A handling-condition ledger that travels with a sensitive payload across every agent hop.
Scored across 4 tools
Each tool maps to a distinct phase of the custody lifecycle: reading standing, appending a hop, grading at receipt, and originating a new payload. The only mild overlap is between extend_custody and originate_envelope, since both produce signed material, but their descriptions (append to an existing logger vs. create a new sealed payload) keep them separable.
All four names use consistent snake_case and are domain-flavored and readable. Three follow a verb_noun pattern (extend_custody, grade_chain, originate_envelope), with custodian_standing being noun-first as a read operation—a minor but explicable deviation.
Four tools is within a reasonable range for a narrow, specialized ledger service, and each tool corresponds to a real lifecycle action rather than filler. It sits on the lean side, but nothing feels redundant or gratuitous.
The surface covers create (originate), append (extend), state transition (grade), and one read (custodian_standing), but there is no way to fetch an envelope, list chains, or inspect/verify the accumulated custody hops or signatures. Agents can write to the ledger but cannot fully read back or audit it, which is a notable gap for a custody ledger.
Read cross-chain custodian standing. Requires Authorization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It identifies the operation as a read and notes an authorization requirement, which is useful, but it does not explain the authorization mechanism, rate limits, or any other operational constraints.
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 two short sentences with no wasted language, and the core operation is front-loaded ahead of the authorization note.
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 zero-parameter read tool, the description covers the basic operation and an authorization requirement. However, without annotations or an output schema, it could say more about what "custodian standing" means and what the caller should expect from the authorization requirement.
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 tool has zero parameters, so parameter semantics are not a meaningful source of complexity. The baseline score of 4 applies because there are no inputs to document or disambiguate.
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 specific verb and resource: "Read cross-chain custodian standing." It is clear what the tool does, but it does not explicitly distinguish it from sibling tools such as extend_custody or grade_chain.
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 only usage guidance is "Requires Authorization," which is a prerequisite rather than a when-to-use rule. It gives no explicit conditions for choosing this tool over its siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the travelling logger with a signed custody hop. Requires Authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| store | No | ||
| chain_id | Yes | ||
| custodian | Yes | ||
| jurisdiction | No | ||
| custodian_class | No | ||
| received_at_min | No | ||
| released_at_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the operation requires authorization and produces a signed custody hop, but it does not explain side effects, whether the chain is mutated irreversibly, what validation occurs, or what happens on failure. For a mutation tool with seven parameters, this is thin.
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. It is appropriately concise for a short summary, though it could benefit from a second sentence covering key behavioral or parameter 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 seven parameters, 0% schema description coverage, no annotations, and no output schema, the description is far too sparse to be complete. It mentions authorization and signing but leaves the agent without enough information to invoke the tool correctly or understand its 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% and the description mentions no parameter names or meanings. Seven parameters—including required chain_id and custodian plus optional store, jurisdiction, custodian_class, received_at_min, and released_at_min—are entirely undocumented beyond their schema types. The description adds no semantic guidance for any parameter.
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 specific verb and resource: 'Extend the travelling logger with a signed custody hop.' This is clearly a mutation that appends to a custody chain. It does not explicitly differentiate from siblings like custodian_standing or grade_chain, but the core action is understandable.
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 only usage guidance is 'Requires Authorization,' which is a precondition rather than a when-to-use rule. There is no mention of when to choose this tool over alternatives such as originate_envelope or grade_chain, and no exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grade a chain at receipt (CLEAN / GRADED / SPOILED). Requires Authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden; it does add a real disclosure that Authorization is required, which the structured data does not. However it does not say whether grading mutates or locks the chain state, whether it is reversible, or what happens if the chain was already graded — significant gaps for an unannotated 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?
Two short, front-loaded sentences with zero filler; the outcome enum sits right after the verb. It is arguably terse to the point of under-specification, but nothing in it is wasted.
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 no annotations, no output schema, and 0% parameter documentation, the description leaves major questions open: what the three grades mean behaviorally, what is returned, whether the chain is consumed or altered, and what receipt actually refers to. The auth note is a start but far from sufficient.
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 0% and the single parameter chain_id is only typed as a string with no description. The description never explains the expected identifier format, where chain_id comes from, or how it relates to 'receipt', so it does not compensate for the coverage gap.
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 and resource ('Grade a chain') plus a scope ('at receipt') and names the concrete outcome states CLEAN / GRADED / SPOILED, so the agent knows what the call produces. It does not differentiate itself from siblings like originate_envelope or extend_custody, and 'grade' vs 'extend custody' is only inferable from the parenthetical.
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?
'at receipt' implies the moment the tool applies, which is a useful timing cue, but there is no explicit when-to-use/when-not guidance and no mention of the sibling alternatives. The agent must infer that grading happens only once the chain arrives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Originate a sealed payload (trial or pass allowance over MCP; x402 needs the HTTP header). Requires Authorization.
| Name | Required | Description | Default |
|---|---|---|---|
| terms | Yes | ||
| payload | Yes | ||
| sensitivity | Yes | ||
| delivery_receipt_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It notes an authorization requirement and x402 header distinction, but does not disclose whether this is a mutation, whether the payload is destroyed or persisted, idempotency, error behavior, or other 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 a single compact sentence with no wasted words, so it is structurally concise. However, it is under-specified and front-loads cryptic jargon rather than useful selection or invocation 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 four parameters, a nested object, no annotations, no output schema, and 0% schema coverage, the description is far too thin. It adds only an auth note and an x402/MCP implementation remark, leaving core semantics and parameter behavior undocumented.
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?
There are four parameters (payload, sensitivity, terms, delivery_receipt_required) with 0% schema description coverage, including a nested 'terms' object. The description adds no meaning for any parameter, leaving the agent with no semantic guidance beyond the raw schema.
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 gives a verb and object ('Originate a sealed payload') but 'sealed payload' is unexplained jargon, and it does not distinguish this tool from siblings like custodian_standing, extend_custody, or grade_chain. An agent knows it originates something, but not concretely what.
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?
It mentions 'trial or pass allowance over MCP; x402 needs the HTTP header' and 'Requires Authorization,' but provides no explicit when-to-use guidance or alternatives. The agent is not told under which conditions to choose this tool versus its siblings.
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.
custodian_standingextend_custodygrade_chainoriginate_envelopeSigned, versioned ledger of standing instructions with intake contradiction diffs.
The record of what the agent relied on: a signed, chained receipt per cleared read. Verify by id.
Hash-chained HMAC-signed audit log MCP for A2A (agent-to-agent) calls. Every tool-call, agent-ha...
Tamper-evident audit log service for agent-to-agent transactions
Add one secure layer between your agents and this server.