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?

No annotations are provided, so the description carries the full burden. It explicitly states the tool 'records an event' and implies a write side effect, but lacks details on persistence, reversibility, or permissions. It is adequate but not rich.

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 core action, and free of redundancy. The 'theater' phrasing is slightly vague but does not detract significantly from clarity.

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 output schema and no annotations, the description covers the core purpose, the key metadata fields, and the intended use case. It does not mention verification or failure modes, but 'independently auditable' hints at verifiability.

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 parameter descriptions are already clear. The description merely lists parameter names without adding deeper semantic context, so it meets the baseline but does not exceed it.

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 verb 'Records' and the resource ('agent_mcp_tool_call event'), with specific metadata fields. This distinguishes it from generic siblings like anchor_event by specializing in MCP tool-call auditing.

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 says 'Use this to make an MCP-using agent's actions independently auditable,' providing explicit use case context. However, it does not mention alternatives or when not to use it, so it stops 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.

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 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.