eudr

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

Annotations only indicate idempotentHint=true and readOnlyHint=false, but the description adds critical nuance: the first call for an organisation writes (opens wallet, grants credits, records ledger line), while all subsequent calls are read-only. This is beyond what annotations convey and is essential for correct usage.

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 yet information-dense. Each sentence serves a purpose: the first defines output, the second lists free operations, the third gives usage guidance, and the fourth clarifies the write-on-first-call behavior. It is front-loaded with the core purpose and avoids fluff.

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 no parameters and an existing output schema (not shown but present), the description fully covers what an agent needs: the tool's purpose, when to use it, side-effect behavior, and cost implications. No critical information is missing for a tool of this simplicity.

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

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

There are zero parameters and the schema coverage is 100%, so no parameter documentation is needed. The description focuses on output content and usage context instead, which is appropriate. Baseline for zero params is 4, and the description adds no param-specific details (none needed).

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 opens with a precise statement of what the tool reports: credit balance, signed-statement coverage, and spent amount. It clearly differentiates from sibling tools by focusing on wallet/account status rather than on specific actions like checking plots or looking up references, naming those free operations 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?

Explicit guidance is given: 'Use this before starting a batch of compiles so the user is not surprised part-way through.' It also clarifies which operations are free versus which draw down the balance, giving the agent a concrete decision rule for when to invoke this tool.

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, openWorldHint=false, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context: it separates blocking vs non-blocking gaps, and explicitly states it is a checklist over supplied fields, reading no documents and judging no evidence. This goes 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?

Three sentences, each earning its place. The first states the core function and legal basis, the second describes the output and its blocking/non-blocking distinction, and the third sets expectations about scope. No fluff, no repetition of schema 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 a rich input schema (15 properties) and an output schema, but the description is still complete enough for an agent to decide whether to call it. It explains the legal basis, the output format, and the scope limitation. It doesn't explain the exact mapping of Article 9 items to schema fields, but that is likely in the output schema or the tool's internal logic. Given the annotations cover safety and the description covers purpose and scope, a 4 is appropriate.

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 0%, so the description must compensate. The description explains the purpose of the 'suppliers' parameter implicitly: it is the set of fields to check against Article 9. It also clarifies that the tool operates on the supplied fields, not on external documents. However, it does not enumerate the specific fields or explain how the checklist maps to the schema properties, so it doesn't fully compensate for the 0% 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 states a specific verb ('Check'), a precise resource (each supplier's file against Article 9(1) of Regulation (EU) 2023/1115), and the exact output (unmet items with article reference and what to request). It also distinguishes itself from siblings by clarifying it is a checklist over supplied fields, not a document reader or evidence judge.

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 when to use it: to find missing Article 9 information per supplier before filing. It also gives an exclusion: 'it reads no documents and judges no evidence,' which implies it should not be used for document analysis or evidence quality assessment. It does not explicitly name alternative sibling tools, but the context is 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?

Discloses side effects beyond the annotations: fresh signed measurements on every call, same finding under new signatures, a short-lived evidence handle retained for 24 hours, no writes to organisation records, and no credit cost. This goes well beyond readOnlyHint=false and idempotentHint=false.

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 tool's purpose, then return values, scope limits, and side effects in a compact sequence. Every sentence carries distinct information and there is no padding or repetition of schema 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 output schema exists and annotations cover safety, the description supplies the missing operational context: side effects, evidence-handle lifecycle, scope limitations, and the meaning of repeated calls. An agent has enough to invoke and interpret the 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 schema already documents all parameters. The description adds contextual framing around GeoJSON, commodity, and country, but it does not materially extend the meaning of individual parameters beyond what the schema provides. 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?

States a specific verb ('Check'), a precise resource (up to eight production plots), the legal threshold (forest loss after 31 December 2020), and the key inputs (GeoJSON, commodity, country). It is clearly distinguishable from siblings like eudr_fetch_evidence and eudr_assess_evidence_gaps.

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 scopes the tool to Article 3(a) and names what it does not check (land tenure, permits, consent, chain of custody), which helps an agent decide when this is insufficient. It does not name sibling alternatives for those other checks, but the boundary is 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=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?

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds meaningful behavior beyond that: it returns current state while running, and once finished returns the verdict, receipt content address and signing key, and printable statement link. This lifecycle detail is valuable and does not contradict 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?

