AuthiChain

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

With no annotations, the description carries the burden of explaining behavior. It discloses that the tool returns a score, gaps, and dated obligations, and adds an important limitation: 'Not legal advice.' It does not detail data handling or side effects, but as a non-mutating readiness check this is adequate.

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?

Three concise sentences: what it is, what it returns, and a key legal disclaimer. Every sentence adds value, and the most important information 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?

Without an output schema, the description sufficiently covers return values. The eight parameters are fully documented in the schema. The main gap is the lack of explicit guidance on how to use the boolean inputs to interpret the score, but this is minor given the schema 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 input schema provides 100% parameter descriptions, including detailed enum meanings for category and clear definitions for each boolean readiness factor. The description adds no parameter-level detail, but none is needed because schema coverage is complete.

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 action ('readiness check') on a clear resource ('EU Digital Product Passport'), and specifies the output: a 0-100 score, gaps, and a dated obligation. This clearly differentiates it from siblings like get_pricing, query_provenance, and verify.

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 when assessing EU DPP readiness, but it does not explicitly state when to prefer this tool over siblings or provide exclusion criteria. The context is clear enough for a basic selection, but no explicit routing guidance is given.

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 usefully discloses that verification is free and that paid plans are on hold, so no prices or Payment Links are returned — real behavioral context about the response contents. It still omits the concrete return shape (empty result vs. message) and whether any auth is needed.

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 key fact ('Free.') and then one compact sentence covering the alternative and the reason no prices appear. Slightly awkward in mixing a tool recommendation with a raw URL, but no wasted sentences.

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 tool with no output schema and no annotations, the description covers the essential context: the resource is free, paid tiers are suspended, and where to go for verification. Only the exact return value of this call remains unspecified.

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 defines zero parameters at 100% coverage, so there is nothing for the description to compensate for. Baseline 4 applies; no parameter detail is needed or missing.

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 name implies a pricing lookup, and the description clarifies the actual state: verification is free and no paid prices or Payment Links exist. However, it never states what the tool itself returns (an empty/absent pricing payload, an explanatory message, or an error), so an agent cannot fully predict the outcome of calling it.

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 explicitly routes the agent to the alternative for the actual task: 'use the verify_record tool, or GET https://authichain.com/api/verify'. That is a clear when-to-use-this-instead signal, though it does not state when get_pricing itself should ever be called.

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 does well: it declares the tool is free, public, non-attesting, and that only the four published packs resolve while any other id returns 'status unknown' because the certificates registry is not yet answering. That is genuine degraded-state and failure-mode disclosure. It stops short of describing the full response shape or any rate/availability caveats.

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?

Three front-loaded sentences with no padding; scope, non-attestation, resolution limits, and the sibling redirect all appear in order of importance with zero boilerplate.

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 single-parameter tool with no annotations and no output schema, the description covers purpose, scope, resolution behavior, failure behavior, and the alternative tool. Only the exact structure of a successful response is left unstated, which is minor for a lookup.

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 assetId description already documents the parameter, giving a baseline of 3. The description earns a point by adding meaning the schema cannot: which concrete identifiers actually resolve (the named packs) and that unrecognized ids yield 'unknown' rather than an error.

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 names a specific verb and resource ('free public lookup for an assetId / seal / QR token') and immediately scopes it ('Never attests'), which cleanly separates it from the sibling verify_record that it explicitly names. An agent can pick between the two without opening either schema.

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 states both when to use it (free public lookup of an identifier) and when to use the alternative ('For free signature and anchor verification use verify_record'). The routing rule is explicit and unconditional.

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 does substantial work: it discloses the GET URL, the response contract (AuthiChain Verification Decision v1), that this host performs signature verification, and the missing-id error (presentation_not_found). It omits auth requirements and rate limits, but the behavioral picture is unusually complete for a read 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?

Four tightly packed sentences, front-loaded with the cost fact and the action, with no filler. The negative scoping is compressed rather than restated.

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?

No output schema exists, so the description wisely names the return contract and the primary failure mode. Combined with full schema coverage for the lone required parameter, an agent has enough to call it correctly; only auth/rate-limit details are absent.

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 single parameter is already described, but the description reinforces the semantics ('stored presentation id' vs. a physical scan) and complements the schema's canonical-form note. Adds meaning beyond the raw schema by tying the id to the error path.

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 ('Scan a stored Living QR'), names the exact endpoint and returns, and explicitly distinguishes itself from adjacent concerns (not an x402 payment endpoint, not physical-product inspection). An agent can identify the tool's function without opening the schema.

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?

Gives positive context ('Free') and negative scoping that rules out two likely misuses, so the agent knows when this is not the right tool. It stops short of naming a specific sibling alternative for the cases it excludes, which keeps it from 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 and does so richly: it discloses exact error codes (400/402/503), the payment semantics (refused before settlement so no payment is taken), and the legacy/not-answering status. This is far beyond what structured fields provide.

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?

It is front-loaded with the tool identity and every sentence earns its place by adding an outcome or the alternative. It is slightly dense with clauses but not padded.

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 that essentially refuses requests, there is no output schema, and the description compensates by describing exactly what each invocation path returns (error codes and the payment-refusal behavior). It is nearly self-sufficient for an agent deciding whether to call this at all.

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 schema already documents sealId as a required UUID while noting productId/serial are not registry keys. The description only reinforces that non-UUID arguments yield HTTP 400, adding marginal value over the schema, so 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 names a specific verb/resource ('Legacy x402 seal verify') and distinguishes itself from the sibling verify_record by directing free verification there. However, the phrase 'not answering' leaves the tool's functional status ambiguous - an agent must infer whether the tool ever succeeds, which slightly blurs the stated purpose.

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 explicitly maps argument conditions to outcomes: bad args -> HTTP 400, empty args -> unpaid 402 for discovery, paid call -> 503 refusal before settlement. It also names the alternative ('For free verification use verify_record'), giving the agent a clear routing decision.

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 does well: it declares the tool is free, enumerates the three possible outcomes (verified, valid-unanchored, invalid) plus the record-hash check, and rules out physical-product inspection. It omits auth requirements and any rate/limit context, but the outcome and cost disclosure is 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?

Front-loads the notable cost fact ("Free.") and then the core action, then input modes, then outcomes, then a scope exclusion. Four tight sentences with no filler; the terse "Free." opener is slightly abrupt but 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?

No output schema exists, and the description compensates by naming the possible results, so an agent knows what comes back. Combined with the free/cost note and the negative scope statement, it covers what is missing from structured fields, with only auth/permission behavior left unaddressed.

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 baseline is 3, but the description adds real meaning the schema lacks: it clarifies that `id` selects the single published demo record while `record`+`anchor` is the bring-your-own path, and tells the agent these are alternative input modes rather than independent fields.

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: verify an AuthiChain signed provenance record with the open reference verifier, and explicitly says it does not inspect a physical product. That scope is clear, but it never distinguishes itself from the sibling tool `verify` (and `query_provenance`), so an agent cannot tell the two apart from the text alone.

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 gives per-parameter usage branching: pass "polygon-anchor-1" for the demo record, or pass your own record plus anchor JSON. However, it never says when to choose this over `verify` or `query_provenance`, which is the main routing decision an agent faces here.

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