Knox Anchor

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full disclosure burden. It does so by specifying the required Authorization header, rejection of unauthenticated calls, key provisioning process, and the exact return fields. However, it does not mention side effects like immutability or possible failure modes, which prevents a 5.

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 three sentences, front-loaded with the main purpose. It efficiently covers returns, authentication, and key provisioning without wasted words.

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's simplicity (two parameters, no output schema, no annotations), the description covers purpose, return values, and usage constraints well. Minor omissions like error handling or example usage are not critical for this level of complexity.

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%, with both event_type and payload having descriptive comments. The description adds no additional parameter-level detail beyond what the schema already states, so a baseline 3 is appropriate.

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 anchors a generic agent action to the Knox chain, using a specific verb and resource. It differentiates from sibling tools by emphasizing 'generic agent action' as opposed to file hash or MCP tool call anchoring.

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 context (generic actions, canonical event types) but does not explicitly state when to use this tool versus siblings like anchor_file_hash or anchor_mcp_tool_call. The 'generic' qualifier implies usage for non-specific actions, but alternatives are not directly named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the file itself is not transmitted, that admissibility is a court determination, and that unauthenticated calls are rejected. This adds valuable behavioral context beyond the schema, though it does not detail the affidavit's structure or 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 three sentences with no filler: it front-loads the purpose, then explains key behavior, then provides auth requirements and a legal disclaimer. Every sentence earns its place.

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 moderate-complexity tool with no output schema or annotations, the description covers purpose, file transmission behavior, legal caveat, and authentication. It does not specify the return structure of the affidavit, which would improve completeness, but overall it is well-rounded.

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% for all four parameters, so the schema already documents them. The description adds minor context by stating 'only the digest + filename + size + MIME type are anchored' and that the caller computes the hash, but this does not significantly enhance parameter understanding beyond the 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 clearly states the specific verb+resource: 'Anchor a SHA-256 file digest to Knox and return an affidavit architected for FRE 902(13)/(14) self-authentication.' This distinguishes it from sibling tools like anchor_event and anchor_mcp_tool_call by explicitly targeting file digests.

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 provides clear context for use: caller computes the hash and only metadata is sent, which indicates when this tool is appropriate. It also states the prerequisite requiring a Bearer API key, but does not explicitly mention exclusions or alternative tools, so it stops short of the top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the record is sealed with a commitment to the authenticated principal, that Knox does not authenticate the named agent, that the event carries `agentIdentityVerified:false`, and that the record makes an independently checkable assertion. This is rich, transparent behavioral context that goes far beyond a simple action statement.

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 long sentences, but every clause adds substantive value—purpose, event type, metadata fields, and the critical trust model. It is dense but not wasteful; the front-loaded purpose is immediately clear. It could be slightly tightened, but for the conceptual complexity it is well-structured.

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 absence of annotations and output schema, the description is remarkably complete. It covers the event's content, the trust boundaries, the principals involved, and the verifiable nature of the record. Combined with fully described schema parameters, an agent has everything needed to use the tool appropriately.

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 has 100% description coverage, so the baseline is 3. The description does not add per-parameter meaning beyond what the schema already provides; it gives high-level context about digests and agent identity, but the schema descriptions already explain the assertion semantics and formats. The description neither compensates for gaps nor loses credit.

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 records an `agent_mcp_tool_call` event with structured metadata, naming the specific event type and its purpose as a 'convenience anchor' for AAM MCP. It distinguishes itself from generic anchoring by focusing on tool-call auditing, but it does not explicitly contrast with the sibling `anchor_event` tool, so it falls short of full differentiation.

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 anchor an MCP tool call and record its metadata—but it does not explicitly state when not to use it or how it compares to alternatives like `anchor_event` or `anchor_file_hash`. The usage context is clear enough to infer, but there is no explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It lists what metrics are returned and mentions it mirrors a public endpoint, implying a read-only operation. However, it does not explicitly state that there are no side effects, no auth required, or describe rate limits.

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 sentences with no filler. The first sentence enumerates the return values, and the second provides the endpoint context. Every word earns its place.

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 no-parameter health check with no output schema, the description provides enough detail about the contents and the SLA target. It does not describe the exact output format, but that is less critical given the listed metrics.

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 the description need not compensate for schema gaps. The baseline for 0 params is 4, and the description adds context by explaining the kind of data returned.

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 ('Return') and names the resource ('Knox service health') with a detailed list of outputs. It clearly distinguishes from sibling tools like verify_anchor or anchor_file_hash, which focus on anchor operations.

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 explicit guidance is given for when to use this tool versus alternatives. It implies a health-check use case but does not name sibling tools or state when not to use it, leaving the decision to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the tool 'Return' (implying read-only) and describes precisely what will be returned (operator, patent, jurisdiction, tools, links). This gives useful behavioral context beyond a simple tautology, though it does not mention side effects or error cases, which is acceptable for a read-only meta 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 is front-loaded with the verb 'Return' and immediately lists the specific content items. No fluff or redundant phrasing; every element 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?