Three short sentences with no filler: the purpose is stated first, followed by the running-state behavior and the finished-state outputs. Every sentence earns its place, and the description is appropriately sized for a simple polling tool.

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-parameter polling tool with an output schema and strong annotations, the description fully covers when to call it, what happens during execution, and what the final result contains. Nothing essential is missing 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 description coverage is 100% and the single parameter task_id is already well-documented by the schema ('The task_id returned by eudr_prepare_dds'). The tool description only repeats the same provenance ('started by eudr_prepare_dds') without adding new parameter-level details, so the baseline of 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 ('Read') and resource ('the state of a compile started by eudr_prepare_dds'), making it immediately distinct from siblings like eudr_prepare_dds (which starts the compile) and eudr_export_statement (which presumably handles the final statement). It also clarifies the two-phase result, so the agent knows exactly what the tool does.

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 places the tool in a workflow: call it after eudr_prepare_dds, while the compile runs, and read the final artifacts once finished. It does not explicitly name alternatives to exclude (e.g., 'for exporting, use eudr_export_statement'), but the workflow context is unambiguous enough for an agent to select this tool correctly.

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 adds useful behavioral context beyond the annotations: it returns results 'newest first', includes a specific set of fields, and scopes to the signed-in organisation's account. It doesn't mention pagination or rate limits, but the output schema exists and the read-only nature is fully disclosed, so a 4 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 with zero waste. The first sentence front-loads the core action, scope, ordering, and returned fields. The second sentence gives 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 list tool with an output schema, the description is nearly complete. It covers what is returned, the ordering, the scope, and when to use it. The only minor gap is that it doesn't explain the verdict parameter's meaning or mention pagination behavior, but the output schema and annotations cover most of the context an agent needs.

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 67%, so the schema already documents limit and country. The description adds no new meaning for the parameters themselves; it only lists the fields returned. The verdict parameter has an enum but no description in the schema, and the description doesn't explain it either. With 67% coverage, the description doesn't need to compensate heavily, but it also doesn't add value 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'), a specific resource ('Due Diligence Statements'), and a clear scope ('in the signed-in organisation's account'). It also names the exact fields returned (verdict, reference, commodity, country, quantity, date) and the ordering (newest first), which distinguishes it from sibling tools like eudr_get_dds and eudr_export_statement without needing to open their schemas.

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 tells the agent when to use this tool: 'Use this to answer what has been filed, what is outstanding, and what a past consignment concluded'. It also gives a clear exclusion: 'rather than asking the user to re-enter details their account already holds'. This is strong usage guidance that routes the agent away from unnecessary user interaction.

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 safety profile is covered. The description adds useful behavioral context about the response content and the outstanding status, going beyond what annotations alone 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?

Two concise sentences, with the core listing behavior front-loaded and the follow-up purpose sentence adding value. No filler or 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?

For a zero-parameter read-only list tool with an output schema and comprehensive annotations, the description covers the key information an agent needs: what is listed, who it reports on, and the relevance to outstanding evidence gaps.

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 leaves nothing to document. The description correctly focuses on the tool's scope and output rather than inventing parameter semantics.

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 'List' and the resource 'supplier evidence requests this organisation has issued', and specifies the information returned: who was asked, whether they responded, and expiration dates. It also distinguishes itself from related sibling tools by focusing on outstanding requests and the practical question of which suppliers still owe data.

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: to determine which suppliers still owe plot boundaries and production details. It does not explicitly name alternatives or exclusions, but the sibling context makes the intended use 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 the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond those annotations: the result is the authoritative table actually used by the engine, with its source and verification date. No contradiction exists, and no additional behavioral risks need to be disclosed for a read-only lookup.

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 focused sentences with no redundant phrases. The first sentence front-loads the tool's purpose and legal context; the second explains the return value's provenance. Every clause earns its place, and the structure is easy to scan.

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 read-only lookup with two well-documented parameters, an output schema, and strong annotations, the description is complete. It covers both supported kinds, states the authoritative nature of the result, and mentions source and verification date. There are no obvious gaps an agent would need filled 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?

Input schema coverage is 100%, and both parameters have clear descriptions including the enum values and the country pattern. The description reinforces the two modes by naming the underlying regulations, but it does not add substantive parameter semantics beyond what the schema already provides. 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 two precise resources, the country benchmark tier under Regulation (EU) 2025/1093 and the Annex I commodity-to-HS mapping under Regulation (EU) 2023/1115, and attaches a specific verb ('Look up'). It also states what is returned, the authoritative table with source and verification date. It clearly distinguishes itself from the action-oriented siblings like eudr_import_shipments or eudr_assess_evidence_gaps.

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 intended use obvious: look up reference data used for EUDR compliance. It provides clear context about both lookup modes and emphasizes that the returned table is the one the engine actually evaluates against, which helps an agent treat it as authoritative. It does not explicitly name alternatives or exclusions, 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 and idempotentHint=true. The description reinforces this with 'Read-only' and goes further by explaining the human-only decision recording workflow and the legal requirement. This adds contextual depth beyond the annotations, with no contradiction.

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 and information-dense. It front-loads the core purpose, then the parameter behavior, then the read-only rationale. Every sentence adds value: legal context, outputs, and usage exclusions. No fluff, clear structure.

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 query tool with one optional parameter and an output schema, the description covers purpose, scope, parameter semantics, the read-only constraint, and the legal backdrop. An agent has everything needed to decide when to call it and what to expect. No gaps.

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

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

The input schema has a single optional parameter, fully described ('Optional. One shipment's plan; omit for every open plan.'). The description essentially repeats this usage. Since schema coverage is 100%, the description adds little over the schema, but it does integrate the parameter into the broader usage guide. Baseline 3 is appropriate.

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

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

The description clearly states the tool reports Article 11 risk-mitigation plans, enumerates the specific outputs (which steps are outstanding, which article each discharges, automation vs. human step, evidence recorded), and defines scope via flagged shipments. This is a specific verb+resource with no ambiguity, and it stands apart from the many sibling 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?

It explicitly tells the agent when to use it: for querying mitigation status, either for one shipment (pass id) or all open plans (omit id). It explicitly distinguishes from recording decisions, which must happen on eudr.dev, and explains why (Article 11(3) requires attribution to a named person). This is clear when-to-use and when-not-to 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=false and destructiveHint=true, but the description goes far beyond that: it specifies that it WRITES, stores a task, sends plot geometry and HS code to an external service, does NOT forward operator/supplier identity, returns a task handle, files nothing with any authority, costs 5 credits, and auto-refunds on failure. This level of behavioral disclosure is exceptional and fully informs the agent of side effects, privacy, and cost implications.

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 dense paragraph but every sentence earns its place: it covers the core action, side effects, privacy, workflow (confirm first), cost, and alternative tool. It is front-loaded with the primary action and avoids extraneous detail. Slightly long for a tool description, but given the complexity and the amount of critical information, it remains appropriately concise.

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 objects, external service call, side effects, cost, and expected follow-up), the description covers all essential context: what happens, what isn't forwarded, how to retrieve the result, the need for user confirmation, the cost and refund policy, and the fact that it doesn't file with authorities. The output schema is present, so the return format is already defined; the description does not need to repeat that. Nothing an agent needs to call it correctly 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 low (20%), so the description is expected to compensate. It does mention that 'operator and supplier details' are passed and that 'plot geometry, HS code, country and quantity' are sent upstream, which clarifies the role of several parameters. However, it does not explain all parameters (e.g., producer, role enum, harvest_window format) and leaves many nested fields undocumented. The description adds value but not enough to fully offset the schema gaps.

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 opens with a specific verb and resource: 'Compile and sign an Annex II Due Diligence Statement.' It then clarifies the exact side effects (stores a compile task, sends data to emem.dev) and distinguishes itself from the read sibling eudr_get_dds by explicitly naming it as the tool to fetch the outcome. The purpose is unambiguous and distinct from all 15 sibling 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 provides clear when-to-use guidance: it tells the agent to confirm details with the user first, explains that the tool costs credits (unlike all others), and directs the agent to eudr_get_dds for reading the result. It does not explicitly state when NOT to use it, but the context of the workflow (preparing a DDS) sufficiently implies when it is appropriate, and the alternative is named.

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

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

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?

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.