Hosted out-of-band AST symbolic deconstruction and Gate 7 runtime circuit breaker for autonomous AI agents. Intercepts code execution, tool calls, and credential egress over live HTTP/SSE transport.
Scored across 3 tools
Each tool targets a distinct capability: policy-gated tool execution, on-chain transaction signing, and TEE attestation verification. The first two both hinge on 'out-of-band arbitration/execution' language, so an agent could momentarily confuse whether a token issuance belongs to execute or sign, but the resource targets (tool call vs. smart contract) separate them adequately.
All three tools follow the identical aw1_<verb>_<object> snake_case pattern (execute_protected_tool, sign_onchain_transaction, verify_tee_attestation). The shared namespace prefix is predictable and the verb choice is meaningful in every case.
Three tools is on the lean side but coherent for a narrow security-middleware surface covering gate, sign, and attest. No tool feels redundant or padded; the surface is just slightly thin for a full circuit-breaker service.
The set covers evaluation, signing, and attestation verification, but there are no operations for managing the policy set itself (create/update/list/revoke breaker policies) or for inspecting audit/continuity records. An agent can execute but cannot configure or remediate, which is a notable lifecycle gap for a circuit-breaker domain.
Intercept and evaluate AI agent tool calls against out-of-band AST circuit breaker policies.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Serialized parameters or code payload | |
| tool_name | Yes | Target tool name to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and fails to disclose key behaviors: whether the target tool is actually executed on policy pass, what happens on policy failure (error, blocked response), whether side effects occur, and what is returned. The phrase 'out-of-band AST circuit breaker policies' is opaque and does not compensate for the lack of behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, the conciseness comes at the cost of clarity due to unexplained jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security-sensitive execution gate with no output schema and no annotations, the description omits critical information: what the tool returns, error semantics on policy violation, and whether execution is performed. An agent cannot confidently invoke this tool or interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'tool_name' and 'payload' explicitly described. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Intercept and evaluate AI agent tool calls') but uses jargon ('out-of-band AST circuit breaker policies') and never clarifies whether the tool also executes the target tool or only evaluates it. The name suggests execution, yet the description only mentions interception/evaluation, leaving ambiguity for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus calling the target tool directly or versus the sibling attestation tool. The only implied usage is that it is for protected tool calls, but there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Out-of-band arbitration and execution token minting for on-chain smart contract calls.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Smart contract function signature | |
| chain_id | No | Target EVM network ID | |
| amount_bwp | Yes | Transaction value equivalent for velocity tracking | |
| target_contract | Yes | Target smart contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain that this signs a transaction, whether the operation is irreversible, what authorization or key material is required, or what 'arbitration' and 'token minting' mean operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is not bloated, but its front-loaded jargon ('out-of-band arbitration') obscures the actual operation. Conciseness is adequate, but structure does not help an agent quickly understand the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a four-parameter mutation-like operation, the description is too thin. It should disclose that this signs an on-chain transaction, note any authorization or safety considerations, and clarify how it relates to the sibling execution and attestation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters, including target_contract, method, chain_id, and amount_bwp. The description adds no parameter-level meaning beyond the schema, which fits the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses vague jargon ('out-of-band arbitration and execution token minting') instead of stating the concrete verb and resource: signing an on-chain transaction. It does mention smart contract calls, but an agent cannot confidently distinguish this from siblings like aw1_execute_protected_tool based on the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus aw1_execute_protected_tool or aw1_verify_tee_attestation, nor any prerequisites or exclusions. The phrase 'for on-chain smart contract calls' gives only the broadest context and does not tell the agent when this signing step is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify cryptographic TEE attestation seal against sovereign ledger continuity records.
| Name | Required | Description | Default |
|---|---|---|---|
| attestation_id | Yes | Attestation hash seal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and falls short: it does not confirm the operation is read-only, does not describe what happens when verification fails (exception vs. negative result), and does not mention authorization requirements for accessing ledger records. The only behavioral hint is the verb 'Verify', which implies a check rather than a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the verb and target lead. It is dense with domain jargon ('sovereign ledger continuity records') but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with no output schema, the description should indicate what a successful or failed verification yields (a boolean, a seal record, a continuity proof). None of that is present, and failure semantics are absent, leaving an agent unable to interpret results confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single required parameter, so the schema already defines attestation_id as an 'Attestation hash seal'. The description's phrase 'attestation seal' aligns with but does not extend the schema (e.g., expected hash format or length), so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Verify') and a specific resource ('cryptographic TEE attestation seal against sovereign ledger continuity records'), so the operation is identifiable. It does not reference the sibling aw1_execute_protected_tool to differentiate the verification path from the execution path, leaving that distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus aw1_execute_protected_tool, no prerequisites, and no conditions under which verification should be skipped or retried. Usage is only inferable from the word 'Verify' itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aw1_sign_onchain_transactionaw1_execute_protected_tool3 fields changedInput schema / properties / agent_idRemoved value: -{
- "default": "agent_planner",
- "type": "string"
-}Input schema / properties / payload / descriptionPrevious value: -"Raw serialized invocation arguments, commands, or python code"New value: +"Serialized parameters or code payload"Input schema / properties / tool_name / descriptionPrevious value: -"The target tool function name proposed by the agent"New value: +"Target tool name to execute"aw1_verify_tee_attestation1 field changedInput schema / properties / attestation_id / descriptionPrevious value: -"The 24-character execution token to verify"New value: +"Attestation hash seal"aw1_execute_protected_toolaw1_verify_tee_attestation
Add one secure layer between your agents and this server.