Given the tool has no parameters and no output schema, the description fully covers what the tool returns and the nature of that information. It details all major components of the self-description, making it complete for the tool's simplicity.

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 has zero parameters, so the baseline is 4. The description appropriately avoids mentioning parameters since there are none, and the semantic meaning of the tool is fully captured by describing the return value.

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 'Return' and clearly identifies the resource as 'the Knox MCP server self-description'. It also enumerates the contents (operator, patent reference, jurisdiction, available tools, and links), which distinguishes it from sibling tools that deal with anchoring, events, or health checks.

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 clearly implies usage context: use this tool to obtain server self-description and discover capabilities or documentation links. It doesn't explicitly mention alternatives or exclusions, but the unique meta-purpose is obvious relative to the sibling tools, giving clear context without needing explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are available, so the description carries the burden of behavioral disclosure. It adds valuable context by stating that the taxonomy 'expands monotonically and is itself anchored on every expansion', indicating growth and immutability. However, it does not describe the exact return format or potential side effects, though the operation is clearly a read.

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 concise, with two sentences. The first sentence immediately states the core purpose, and the second adds meaningful behavioral context without redundancy. It is well-structured and front-loaded.

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 parameter-less listing tool with no output schema, the description adequately conveys what is returned and the nature of the data (canonical, anchored, expanding). While it does not specify the exact response structure, the conceptual detail compensates for the absence of an output schema.

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 and the schema declares none. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to explain parameter semantics. The absence of parameters is fully reflected in the 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 clearly states the action ('Return') and the resource ('canonical Knox event-type taxonomy'), making the tool's purpose explicit. It distinguishes itself from sibling tools like anchor_event or verify_anchor, which focus on anchoring and verification rather than listing.

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 explicit when-to-use or alternative guidance is provided. The usage is implied by the tool name and description, but sibling tools are not mentioned, so the user must infer when to choose this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and discharges it richly: it enumerates the validation steps (plan/nonce checked against departure, hash chain recomputed, plan/record/report compared), states the sealing outcome (one stamp on the plan as agent_trip_returned), discloses idempotency behavior (repeat return refused as REPLAY and not sealed), and specifies auth ('Requires a Knox Bearer API key on the Authorization header'). It even flags a trust boundary: Knox never holds the trip key, so MACs should be verified externally.

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?

