FaultKey · CausalLayer

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

With no annotations, the description carries the full burden. It discloses several important behavioral traits: determinism, credit cost, per-jurisdiction thresholds, override requirements with governance rationale, and its relationship to the certificate engine. It could add more about error handling or exact return structure, but the provided details are substantive.

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?

Every sentence in the description carries meaningful information: method reference, usage timing, verdicts, engine linkage, exclusion, threshold access, override policy, cost, and determinism. It is front-loaded with the core purpose and contains no 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?

Given the tool's complexity (nested action object, overrides) and absence of an output schema, the description covers the core aspects: what input is expected, what verdicts to expect, when to call, and governance constraints. It does not specify exact response structure, but the verdict list is sufficient for an agent to understand the contract.

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 each property already has a description, so the baseline is 3. The tool description adds meaning beyond the schema by explaining that the 'action' parameter is a structured ProposedAction (not prose) and that 'overrides' require a governance rationale for audit. This enriches the schema's formal definitions.

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 a 'Deterministic prospective-evaluation gate' that evaluates a ProposedAction and returns one of three verdicts. It distinguishes itself from sibling verification tools by explicitly positioning it as a pre-response gate rather than a post-hoc certificate tool, and it clarifies it is not a content safety classifier.

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 states clearly WHEN to use it: 'Pass a ProposedAction BEFORE the agent delivers a response.' It also provides exclusion guidance: 'NOT a content safety classifier on raw prose.' While it does not explicitly name alternative sibling tools, it gives enough context to infer appropriate use cases.

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?

The description discloses important behavioral traits beyond any annotations: it is 'Claude-powered' (LLM-based), a 'pre-processing convenience tool' with a deterministic scoring engine that remains LLM-free, and it costs 10 credits. This gives the agent awareness of non-determinism, cost, and its auxiliary role. It does not mention potential failure modes or rate limits, but the provided context is substantial given no annotations exist.

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 composed of three sentences plus a note. It leads with the tool's core function, then describes the output and adds important caveats. Each sentence earns its place, though the length is slightly above minimal. No fluff is present, and key details (cost, LLM nature) are efficiently included.

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?

Despite having no output schema and no annotations, the description covers the essential context: what the tool does, what it returns, its relationship to submit_incident, cost, and its LLM-based nature. It is complete enough for an agent to use it correctly without needing additional documentation. A perfect score is withheld because it does not mention error handling or clarify the 'agents, events' fields in more detail.

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 all three parameters, so the description does not need to explain them. The description adds contextual value by detailing the output (agents, events, severity, jurisdiction, financial impact) which indirectly relates to the text and hint parameters, but it does not elaborate on parameter syntax or formats beyond the schema. This aligns with the baseline 3 for high schema coverage.

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 an extractor that parses unstructured text into a typed JSON schema, explicitly naming the resource (unstructured text) and the output format required by submit_incident. It distinguishes itself from sibling tools by positioning itself as a pre-processing convenience for incident submission, not as a submission, evaluation, or simulation tool.

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 states that the tool parses text into the schema required by submit_incident, which strongly implies it should be used before submission to prepare incident data. It provides clear context for when to use it, though it does not explicitly mention alternatives or when not to use it. The note about being a pre-processing tool adds further clarity.

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 full burden. It discloses the return types (index or full JSON) and the JSON contents (signed Merkle root, leaves, OpenTimestamps proof reference), but does not explicitly state safety (read-only) or other behavioral traits like side effects or potential empty results.

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, information-dense sentence. It front-loads the verb and resource, then delivers the two modes and key JSON fields 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?

For a simple tool with one optional parameter and no output schema, the description covers the essential return behavior and contents. It lacks details like response format for the index (e.g., array of versions) but is otherwise sufficient for an agent to invoke it 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 coverage is 100% (version is described). The description adds semantic value by implying that the optional version parameter distinguishes between retrieving all batches (index) and a single batch (full JSON), which is not fully explicit in the schema alone.

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 ('CausalLayer Tessera anchor batches') with clear modes: index of all batches or one batch's full JSON. This differentiates it from siblings like verify_certificate and query_issuer_registry, which serve distinct purposes.

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 usage (when you need anchor batch data, use this tool) and adds 'FREE' as a hint, but it does not explicitly state when to use this vs alternatives or list any exclusions. It provides clear context but lacks direct alternative differentiation.

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?

Without annotations, the description adds useful context: access is free/no API key required, and only active issuers are included. It does not mention response format, error handling, or rate limits, but the read-only nature is clear from 'Return,' and the auth trait is disclosed.

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, front-loaded with the main action, and no redundant information. Every word contributes to understanding what the tool does.

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 one-optional-param query tool, the description adequately covers purpose, data fields, and access requirements. It lacks edge-case behavior (e.g., invalid issuer_id) but is otherwise 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?

