eudr

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

The description carries an unusual and important disclosure that the annotations cannot: readOnlyHint=false is explained by "The first call for an organisation writes: it opens the wallet, grants the welcome credits and records that grant as the opening ledger line. Every call after that only reads," which also justifies idempotentHint=true and destructiveHint=false. Return format and any ledger detail are left to the output 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?

Front-loaded with what is reported, then the cost model, then the first-call write nuance. Every sentence carries distinct information, though the free-vs-paid sentence and the write-behavior sentence are doing overlapping work that could be tightened slightly.

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?

An output schema exists, so return values need not be described. The description covers the cost model, the free/paid boundary, the one-time write on first call, and the recommended call timing — everything an agent needs to invoke it correctly and interpret when it mutates state.

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 takes zero parameters, so per the scoring baseline the schema imposes no documentation burden; there is nothing for the description to clarify about inputs. No credit or penalty beyond the baseline.

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 (report) and resource (this organisation's credit balance) and enumerates the exact contents: balance, number of signed statements covered, and spend. It is clearly distinguishable from siblings like eudr_export_statement or eudr_compliance_status without opening any 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?

Explicitly tells the agent when to call it ("Use this before starting a batch of compiles") and why (so the user is not surprised part-way through). It also draws the operational line between free operations (checking plots, lookups, gap assessment, traces) and the one operation that consumes balance, which is exactly the guidance needed to route between this tool and the compile-related siblings.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real substance beyond them: it discloses the output's structure (unmet items with article reference and recommended follow-up, split into filing-blocking vs. merely-incomplete), and explicitly scopes its own authority by stating it does not read documents or judge evidence. It omits any note on the 50-supplier batch cap, which is the one remaining behavioral 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?

Three sentences, each earning its place: the first states purpose and legal anchor, the second states the return shape, the third states scope limits. The most important information (what is missing per supplier) is front-loaded, and there is no filler or restatement of the title.

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?

Low-complexity, single-input, read-only tool with a 100%-documented schema and an existing output schema, so the description need not explain return values—and it still sketches them usefully. It is essentially complete; only the batch-size ceiling and explicit sibling routing are left to structured data or inference.

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% and there is effectively one top-level parameter, with each nested field already documented including article mappings (e.g. email/address for Article 9(1)(e), scientific_name for 9(1)(a)). The description says 'checklist over the fields you supply' but adds no field-level meaning beyond the schema, 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?

Specific verb ('Check what each supplier's file is still missing') plus a precise, normatively-anchored resource (Article 9(1) of Regulation (EU) 2023/1115), and it names the deliverable ('returns the unmet items with their article reference'). It is clearly distinguishable from siblings like eudr_fetch_evidence or eudr_request_supplier_evidence because it is a gap analysis, not a fetch or a request.

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 closing sentence establishes a clear boundary of applicability: it is a checklist over supplied fields, reads no documents, and judges no evidence, which tells the agent not to reach for it when document inspection or evidentiary judgment is needed. It stops short of naming the alternative tools (e.g. eudr_fetch_evidence) for those cases, so it is clear context without explicit routing.

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?

Annotations already flag non-read-only, open-world, non-idempotent behavior, and the description adds substantial context beyond them: no organisational records are written, no credits are consumed, calls generate freshly signed measurements, repeated checks return the same finding under new signatures, and a 24-hour evidence handle is minted that later checks will not reproduce. This is consistent with and much richer than the annotations.

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 well front-loaded: purpose first, then return values, scope exclusions, and side effects. Some return-value detail overlaps the output schema and the final sentence is long, but almost 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 a rich output schema and annotations, the description fills the remaining gaps an agent needs: exact scope, exclusions, side effects, evidence-handle lifetime, and the fact that repeated checks do not reproduce the same handle. It is complete enough to call correctly and interpret the result.

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 all parameters and constraints are already documented in the schema. The description only restates the main inputs (GeoJSON boundaries, commodity, country) and the six-plot limit, adding no syntax or constraint detail beyond what the schema provides.

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, resource and regulatory scope: check up to six production plots for forest loss after 31 December 2020. It clearly bounds the tool to Article 3(a), though it does not explicitly name the sibling tool to use for larger consignments or broader compliance 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?

Gives clear when-to-use context (up to six plots, forest-loss check after the EUDR cut-off) and explicit when-not coverage by excluding land tenure, permits, consent and chain of custody. It names eudr_fetch_evidence only as the resolver for the returned evidence handle, not as an alternative for other compliance assessments, so alternatives are not fully routed.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by specifying the content of the summary (counts by commodity/country, supplier evidence requests) and its scoping to the signed-in organisation. It does not disclose any hidden limitations, but none are expected for a read-only summariser.

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 sentences, front-loaded with the core purpose, and every clause adds value (specific counts, breakdowns, the non-enumeration caveat). No fluff or repetition of structured fields.

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 an output schema, the description is complete: it states what the tool does, what it returns (counts, breakdowns, supplier requests), and its scope (signed-in organisation). The only minor missing piece is an explicit reference to a sibling like eudr_list_statements, but the 'without enumerating' phrasing covers that.

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 schema coverage is trivially 100% and the baseline is 4. The description adds no parameter-specific detail (there are none to add), but it clarifies what the invocation accomplishes, which is appropriate for a parameterless tool.

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

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

The description states a specific verb ('summarise'), a resource ('the signed-in organisation's position'), and enumerates exactly what is summarised (filable, blocked, unresolved statements; supplier evidence requests; breakdowns). It explicitly differentiates from enumeration tools by saying 'without enumerating every record', distinguishing it from siblings like eudr_list_statements.

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: when an overview is needed rather than a detailed listing, as indicated by 'Answers "where do we stand" without enumerating every record.' It implies alternatives for enumeration but does not explicitly name them or state when not to use this tool, so it stops short of a full exclusion.

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?

Beyond the annotations (write, open-world, non-idempotent, non-destructive), the description discloses the actual side-effect chain: country auto-derived from the land, forest record warmed, and the EUDR land check triggered when the crop is covered; with only a pin, mapped fields are merely suggested for human acceptance. That is materially more than the annotations convey.

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 core action, then dense but purposeful detail on geometry input and cascade behavior; almost every sentence earns its place. The one long mid-paragraph sentence about what 'runs at once' is somewhat run-on and forces a re-read.

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?

An output schema exists, so return values need no explanation, and the description covers required vs optional inputs and cascading effects well. Gaps remain around permissions/auth and what happens on a duplicate create (idempotentHint is false but duplicates go unmentioned).

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 would be 3, but the description adds semantics the schema does not: how `fields` are joined by closing bunds and tracks, what `join_m` achieves in practice, and that `crop` decides whether the EUDR rules apply. It adds genuine meaning on top of the field-level 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?

States a specific verb and resource ('Add a farm to this organisation's record') plus the conditional scope 'with its boundary if known', so the agent knows this is a create operation that may also ingest geometry. It never names the obvious sibling (eudr_set_farm_boundary) to draw the line between creating-with-boundary and attaching a boundary later, so sibling differentiation is only implied.

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 gives real context for input choice: 'a name is enough', give a pin 'when no boundary is known', and boundary or fields when the outline exists. However it offers no tool-level guidance — nothing tells the agent when to call this versus eudr_set_farm_boundary or eudr_list_farms, and no prerequisites or exclusions are stated.

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 all annotation hints false, the description carries the full burden of behavioral disclosure, and it does so richly. It explains what is returned (decision per destination, chain-hold chance, P10/P50/P90 margin, max payable price, deal zone, farmer message without walk-away price), that defaults are surfaced as stated assumptions, that other crops are refused, and that the run is stored as a decision for later outcome recording. This gives the agent an unusually complete picture of the tool's behavior.

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 long, but nearly every sentence carries a distinct piece of needed information: outputs, defaults, crop restriction, persistence, and input sourcing. It is front-loaded with the core decision output before adding constraints and input guidance. A small amount of density prevents a perfect score, but there is no wasted content.

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 high complexity — nested lot object, multiple output dimensions, and no meaningful annotation hints — the description is complete enough for an agent to call it correctly. It covers inputs and their source, crop restrictions, what happens with defaults, the output categories, and the persistence side effect. Since an output schema exists, the description does not need to enumerate return fields.

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 meaningful semantics beyond the schema. It directs the agent to send `lot` in the shape of `lot_example` from `eudr_procurement_overview`, and it clarifies an important interaction: the crop is taken from the farm's own record, not necessarily from the lot payload. This materially helps the agent construct correct arguments.

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 and resource: 'Run the organisation's own buying process on a banana lot from one of its farms.' It goes beyond the title by specifying the concrete outputs per destination (GO / GO WITH CONDITIONS / NEEDS A PERSON / NO-GO, margins, price ceiling, deal zone) and the explicit 'Banana only' scope, which separates it from the other procurement/evidence tools in the sibling list.

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 gives clear context for when to use the tool: on banana lots from one of the organisation's farms, and it provides an explicit exclusion ('other crops are refused by name'). It also tells the agent where to get a valid `lot` shape: `lot_example` from `eudr_procurement_overview`. It does not name alternative tools or give a when-not-to-use scenario, but the crop constraint and input sourcing guidance make the intended use clear.

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?

Even with readOnlyHint, idempotentHint, and destructiveHint already declared, the description adds valuable behavioral detail: it lists the exact stages in order, explains that absent evidence is reported as absent with a reason, and reveals provenance details such as three independent signing keys. This substantially exceeds the annotation baseline.

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 sentences with no filler. The first sentence front-loads the tool's purpose and enumerates the derivation chain compactly; the second adds a key behavioral trait and usage guidance. Every clause 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 read-only trace tool with one well-documented parameter and an output schema, the description covers purpose, ordering, evidence-absence behavior, and when to use it. No critical operational context is missing.

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%, and the task_id parameter is already well documented in the schema as the ID of a compile that produced a statement. The description does not need to add parameter-level detail and does not attempt to, so the baseline score 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 states a precise purpose: it shows the complete derivation chain behind a compiled statement, with the steps in order. It explicitly frames the tool as answering how a result was reached, clearly distinguishing it from tools that report what the result is.

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 last sentence provides a clear usage trigger: use this tool when someone asks how a result was reached rather than what it was. It does not name a specific alternative tool, but the 'rather than what' contrast gives useful 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safe/read-only nature is covered. The description adds the key behavioral nuance that exporting is not filing and introduces the conditional refusal for non-negligible verdicts when exporting to TRACES. This is valuable context beyond the annotations and does not contradict them.

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 sentences with zero filler. The first sentence front-loads the action and output formats; the second adds the filing clarification and the refusal condition. Every clause carries necessary information, and the structure is ideal for quick agent scanning.

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 three parameters, an output schema, and strong annotations, the description provides all necessary operational context: what the tool does, what it doesn't do (filing), and a critical edge case (refusal). The output schema covers return shapes, and parameter details are fully described in the schema. Nothing essential is missing for correct invocation.

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 every parameter is already explained in the input schema. The description repeats the format names and mentions 'signed' for JSON and 'FeatureCollection' for GeoJSON, but these details are also present in the schema descriptions. The description does not significantly add semantic value beyond what the schema already provides, justifying the baseline of 3.

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 (export) on a specific resource (a compiled statement) and enumerates the three concrete output formats (TRACES NT submission XML, signed Annex II JSON, plot boundaries as GeoJSON). It also clarifies that this is not filing, distinguishing it from submission-oriented tools. This is precise and sets it apart from siblings like eudr_list_statements or eudr_prepare_dds.

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 states that exporting is not filing and nothing is submitted to any authority, which tells the agent when not to use this tool for filing purposes. It also warns that TRACES export is refused for a non-negligible verdict, implying an alternative format might be needed. However, it does not explicitly name alternative tools or provide explicit 'use this instead' guidance for the refused case, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: pagination ('a page at a time'), the fact that each entry is a content address resolving at emem.dev, and offline verification against the responder's key. This goes beyond the annotations and helps the agent understand the nature of the returned data.

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, each earning its place: the first states the core action and mechanism, the second explains the nature of the data, and the third gives usage guidance. It is front-loaded with the most important information and has 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 moderate complexity (3 params, 1 required, output schema present), the description covers the key aspects: what it does, how to use it, when to use it, and the nature of the returned data. The output schema likely explains return values, so the description doesn't need to. The only minor gap is that it doesn't explicitly mention pagination parameters (limit/offset), but the schema covers those, so this is not a significant omission.

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 three parameters. The description adds the key semantic link that evidence_cid is 'the handle returned by eudr_check_plots', which is useful context beyond the schema's 'The handle returned by eudr_check_plots' (though the schema already says this). The description doesn't add much beyond the schema, 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 states a specific verb ('Retrieve'), a specific resource ('signed satellite facts behind a completed check'), and a specific mechanism ('a page at a time, using the evidence_cid'). It also explicitly distinguishes itself from summarising a result, which helps differentiate it from sibling tools like eudr_compliance_status or eudr_execution_trace.

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 explicitly says when to use this tool: 'when someone needs to audit or cite the evidence, not to summarise a result.' This provides a clear usage context and an exclusion, which is strong guidance for an agent deciding between this and sibling tools.

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?

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real behavioral detail the annotations don't cover: the two-phase return behavior (transient state vs. final verdict plus content address and signing key). It doesn't mention polling cadence, terminal-state signaling, or failure/expiry behavior, which keeps it at 4 rather than 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?

Three short sentences, front-loaded with the core action, then lifecycle behavior, then a pointer to the sibling for the printable output. Nothing is redundant or 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?

An output schema exists, so return values needn't be enumerated, yet the description still tells the agent what each phase yields and where the printable statement actually comes from. For a one-parameter polling tool, an agent has everything needed to invoke and interpret it.

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's description already says it is 'the task_id returned by eudr_prepare_dds.' The description restates that provenance ('started by eudr_prepare_dds') but adds no format, lifetime, or reuse semantics, so the schema is doing the work.

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 (read the state) and resource (a compile started by eudr_prepare_dds), and names the originating sibling tool so the agent knows where the task_id comes from. It also implicitly separates itself from eudr_export_statement by pointing at the report_url for the printable statement.

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 two-phase framing ('while it runs… once finished…') clearly implies a polling pattern and tells the agent what to expect on each call. It stops short of stating explicitly that the tool should be called repeatedly until a terminal state, or naming rate/cadence expectations, so it's clear but not fully directive.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral guarantees beyond that: 'Nothing is stored and nothing is submitted; this only reads the document you pass,' plus the promise of per-row warnings for unreadable records. This gives the agent a precise side-effect and partial-failure model.

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 sentences, no filler, with the core action and accepted formats front-loaded, followed by output semantics and safety behavior. Every sentence earns its place; the title is redundant but harmless.

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, combined with rich annotations and an output schema, fully equips an agent to call the tool correctly: it knows inputs, output fields, failure behavior, read-only guarantees, and limits. Nothing essential is missing.

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 parameter descriptions already document format, document, limit, and offset fully. The description adds useful framing like 'the column set eudr.dev publishes' and 'GS1 EPCIS 2.0 JSON-LD document,' but these largely echo what the schema provides. It does not materially improve parameter understanding 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 names a specific verb and resource: 'Parse a consignment list into structured shipments ready to check.' It explicitly states the accepted input formats (CSV export or GS1 EPCIS 2.0 JSON-LD) and the output shape (rows with supplier, commodity, country, quantity, plot boundaries, plus warnings). This distinguishes it from sibling check, evidence, and statement tools.

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 makes the usage context clear: use it when you have a spreadsheet or GS1 event feed that needs to become structured shipment records. The explicit 'Nothing is stored and nothing is submitted' also signals that this is safe pre-check ingestion. It does not name alternatives or state when not to use it, but the context is strong enough for an agent to select it appropriately.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description restates 'Read-only' (redundant) but adds genuinely non-structured detail about the area field being geodesic with holes subtracted. With annotations carrying the behavioral burden, a 3 is appropriate.

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?

A single dense sentence that front-loads the verb and resource before listing fields. It is slightly overloaded with parenthetical detail ('geodesic, holes out'), but every clause carries information and nothing is padding.

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?

With no parameters, full annotation coverage and an output schema present, this definition is essentially complete. The description even summarizes the return fields, which the output schema would have covered anyway, leaving no meaningful gap for an agent.

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 takes zero parameters, so there are no parameter semantics to explain. The description compensates by documenting the shape of the result set instead, which is the relevant information at this call site.

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 ('List the farms in this organisation's record') and enumerates the fields returned, so the agent knows exactly what it gets. It does not explicitly differentiate itself from siblings such as eudr_check_plots or eudr_compliance_status, but the resource is 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives among the 20 sibling tools. The 'Read-only' note hints at safe retrieval, but an agent gets no help deciding between this and tools like eudr_check_plots or eudr_compliance_status.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds useful scope (organisation account, newest-first ordering) and listed return fields, but does not mention pagination limits or that limit filters results; with an output schema present, a 3 is appropriate.

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 action and scope, then the use case. No filler; length is proportionate.

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 read-only, idempotent list tool with an output schema and fully described parameters, the description is almost complete. It could mention that results are limited by default or how to paginate, but no critical information for correct invocation is missing.

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 describes each parameter (limit default 20, country pattern, verdict enum) plus the output schema. The description adds nothing about parameter semantics beyond the schema, so baseline 3 is correct.

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

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

The description states a specific verb (list) and resource (Due Diligence Statements), scopes it to the signed-in organisation, and enumerates the returned fields (verdict, reference, commodity, country, quantity, date). It is clearly distinguished from siblings like eudr_get_dds (single fetch) and eudr_prepare_dds (create).

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 gives a clear context for use: answering what has been filed, what is outstanding, and what a past consignment concluded, and explicitly discourages re-entering details. It does not name a specific sibling alternative (e.g. use eudr_get_dds for one statement), but the when-to-use is otherwise specific.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that each record carries a response status and an expiry timestamp, which is helpful domain context. It says nothing about ordering, pagination, or whether expired requests are included, which is the main remaining behavioral 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?

Two sentences, both front-loaded, with no repetition of the title or annotation content. The scope statement comes first and the business question it answers comes second, which is the right order for scanning.

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?

With an output schema present, no parameters, and full annotation coverage, the description need only convey scope and intent, which it does. The only missing piece is guidance on how the returned request list relates to the gap-assessment workflow, which would help an agent choose between the two tools.

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 takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate and no risk of mis-invocation from undocumented arguments. It correctly does not invent parameters or filtering options.

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 ('List the supplier evidence requests this organisation has issued') and adds the exact fields returned: requester, response status, and expiry date. It implicitly contrasts with eudr_request_supplier_evidence by focusing on already-issued requests, but never names that sibling or any other alternative explicitly.

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 phrasing 'Answers which suppliers still owe plot boundaries and production details' implies the scenario in which to reach for this tool, which is useful. However, there is no explicit when-to-use/when-not statement and no pointer to a related tool such as eudr_assess_evidence_gaps, so the agent must infer the choice.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-redundant behavior: provenance (source regulation, UN Comtrade 2023, World Bank indicator prices) and the fact that it returns a verification date, which signals a static snapshot rather than live data. Missing only pagination or table-size behavior, hence not 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?

Two sentences, front-loaded with the verb and the four branches, then the return contract. It is dense and could be broken into a bulleted list for the four kinds, but nothing is filler and the scope is stated before the return behavior.

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?

Output schema exists, so return structure need not be explained, yet the description still adds the source/verification-date contract. With full param coverage and clear enum routing, the only material omission is guidance on when in a compliance workflow to reach for this lookup versus the assessment siblings.

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 baseline is 3. The description restates the four kind branches but adds no syntax or format detail beyond what the enum descriptions already carry; the regulatory citations enrich context but not parameter meaning. The optional country/commodity narrowing is documented only 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?

States a concrete verb ('Look up') and enumerates the four distinct reference tables (country risk tiers, Annex I HS-code mapping, UN/LOCODE ports, trade lanes) with their governing regulations. An agent can immediately tell this apart from the operational siblings like eudr_compliance_status or eudr_check_plots, which assess data rather than fetch the static tables the engine evaluates against.

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 four 'kind' branches imply the usage context (reference data underlying the engine), but there is no explicit when-to-use, when-not-to-use, or naming of any alternative tool. An agent must infer that this is the lookup layer for values returned by the compliance tools, rather than being told to consult it before/after running an assessment.

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?

Even though readOnlyHint and destructiveHint already cover safety, the description adds value beyond annotations: it clarifies that only open plans are returned, explains what the report contains, and discloses why recording is not possible here (Article 11(3) documentation, named-person attribution). This is substantive behavioral context rather than a restatement.

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 front-loaded with the core purpose and the parameter guidance is placed before the regulatory rationale. Every sentence adds information, though the final sentence about eudr.dev and 'our choice rather than the Regulation's wording' could be tightened.

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 output schema and annotations, nothing an agent needs to use the tool correctly is missing: it covers the report's contents, the one-vs-all parameter behavior, and the read-only boundary. The regulatory context also helps the agent judge whether this is the right tool for the user's intent.

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 describes shipment_id as optional and explains the omit behavior, so coverage is 100%. The description repeats the same guidance without adding new detail such as formats or examples, so it stays at the baseline 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 is built around a specific verb, 'Report', a precise resource ('Article 11 risk-mitigation plans ... open against flagged shipments'), and enumerates the exact content (outstanding steps, discharged article, automation, evidence). This makes it easy to distinguish from sibling tools such as eudr_compliance_status or eudr_execution_trace.

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 explicit invocation guidance: 'Pass a shipment id for one plan, or omit it for everything still open', and states the read-only boundary with recording deliberately delegated to eudr.dev. It does not name any sibling tool as an alternative, but the context ('this answers how far that has got') clearly frames when to call 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?

Goes well beyond the annotations: which fields are forwarded to the external provider and which are withheld (operator/supplier identity), that a revocable 7-day share link is minted for organisations, that nothing is filed with an authority, and the credit cost with refund-on-failure. This substantially softens the destructiveHint=true alert by explaining what is and is not actually at stake.

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 write semantics and outcome path before the secondary share-link and pricing detail, and nearly every sentence carries operational weight. The dated credit-pricing clause is verbose, though it is real cost information an agent should surface.

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 costly, non-idempotent, externally-visible mutation with nested parameters, the description covers the async task model, the follow-up tool, privacy boundaries, billing, and the reassurance that no regulatory filing occurs. An output schema exists, so not explaining the return shape beyond 'a task handle' is acceptable.

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 already 100%, so the baseline is 3; the description adds a genuinely useful data-flow layer by naming exactly which inputs (plot geometry, HS code, country, quantity) leave the system, which no field description states. It does not, however, explain the operator/supplier/product/geolocation split beyond what the schema already documents.

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 artefact ('Compile and sign an Annex II Due Diligence Statement') and immediately frames it as the start of a task whose outcome is read elsewhere. An agent can distinguish it from eudr_get_dds and eudr_export_statement from the description 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?

Explicit handoff ('read the outcome with eudr_get_dds') and an explicit interaction rule ('Confirm the details with the user first'), plus a cost contrast against every other free tool. It stops short of saying when to use it instead of prerequisite siblings like eudr_check_plots or eudr_assess_evidence_gaps before compiling.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds behavioral context by specifying the scope ('across this organisation's farms'), the decision statuses included, and the fact that it includes both recorded outcomes and overridden decisions. It doesn't describe pagination or return format, but the output schema exists and the description is otherwise transparent.

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 sentences, front-loaded with the core listing purpose, then the decision statuses, then the use cases. Every sentence earns its place; no fluff or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only tool with an output schema, the description is complete. It tells the agent what data is returned, how to use it (find farm id, review outcomes), and that it is safe to call. Nothing essential is missing.

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 schema is trivially complete. The description adds meaning by explaining what the returned data represents (farms and buying decisions with statuses), which is more than the empty schema provides. Baseline for 0 params is 4, and the description earns 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 tool lists the organisation's farms and recent buying decisions with specific decision outcomes (GO / GO WITH CONDITIONS / NEEDS A PERSON / NO-GO), and notes which have recorded outcomes and which were overridden. It distinguishes itself from siblings by naming eudr_decide_lot as a follow-up use case.

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 explicitly says when to use it: to find a farm id before eudr_decide_lot, or to see how decisions have turned out. It also states it is read-only, which helps an agent avoid using it for mutation purposes. It doesn't explicitly name alternatives to avoid, but the use cases are clear enough.

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?

Annotations already declare readOnlyHint false, and the description reinforces this by saying 'This writes: it creates a credential'. It further discloses that the link is one-time, returns only once, and that no email is sent—providing valuable behavioral context beyond the annotations.

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 compact, front-loads the core action, and includes critical caveats in just a few sentences. Every sentence contributes value without redundancy.

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 output schema exists and annotations cover safety, the description is complete. It explains the purpose, write nature, one-time behavior, and the no-email detail, covering everything an agent needs to decide and 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 description coverage is 100%, so the schema already documents all parameters clearly. The description adds no additional parameter meaning (e.g., it does not elaborate on valid_for_days or email beyond what the schema says). 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 states a specific verb ('Create') and resource ('one-time link'), and clearly explains the purpose: letting a supplier submit evidence without an account. It differentiates from siblings like eudr_list_supplier_requests (listing) and eudr_fetch_evidence (fetching) by its action and context.

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 this tool (when you need to collect evidence from a supplier) and adds cautions ('Send it only to the intended supplier', 'No email is sent'). However, it does not explicitly name alternatives or state when not to use it, so it lacks 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?

Annotations already declare destructiveHint=true and idempotentHint=false; the description goes further by stating exactly what is destroyed (the previous outline stops being the boundary), what the effects are (compliance answers and area change), that the superseded outline is kept in history, and that the call does not undo on its own. This is rich behavioral context beyond the annotations.

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 core action and modes, then sequences consequences and warnings. Somewhat dense with subordinate clauses, but every sentence carries load. Not maximally tight but appropriate for the complexity.

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 an output schema, so return values need not be explained. The description covers the mutation, its destructive effects, history retention, and a user-confirmation warning, which is complete for a destructive, non-idempotent 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 coverage is 100%, so baseline is 3. The description adds interpretation of 'boundary' vs 'fields' (GeoJSON Polygon/MultiPolygon, joining into one farm) that helps the agent understand the semantics, though it largely restates what the schema already documents.

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+resource ('set the boundary of a farm') and distinguishes the two input modes (boundary vs fields) that map to the siblings eudr_create_farm context. Differentiated from other tools by clarifying it acts on an existing farm in the record.

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?

Explains the two modes of providing input, references eudr_create_farm for farm creation, and includes an explicit precondition ('confirm with the user before overwriting a boundary somebody else set'). This is when-to-use guidance with an exclusion/warning.

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?

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavioral nuance: a valid signature establishes who signed and that bytes are unchanged, but 'does not establish that the claim inside is true.' This helps the agent set correct expectations and avoids overinterpretation of verification 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?

Three sentences, no redundant filler, and the core operation is front-loaded. Each sentence earns its place: what it does, when to use it, and what the result does and does not mean.

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 a single parameter with full schema coverage and an output schema, so return details need no elaboration. The description covers operation, use case, and important interpretive caveats—everything an agent needs to invoke and interpret this tool 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 the baseline is 3. The description adds value by explaining how the receipt fields are used: re-deriving the content address from the canonical payload and checking the ed25519 signature. This gives semantic meaning to fields like canonical_b64 and signature_b64 beyond their names.

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

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

The description states a specific verb and resource: 'Verify a statement receipt' and goes further by explaining the mechanism—'re-derive its content address from the canonical payload and check the ed25519 signature.' This clearly distinguishes the tool from sibling statement-management tools.

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 gives clear context: 'Use it on a receipt a counterparty hands you.' It indicates the intended input source and scenario, though it does not explicitly name alternative tools or state when not to use it. This is a clear usage context but lacks formal exclusions.

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