Front-loaded with the outcome ('THE TICK. Your own door posts a returned trip'), then the mechanics, then the replay rule and auth. It is dense and jargon-heavy, but almost every sentence conveys validation, sealing, or auth information rather than filler.

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 complex cryptographic tool with seven parameters, no output schema, and no annotations, the description covers the return path well: what is validated, what gets sealed, what happens on replay, and the auth requirement. It does not explain other failure modes (e.g., a failed hash-chain comparison) or the exact success payload, though the sealed verdict is named.

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 seven parameters (plan, nonce, report, door_head, observations, departure_seal, flow) including formats and patterns. The description adds high-level meaning about how departure_seal and nonce are validated against the departure, but no per-parameter syntax or format detail beyond what the schema supplies. Baseline 3 is appropriate.

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 specific verb (posts a returned trip) and resource (the plan, the door's record, head, nonce, report) and states the outcome concretely: Knox validates and seals the verdict as agent_trip_returned. It is clearly distinguishable in spirit from the sibling verify_agent_trip, but it never names the sibling tool itself, relying on the verify-agent-trip.mjs script name to imply the split. The proprietary 'Knox'/'door'/'TICK' vocabulary adds flavor without obscuring the core operation.

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?

A prerequisite is stated ('The trip's departure must already be sealed under the same key as agent_trip_departed'), which tells the agent when the call is valid. It also notes a second return is refused as REPLAY. However, it gives no explicit guidance on choosing this tool over verify_agent_trip or the other siblings, so the routing signal is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses the access model (public, no key), the witness semantics (door_observed — the door ran in the agent's own process), and the crucial scoping rule that comparison is the agent's report against the door's record, not the outside system's answer. It stops short of rate limits, failure modes, or whether results are cached/immutable.

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?

Five sentences with the return contract front-loaded, but 'THE TICK' is an unexplained opener that spends space without information, and the identifier/return details partially restate the schema. Jargon density makes it slower to parse than its length warrants.

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?

There is no output schema and no annotations, so the description must enumerate results — it does (verdict LINES_UP/MISMATCH, finding classes, door head, seal time, Bitcoin batch status). Combined with the either-or input contract and the public/no-key note, an agent has what it needs; only unexplained domain vocabulary keeps this from being fully self-contained.

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%, so the per-parameter descriptions are already in the schema (seal = 64 hex stamp code, trip_id minted at departure). The description adds genuine semantics the schema does not: either identifier is accepted to resolve the same trip, and it repeats the 64-hex constraint explicitly.

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: given a returned seal or trip id, return what was sealed (verdict, finding classes, door head, seal time, Bitcoin status). This is clearly distinguishable from verify_anchor. However, the opening 'THE TICK' and heavy jargon (Knox, door) add noise without clarifying the resource being verified.

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?

Provides useful context ('Public, no key') and implies the trigger (a trip has returned, you hold a seal or trip id). But it never states when to use this instead of the sibling verify_anchor, nor any exclusions or error conditions. Usage is implied rather than specified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It explicitly states the tool is public and requires no authentication, and it enumerates the return fields (anchor record, chain link validity, event type, sequence number, verify URL). This gives agents a clear idea of what to expect, though it does not describe failure cases or behavior for invalid hashes.

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 efficiently packs all necessary information: the input format, the action, the return fields, and the authentication status. There is no redundant fluff; every phrase earns its place, and the most important information (input and action) is front-loaded.

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's simplicity (one parameter, no output schema), the description is quite complete: it lists all major return components and the auth requirement. However, it lacks details on potential error behavior or the exact structure of the 'anchor record,' which would be helpful given there is no output schema. Still, it is sufficiently complete for a straightforward verification tool.

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 already provides 100% coverage for the single parameter, including the pattern and description. The tool description repeats the same information ('SHA-256 anchor hash (64 hex chars)') without adding new semantic meaning. Since the schema does the heavy lifting, the description adds no additional parameter-level value.

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: given a SHA-256 anchor hash, it returns the anchor record, chain link validity, event type, sequence number, and verify URL. The verb 'return' and the specific resource 'anchor record' make the purpose unambiguous, and the mention of chain link validity distinguishes it from sibling tools like get_chain_health or anchor_event.

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 clear usage context: it is used when you have a SHA-256 anchor hash and need verification details. It also notes that the tool is public with no authentication required, which is useful guidance. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.