The sole parameter issuer_id is fully described in the schema (optional, example, behavior when omitted). The description merely echoes this information without adding new semantic details, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and clearly identifies the resource (CausalLayer issuer registry) and its contents (fingerprints, algorithms, validity windows, anchor-log repo). It distinguishes itself from siblings like verify_certificate by focusing on registry retrieval rather than verification.

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 usage guidance or alternatives are mentioned. The description implies use when needing issuer registry data, but it does not specify when not to use it or compare it to sibling tools such as verify_certificate.

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 burden. It discloses key behavioral traits: full implementations for AU/EU, research stubs for US/UK/CA with `is_stub: true`, pure determinism, credit cost, and the need to consult a catalog for support. It also describes the return format. This is exemplary transparency.

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 dense but appropriately sized for a complex tool. It front-loads the core purpose, then adds stub status, discovery, cost, and determinism in separate clauses. Every sentence earns its place, though it is slightly long.

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 complexity (5 nested parameters, no output schema), the description adequately covers return values, stub limitations, and a discovery mechanism. It could mention error handling or the role of primaryJurisdiction, but the schema covers the latter. Overall it is sufficiently complete for an agent to invoke 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 coverage is 100%, so baseline is 3. The description adds conceptual meaning by framing the three required parameters ('attributable apportionment', 'union of jurisdiction role tags', 'union of jurisdiction-specific flags') and notes optional subset selection. This adds value beyond the schema's individual field descriptions.

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 purpose with a specific verb ('return') and resource ('multi-jurisdiction overlay'), enumerating the output components (post-overlay shares, rules fired, citation URLs, matrix). It distinguishes itself from siblings by specifying its unique computation and jurisdictions.

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 on when to use the tool (given a canonical apportionment, actor tags, and flags) and includes a clear pre-flight instruction to check the catalog for stub status. It does not explicitly name alternative tools, but the context is sufficient for correct selection.

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 transparency burden. It discloses determinism ("Pure deterministic; same inputs produce a byte-identical result"), cost (1 credit), and points to the catalog endpoint. However, it does not explicitly state whether the operation has side effects, requires special permissions, or what the exact response structure is. The deterministic and cost details add value, but the absence of side-effect or permission disclosure is a 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?

The description is four sentences, all informative: purpose, inputs/outputs, catalog reference, and cost/determinism details. It is front-loaded with the main purpose and each sentence adds distinct value; however, it is slightly longer than strictly necessary, earning a 4 rather than 5.

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 nested parameters and no output schema, the description explains the high-level output (apportioned shares individually and in composite) and provides the catalog endpoint. It lacks a detailed output format example or edge-case guidance, but the deterministic and cost information, combined with the clear input/output description, makes it sufficiently complete for an agent to understand when and how to invoke the 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?

Schema description coverage is 100%, so baseline is 3. The description adds context by grouping parameters ("verdict + fourFactorScoring + agents and a list of remediation IDs") and explaining that remediations come from the FK-METHOD-2026-003 catalog and cite statutes/standards. This complements the schema but does not substantially elevate semantic understanding beyond what the property descriptions already provide.

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 a specific verb and resource: "Counterfactual remediation simulator" that takes a certificate's verdict, fourFactorScoring, agents, and remediation IDs to return apportioned shares. It distinguishes itself from siblings by focusing on simulating remediation outcomes rather than verification or other functions.

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 context for when to use the tool: when needing to simulate counterfactual remediation outcomes from a certificate's verdict and scoring. It also gives a prerequisite (GET /api/v2/remediation/catalog for IDs) and mentions cost parity with verify_certificate, though it does not explicitly name alternatives or exclusions.

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 of behavioral disclosure. It explicitly lists the return values (signed CausalCertificate, liability allocation, evidence-chain completeness, regulatory mapping, Bitcoin proof) and discloses the cost and guardrails. This is a solid amount of transparency, though it does not explain failure modes or exact evidence thresholds, which would push it to 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 long and front-loaded with the main purpose. Each sentence adds critical information: purpose, return values, cost, and guardrails. There is no fluff or repetition, making it concise and 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?

The description provides a comprehensive overview of what the tool does, what it returns, its cost, and its guardrails. For a complex submission tool with 11 parameters and no output schema, this is reasonably complete. However, it does not elaborate on the 'minimum evidence' requirement or error handling, leaving some gaps for an agent trying to use the tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 18% (2 out of 11 parameters have descriptions). The description mentions guardrails that map to `pii_acknowledged` and `deterministic_only`, but it does not explain the meaning or purpose of other parameters such as `agents`, `events`, `severity`, or `jurisdiction`. The description does not compensate for the low schema coverage, leaving many parameters underspecified.

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 starts with a specific verb and resource: 'Submit an AI incident for deterministic causal liability attribution.' This clearly identifies the tool's primary function and distinguishes it from siblings like submit_otel_trace (which submits telemetry) and evaluate_prospective_response (which evaluates responses). The purpose is unambiguous and the resource is well-defined.

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 context on when to use this tool: to submit an AI incident for liability attribution. It also mentions cost (50 credits) and three guardrails (PII scan, deterministic-only acknowledgement, minimum evidence), which help the agent understand prerequisites and constraints. However, it does not explicitly mention alternatives or exclusions, 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.

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

