MCP Tools
ArmorCodex's MCP tools for intent plan registration and policy management
MCP Tools
ArmorCodex exposes 4 MCP tools through the armorcodex-policy MCP server. These are available to Codex during a session - Codex uses them to register plans and read or stage policy.
Users manage policy through armor commands. MCP tools are called by Codex (the model). Applying a policy change is human-only: the model can stage a proposal but only a terminal armor yes applies it.
register_intent_plan
Declare the tools Codex intends to use for the current task. ArmorCodex requires this before other tool calls; without a registered plan, tool calls are blocked (fail-closed).
Input:
| Parameter | Type | Required | Description |
|---|---|---|---|
goal | string | Yes | One-line summary of what the plan accomplishes |
steps | array or JSON string | Yes | Ordered list of tool calls |
plan | object or JSON string | No | Alternative: pass the whole plan as one object |
Each step in the steps array:
| Field | Type | Required | Description |
|---|---|---|---|
action | string | Yes | Tool name (e.g., Bash, apply_patch, mcp__server__tool) |
description | string | No | Why this step is needed |
metadata.inputs | object | No | Expected tool parameters for enforcement |
Use canonical tool names in the plan. Codex's shell tool reports several names (exec_command, shell, local_shell, unified_exec, container.exec); ArmorCodex normalizes them all to Bash, so plan a Bash step for any shell command.
Example input:
{
"goal": "Read and summarize README.md",
"steps": [
{
"action": "Bash",
"description": "List the project files",
"metadata": { "inputs": { "command": "ls -la" } }
}
]
}What happens when called:
- The plan is validated against the intent plan schema
- If an API key is configured, the plan is sent to the ArmorIQ backend for a signed JWT intent token
- The plan and token are stored locally as a pending plan file
- The next
PreToolUsehook consumes the pending plan and enforces it
policy_read
Read the current policy state.
Input:
| Parameter | Type | Required | Description |
|---|---|---|---|
id | string | No | Specific rule ID to read |
Without id: Returns the full policy state (version and rules). With id: Returns a single rule.
Example output:
{
"version": 3,
"policy": {
"rules": [
{ "id": "policy1", "action": "deny", "tool": "bash" }
]
}
}policy_command
Run a structured armor policy command. Read and stage are allowed; applying is human-only.
Input:
| Parameter | Type | Required | Description |
|---|---|---|---|
command | string | Yes | An armor policy command (e.g. policy list, policy add deny bash, policy template lockdown) |
confirm / yes are rejected by this tool. To apply a staged change, a human runs armor yes in the terminal. This is what keeps policy mutation human-in-the-loop.
policy_update
Legacy tool, retained for back-compat. Unlike policy_command, policy_update applies immediately without staging. Prefer the staged armor commands / policy_command for the human-only guarantee.
Create, modify, or delete a rule directly. Whitelisted (never blocked by intent enforcement) so a blocked-then-fix loop can work, and every change is logged.
Whitelisted Tools
These tools are never blocked by ArmorCodex's intent enforcement (they are needed for the system to function):
register_intent_plan- Codex needs this to declare planspolicy_read- Policy reading (read-only)policy_command- Policy read and stage (no apply)policy_update- Legacy policy mutation- The MCP server itself (
armorcodex-policy.*) is always allowed
Trust lifecycle operations (revoke, re-anchor, delegate) are not yet available in ArmorCodex. They are tracked as a parity gap.
Verifying MCP Server Connection
The installer wires [mcp_servers.armorcodex-policy] into ~/.codex/config.toml. Check it is registered:
codex mcp list | grep armorcodex