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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context by stating it 'reads no documents and judges no evidence' and that it returns a separation of blocking vs. incomplete items, which goes beyond the annotations and clarifies side-effect-free operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler. The core purpose and output are front-loaded, and every sentence adds information: what it checks, what it returns, and its scope/limitation. It is appropriately sized for the tool's 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?

For a read-only checklist tool with a rich input schema and an output schema, the description covers the purpose, the output nature (unmet items with article references, blocking vs. incomplete), and the limitation (no document reading). It does not mention the max supplier count (in schema) or authentication requirements, but those are covered by schema/annotations. Overall, it provides enough context 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 0%, so the description must compensate by explaining the 'suppliers' parameter and its fields, but it does not. It only refers generically to 'the fields you supply' without describing which fields, their formats, or requiredness. The schema itself is well-documented, but the description adds zero parameter-level meaning, leaving the agent to rely entirely on the schema.

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

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

The description uses a specific verb ('Check') against a clear resource ('each supplier's file') and a named regulation (Article 9(1) of EU 2023/1115). It also states what is returned (unmet items with article reference and what to request) and distinguishes blocking vs. incomplete items, making the tool's purpose unambiguous and distinct from the 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 clarifies that it is a checklist over the fields supplied and explicitly states it 'reads no documents and judges no evidence,' which helps an agent decide when to use it (when structured supplier data exists) versus tools that handle documents. However, it does not name a specific alternative or provide an explicit when-not-to-use condition, so it falls short of a 5.

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

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

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?

Discloses substantial downstream behavior beyond the annotations: with a boundary the country is derived 'from where the land lies', the forest record is 'warmed', and the land check runs when the crop is EU-regulated; with only a pin, mapped fields are surfaced as suggestions for a person to accept. It also states the write happens and explains the join_m default (3 m each way) and neighbor-joining logic.

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?

Purpose is front-loaded in the first sentence, and subsequent sentences earn their place by covering each input mode. It is a long, dense paragraph with jargon ('closing the bunds and tracks between neighbours') that could be broken up, but little of it is 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?

An output schema exists, so return values need not be explained. For an 8-parameter, nested-object creation tool the description covers the main input paths (name, crop, country, pin, boundary, fields, join_m) and the triggered side effects, leaving only minor gaps such as constraints on the separate pieces when fields are far apart.

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?

With schema coverage at only 38%, the description compensates well: it clarifies boundary is a GeoJSON Polygon/MultiPolygon 'longitude first', that fields are multiple outlines joined into one farm, and that join_m defaults to 3 m per side. Minor gap: lat/lon are only described as a 'pin (lat, lon)' without reinforcing valid ranges.

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 upfront: 'Add a farm to this organisation's record.' An agent can distinguish this creation tool from siblings like eudr_set_farm_boundary or eudr_list_farms, since the description explains it accepts a boundary at creation time rather than only setting one later.

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 conditional guidance on input modes: 'A name is enough', supply crop/country/pin 'when known', use boundary for a known outline, fields for joining parcel outlines. It lacks explicit routing against sibling tools (e.g., when to prefer eudr_set_farm_boundary afterwards), so it stops short of the top band.

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 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 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=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?

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: discloses the write target (a stored compile task), the external data flow to emem.dev for measurement and independent signing, the privacy boundary ('Operator and supplier identity are not forwarded upstream'), and the async task-handle pattern. It also surfaces cost and refund behavior (5 credits, +1 per additional plot, auto-refund on failure, other tools free), which the annotations cannot express.

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?

Dense but front-loaded: the write behavior, upstream flow and read-back pointer come first, with cost/policy details trailing. Every sentence carries operational information, though the final cost sentence is long and could be split for easier 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?

Given a rich output schema and strong annotations, the description covers the remaining agent-critical gaps: async task-handle workflow, the read-back tool, upstream data exposure, the no-filing boundary, user confirmation, and the credit cost/refund model. Nothing material 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 only 20% across 5 nested parameters. The description names what is forwarded upstream (plot geometry, HS code, country, quantity) and that operator/supplier details are stored, which adds some meaning, but it says nothing about producer, harvest_window, additional_plots, or the credit-per-plot implications of the additional_plots array. Baseline 3 for partial compensation of a low-coverage 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 specific verb and resource ('Compile and sign an Annex II Due Diligence Statement') and immediately scopes it as an async compile step distinct from its read counterpart eudr_get_dds. An agent can distinguish it from siblings like eudr_export_statement or eudr_get_dds without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'Returns a task handle; read the outcome with eudr_get_dds', and adds the precondition 'Confirm the details with the user first.' It also clarifies scope with 'Nothing is filed with any authority', which tells the agent what this tool does NOT do versus the filing-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 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?

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.