With no annotations provided, the description carries the full burden and does an excellent job: it discloses the cost (50 credits), the three guardrails (PII scan, deterministic-only, minimum evidence), and the trace-to-incident mapping details (span/event, service.name grouping, evidence pointer propagation). This gives the agent critical behavioral context beyond the schema.

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 four sentences, each adding distinct value: primary purpose, mapping logic, cost, and guardrails. It is front-loaded with the main action, uses semicolons for compactness, and contains no filler or redundancy. 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?

Given the tool's complexity and lack of output schema, the description covers the major aspects: purpose, mapping, cost, and guardrails. However, it leaves some ambiguity about behavior in edge cases (e.g., zero spans) and does not explain the return format beyond 'CausalCertificate' (though that is presumably covered by submit_incident). The schema fills some gaps, so the overall package is strong but not exhaustive.

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 only 38%, so the description needs to compensate. It adds meaningful context for some parameters via guardrails (PII scan aligns with pii_acknowledged, deterministic-only aligns with deterministic_only) and mentions OTLP payloads, but it does not explain the remaining parameters (title, category, currency, jurisdiction, financial_impact_cents). While it partially fills the gap, it falls short of fully compensating for low schema coverage.

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 converts an OpenTelemetry OTLP JSON trace into a FaultKey incident and returns a CausalCertificate, distinguishing it from submit_incident by referencing the same certificate. It also specifies the mapping behavior (spans to events, service.name to agents) and propagation of trace/span IDs, making the purpose specific and unambiguous.

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 implicitly tells when to use the tool (when you have an OTLP trace) by stating its core function, and it relates to submit_incident by noting it returns the same certificate. However, it does not explicitly state when not to use it or provide direct alternatives beyond mentioning submit_incident. This is clear enough for an agent to infer, but a more explicit comparison would improve it.

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 of behavioral disclosure. It adds valuable context: a cost of 1 credit and production-environment rejection for certificates from non-active issuers. However, it does not explain side effects (if any), return format, or failure modes beyond issuer rejection.

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 compact sentences: the first declares the core action and scope, the second adds cost and production-specific behavior. No fluff or repetition; information is front-loaded and efficient.

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 description covers purpose, cost, and a key environmental behavior, but it does not describe the output/return value, and there is no output schema to fill that gap. Given the complexity of 'end-to-end' verification, an agent would benefit from knowing what the tool returns (e.g., success status, report, reasons for failure).

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 the parameter description ('CausalCertificateV1 object as returned by submit_incident.certificate') is explicit and helpful. The tool description does not add further detail beyond echoing the certificate object, so the baseline of 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 verifies a CausalCertificate end-to-end, listing specific verification dimensions (signature, Merkle integrity, issuer status). This specific verb+resource+scope distinguishes it from siblings like verify_certificate_recompute, which likely has a narrower focus.

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 use for independent verification and mentions production behavior, but it does not explicitly state when to choose this tool over alternatives such as verify_certificate_recompute or query_issuer_registry. No exclusions or alternative comparisons are provided.

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 burden of behavioral disclosure. It covers key traits: costs 1 credit, returns PASS only on exact byte-for-byte match, enumerates the exact fields checked, and clarifies the trust model (no trust in issuer/key). It does not explicitly state what happens on mismatch or whether the operation is read-only, but the nature of a verification/recompute tool makes this implicit.

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 succinct and front-loaded with the core action. It efficiently packs essential information: the verification approach, trust model, cost, and the strict PASS condition with a field list. No superfluous words or redundant 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?

The tool has two complex object parameters, no annotations, and no output schema. The description covers the primary behavior, cost, and success criteria, and it distinguishes the tool from siblings. However, it lacks an explicit comparison to verify_certificate (beyond cost) and does not describe the failure response or edge-case behavior, which would make it fully complete.

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% for both parameters. The schema already describes certificate as 'The CausalCertificate object claimed by the issuer' and canonicalInput as 'the original incident body that produced the certificate — the same JSON originally posted to submit_incident or submit_otel_trace.' The tool description adds no new parameter-level details beyond the schema, so 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 a specific verb and resource: 'Independently re-derive a CausalCertificate from its canonical input and compare byte-for-byte against the claimed certificate.' It also distinguishes itself from the sibling verify_certificate by emphasizing it is the 'strongest verification path' requiring no trust in issuer, making its unique purpose unambiguous.

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 context for when to use this tool over alternatives: it is the strongest verification path and requires no trust in issuer or signing key. It also notes cost equivalence with verify_certificate, implying it can be used as an independent check. However, it does not explicitly state when NOT to use it or name an alternative like 'for standard verification, use verify_certificate'.

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