Checks AI agent actions before they run. Signed, RFC 3161 timestamped evidence for audits.
Scored across 11 tools
Most tools target distinct resources and actions: action checks, logging, audit retrieval, agent registration/verification, MCP proxy, MCP payload scans, and record verification. A few pairs are conceptually adjacent, such as check_action vs scan_mcp_tool_result and verify_agent vs verify_record, but the descriptions make their boundaries clear.
All tool names use snake_case and a verb-first pattern, e.g. register_agent, check_action, scan_mcp_tools_list, verify_record. Even longer names like run_aiuc1_gap_check and proxy_mcp_request remain predictable within the same convention.
The server exposes 11 tools, which is well within a reasonable range for an agent security, audit, MCP proxy, and verification surface. Each tool appears to earn its place without obvious duplicates or excessive fragmentation.
Core workflows are covered: agent registration, verification, behavior profile setup, action checking/logging, audit log retrieval, MCP proxying and scanning, record verification, and an AIUC-1 self-check. However, notable lifecycle gaps exist, such as listing agents, revoking or deleting agents, searching audit logs across agents, and managing policies or scan configuration.
Run Cyphrex check on a proposed action
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| agentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'run a check,' implying a read-only operation, but it doesn't specify side effects, permissions, or return behavior. This is insufficient for an agent to understand the tool's full impact.
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, highly concise and front-loaded. However, the brevity omits critical details, making it under-specified.
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?
Given no annotations, no output schema, and sparse parameter information, the description is not complete enough for correct invocation. The agent lacks details on expected inputs, outputs, and behavior, making it challenging to use effectively.
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?
The schema includes action and agentId with zero description coverage, and the description fails to mention these parameters at all. There is no guidance on what 'action' should contain (string vs object) or what 'agentId' represents, leaving the agent without essential parameter context.
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 clearly states the tool runs a Cyphrex check on a proposed action, using a specific verb and resource. However, it doesn't explicitly differentiate itself from sibling tools or explain what a Cyphrex check entails, leaving some ambiguity.
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 provided for when to use this tool versus alternatives like log_action or verify_agent. There are no exclusions or contextual hints, so an agent cannot determine the appropriate selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Cyphrex audit log for an agent
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| agentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action ('Get') without revealing any behavioral traits such as pagination, ordering, permission requirements, or return format. The presence of a 'limit' parameter hints at pagination, but the description does not mention it.
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, clear sentence with no superfluous words. It is front-loaded and efficiently communicates the core purpose. Perfect conciseness for a simple tool.
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?
While the tool is conceptually simple, the description lacks important context: no output schema is provided, and the description does not explain the return structure, the meaning of 'limit', or any default behaviors. The agent would need to infer too much about the audit log contents and parameter effects.
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 0%, meaning the description adds no parameter details. The required 'agentId' is loosely implied by 'for an agent', but the optional 'limit' parameter is completely unexplained. The description provides minimal value beyond what the schema already shows.
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 a specific verb ('Get') and resource ('Cyphrex audit log'), scoped to 'an agent'. This clearly distinguishes it from sibling tools like 'log_action' (which writes) or 'check_action' (which verifies). No ambiguity.
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 provided on when to use this tool versus alternatives. The description neither states typical use cases nor excluded scenarios. With sibling tools like 'log_action' and 'check_action', some differentiation or usage context would be helpful, but it is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log an executed action for a Cyphrex agent
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| agentId | Yes | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure, but it only states that it logs an action. It does not mention side effects (e.g., storage writes), authorization requirements, error behaviors, or what happens to previously logged data. The word 'executed' adds a small hint about the action's state but nothing more.
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, tight sentence with no redundant words, making it highly concise. However, its brevity borders on under-specification, so it loses one point for not being appropriately sized for a tool that needs more context.
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?
Given three parameters, no output schema, and no annotations, this minimal description is grossly insufficient. It fails to explain return values, parameter behaviors, or any edge cases, making it nearly impossible for an agent to confidently invoke the tool correctly.
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 0%, so the description must compensate, but it only vaguely aligns with the action and agentId parameters. The metadata parameter is entirely unexplored, and no details are given about accepted shapes or relationships between parameters.
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 clearly identifies the tool as logging an executed action for a Cyphrex agent, specifying the verb 'log' and the resource. While it does not explicitly contrast with sibling tools like check_action or get_audit_log, the purpose is unambiguous enough for basic selection.
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?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about typical use cases. It is a simple declarative sentence without any usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proxy a JSON-RPC tools/list or tools/call request to an upstream MCP server. Cyphrex enforces threat policy before the caller receives the upstream result.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | ||
| message | Yes | ||
| upstreamUrl | Yes | ||
| upstreamSessionId | No | ||
| upstreamAuthorization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds one key behavioral trait: Cyphrex enforces threat policy before returning results. However, it does not disclose details such as session handling, auth requirements, error behavior, or what happens when policy is violated, leaving meaningful gaps.
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 of about 20 words, no filler, and front-loads the key action. Every phrase adds value.
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?
The tool is moderately complex (5 params, nested object, no output schema). The description lacks critical context: how to construct the message, purpose of agentId, session/auth flows, and behavior on policy rejection. It is not complete enough for an agent to invoke reliably without additional information.
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 0%, so the description must compensate. It clarifies that 'upstreamUrl' is an MCP server and 'message' is a JSON-RPC request, but provides no meaning for 'agentId', 'upstreamSessionId', or 'upstreamAuthorization'. With 5 parameters, this is insufficient.
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 clearly states the tool's function with a specific verb ('Proxy') and resource ('JSON-RPC tools/list or tools/call request to an upstream MCP server'). It differentiates from sibling tools (e.g., scan_mcp_tool_result, scan_mcp_tools_list) by focusing on the proxying action itself, not scanning results.
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?
The description implies when to use the tool: when you need to proxy MCP requests while enforcing threat policy. However, it doesn't explicitly mention alternatives or exclusions, though sibling tool names provide context. This is clear usage context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new Cyphrex agent
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits (e.g., side effects, permissions, return behavior). The description only restates the registration action, offering zero additional context about what happens when an agent is registered.
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, short sentence that reads easily, but it is under-specified. It provides only the bare minimum, similar to a stub, and lacks sufficient detail to be considered effectively concise.
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?
Given the tool has three required parameters, no output schema, no annotations, and no elaboration in the description, the context is severely incomplete. The agent cannot determine what registering an agent entails, what the response looks like, or what side effects occur.
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?
The input schema defines three required parameters (name, type, description) with no descriptions in the schema, and the tool description does not explain their meanings, constraints, or relationships. With 0% schema description coverage, this omission is critical and the description fails to compensate.
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 clearly states the action (register) and the resource (a new Cyphrex agent), giving a specific verb-and-resource combination. It doesn't explicitly contrast with sibling tools like verify_agent, but the verb 'register' naturally implies creation, making the purpose clear.
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?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It simply states the action, leaving the agent to infer context without any supporting information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public AIUC-1 readiness self-check. No API key. AIUC-1 readiness self-check. Not certification, and not affiliated with or endorsed by AIUC.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| answers | Yes | ||
| send_results | No | ||
| marketing_opt_in | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one real behavioral fact (no API key required) and a scope disclaimer (not certification, not affiliated), which is worth credit. But it says nothing about what happens to the submitted email or answers, what send_results/marketing_opt_in actually do, whether calls are rate-limited, or what the response contains.
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?
Very short, but not efficient: 'AIUC-1 readiness self-check' appears twice in three clauses, so a large fraction of the text is pure duplication. The useful disclaimers are present but the space wasted on repetition could have carried real parameter or behavior information.
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?
Complexity is moderate-high: four parameters, a nested required object of twelve enumerated answers, no annotations, and no output schema. Against that, the description explains neither the questionnaire structure nor the effect of email/send_results/marketing_opt_in, leaving an agent unable to construct a valid, intentional call.
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 0% and the description mentions no parameters at all. The nested 'answers' object requires twelve keys ('01'–'12') whose meanings are entirely opaque — an agent has no way to know what question 07 or 11 asks. This is the tool's central input and it is completely undocumented.
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 identifies the resource as an 'AIUC-1 readiness self-check' and notes it is public, but the opening verb is implied rather than stated and the purpose sentence is literally repeated twice. An agent can infer this is a questionnaire-based assessment, but cannot tell what the check actually evaluates or returns.
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 use this tool versus the siblings (verify_agent, check_action, scan_mcp_tools_list, etc.), which all appear compliance-adjacent. 'No API key' hints at accessibility, and 'not certification' hints at scope, but neither is framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan an upstream MCP tools/call result for PII, injection, and volume anomalies
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | ||
| agentId | Yes | ||
| toolName | Yes | ||
| serverUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states the scanning categories (PII, injection, volume anomalies) but does not disclose whether the tool is read-only, how anomalies are reported, whether it modifies the result, or any side effects. This leaves significant behavioral ambiguity.
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 with no wasted words and front-loads the core purpose. However, the typo 'tools/call' and the lack of any supplemental detail prevent a perfect score, though this is not a padding or verbosity issue.
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 tool with four parameters, no annotations, and no output schema, the description provides only a high-level scanning intent. It fails to explain input semantics, output format, error behavior, or integration with sibling tools like 'proxy_mcp_request'. The description is too minimal to be considered complete in this context.
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 0%, and the description does not compensate. The function of 'agentId', 'toolName', 'serverUrl', and 'result' is not explained. Only 'result' is implicitly referenced via 'upstream MCP tools/call result', leaving the other three parameters without semantic meaning.
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 a specific verb ('Scan') and identifies the resource ('an upstream MCP tools/call result') plus the intent (detect PII, injection, and volume anomalies). It distinguishes from the sibling 'scan_mcp_tools_list' by focusing on a call result rather than a tool list, though the phrase 'tools/call result' is slightly awkward.
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 provided on when to use this tool versus alternatives such as 'scan_mcp_tools_list' or 'proxy_mcp_request'. The description implies it is used after an upstream MCP call, but does not explicitly state prerequisites, exclusions, or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan an upstream MCP tools/list payload for threats and diff tool snapshots
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes | ||
| agentId | Yes | ||
| serverUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'scan for threats' and 'diff tool snapshots', suggesting non-mutating analysis, but it does not specify whether the operation is read-only, whether it requires network access to 'upstream', what constitutes a 'threat', or if any data is stored or transmitted. This lack of safety and side-effect information is a significant gap for a security-related tool.
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 that grabs the core purpose without excessive wording. It is front-loaded with the verb 'Scan' and the main resource. No fluff or repetition of schema details.
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 tool with three required parameters, no annotations, and no output schema, the description is too sparse. It does not explain the outcome or return value, what 'threats' means, how the diff works, or any side effects. The security context and potential risks are left entirely unspecified, making it insufficient for safe and correct invocation.
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?
The schema description coverage is 0%, so the description must compensate but fails to explain any of the three parameters (agentId, serverUrl, tools). The description's mention of 'payload' vaguely relates to 'tools', but it gives no meaning for 'agentId' or 'serverUrl', nor does it clarify the structure or purpose of the 'tools' array. The agent receives no help beyond the schema's basic types.
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 clearly states the tool's function: scanning an upstream MCP tools/list payload for threats and diffing tool snapshots. This distinguishes it from the sibling 'scan_mcp_tool_result', which likely handles a single tool result. However, 'diff tool snapshots' is somewhat vague without further context.
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?
The description implies this tool is used when you have an upstream MCP tools/list payload, but it does not explicitly state when to use it versus alternatives like 'scan_mcp_tool_result' or list any prerequisites. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set behavior profile for an agent
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | ||
| profile | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the operation. It doesn't reveal whether the profile is overwritten, merged, validated, or what happens if the agentId doesn't exist, nor does it describe any return value.
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 one-sentence description is appropriately brief and front-loaded, with no wasted words. However, it could have used an additional sentence to provide usage context without becoming bloated.
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?
Given the low parameter documentation, lack of annotations, and absence of an output schema, the description is too sparse to be complete. It fails to explain return values, side effects, or validation behavior, which are essential for a mutation tool with an open-ended profile object.
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 0%, and the description adds no meaning to the 'agentId' or 'profile' parameters. It doesn't explain what a valid profile looks like or how the parameters interact, so the agent has insufficient information to correctly populate the arbitrary profile object.
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 the specific verb 'set' and identifies the resource as 'behavior profile for an agent,' clearly indicating the operation. While it distinguishes from sibling tools like register_agent or verify_agent, it does not explicitly contrast with alternatives.
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 provided on when to use this tool versus siblings. There is no mention of prerequisites, alternatives, or context, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch/verify agent details
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral transparency, but it only states a generic action. It does not disclose whether the operation is read-only, what happens if the agent is not found, or any side effects.
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 extremely short, consisting of a single phrase with no unnecessary words. However, the phrasing 'Fetch/verify' is awkward and could be clearer, and the brevity may sacrifice needed detail.
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 simple tool with one parameter and no output schema, the description still fails to convey important context such as the return value, error behavior, or when verification is needed. It omits any usage guidance and does not clarify the tool's role among siblings.
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?
The input schema lists a single required parameter, agentId, but the description does not explain its meaning or format beyond the schema's minLength constraint. Schema description coverage is 0%, so the description should compensate, but it does not.
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 'Fetch/verify' as a compound verb, which is ambiguous about whether the tool retrieves or validates agent details. It names the resource ('agent details') but does not distinguish it clearly from sibling tools like check_action or register_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 usage guidance is provided. The description does not specify when to use verify_agent instead of related tools such as check_action or get_audit_log, nor any exclusions or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a record or export bundle. Reports the signature, a public timestamp when one is present, and an RFC 3161 timestamp valid when a token is attached. A record also reports its hash chain. A bundle reports file_hashes against the manifest. Each part is pass, fail, not_present, or not_checked. A signature that verifies only with a caller-supplied key that is not Cyphrex's is pass_supplied_key. No API key.
| Name | Required | Description | Default |
|---|---|---|---|
| record | No | ||
| bundle_base64 | No | ||
| public_key_pem | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole burden and does a solid job: it enumerates the four outcome states (pass, fail, not_present, not_checked), explains the special pass_supplied_key state, and discloses the auth requirement ("No API key"). It does not say what a malformed input or a wholly unverifiable record returns, which is the main remaining gap.
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?
Dense but front-loaded: the purpose lands in the first clause, then output semantics follow in short declarative sentences. Each sentence contributes information; nothing is padding. Slightly list-like, but appropriate for a multi-mode verifier.
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?
Given a nested, untyped `record` object, zero schema descriptions, no annotations, and no output schema, the description does well on return vocabulary but leaves the caller guessing what to put in `record` and whether the three parameters are alternatives or combinable. For a tool this open-ended, that is a meaningful gap.
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 0% across three undocumented parameters, so the description must compensate. It partly does: `public_key_pem` is explained via the caller-supplied-key / pass_supplied_key semantics, and `record` vs `bundle_base64` map to the two verification modes. But the shape of the nested `record` object and base64 encoding of the bundle are never described.
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?
Opens with a specific verb+resource ("Check a record or export bundle") and immediately enumerates what the check reports (signature, public timestamp, RFC 3161 timestamp, hash chain, file_hashes vs manifest). This is far more than a restatement of the name. It does not, however, differentiate itself from nearby siblings like verify_agent or check_action.
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 when-to-use or when-not-to-use statement, and no mention of the sibling tools an agent might confuse this with (verify_agent, check_action, scan_mcp_tool_result). The agent must infer from the input types that a `record` goes with record verification and `bundle_base64` with bundle verification, but mutual exclusivity is never stated.
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.
run_aiuc1_gap_checkverify_recordcheck_action3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "agentId",
- "action",
- "apiKey"
-]New value: +[
+ "agentId",
+ "action"
+]get_audit_log3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "agentId",
- "apiKey"
-]New value: +[
+ "agentId"
+]log_action3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "agentId",
- "action",
- "apiKey"
-]New value: +[
+ "agentId",
+ "action"
+]proxy_mcp_requestregister_agent3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "name",
- "type",
- "description",
- "apiKey"
-]New value: +[
+ "name",
+ "type",
+ "description"
+]scan_mcp_tool_resultscan_mcp_tools_listset_behavior_profile3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "agentId",
- "profile",
- "apiKey"
-]New value: +[
+ "agentId",
+ "profile"
+]verify_agent3 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +trueInput schema / properties / apiKeyRemoved value: -{
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "agentId",
- "apiKey"
-]New value: +[
+ "agentId"
+]check_actionget_audit_loglog_actionregister_agentset_behavior_profileverify_agentCheck, limit, record and prove AI agent actions with 2-of-3 validators and onchain proofs.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Add one secure layer between your agents and this server.
