Assay Systems procurement register

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds only 'from the register' as source context and says nothing about lookup failures, missing records, or payload size, so it contributes little beyond the structured metadata.

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 short sentence with no filler, and the resource and scope are front-loaded. It is efficient, though its brevity borders on under-specification rather than true economy.

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 output schema and no explanation of what fields the returned record contains, the description leaves the agent guessing about the response shape. For a data-retrieval tool, that is a meaningful gap, even though parameters are well covered by the schema.

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 schema already explains that id comes from assay_search and that country is a lowercase two-letter code listed by assay_countries. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description identifies the resource ('one contract or award record') and its source ('the register'), and the singular phrasing implies single-record retrieval. However, it is a noun phrase with no verb, and it does not differentiate from siblings such as assay_line_contracts, assay_supplier_contracts, or assay_search, which all touch contract records.

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 prerequisite stated (e.g., that the id comes from a prior search), and no alternatives named. The id parameter's schema hints at a dependency on assay_search, but the description itself offers nothing.

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 readOnly, idempotent, and closed-world behavior, so the safety profile is covered. The description adds the useful detail that results are aggregated with a per-country supplier count, but says nothing about ordering, pagination, or coverage limits.

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 front-loaded sentence that states scope and return content with no filler. 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 parameterless read-only listing with no output schema, the description supplies enough to call it correctly and anticipate the shape of the result. Only minor gaps remain around ordering and result size.

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 is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies an unfiltered full-register listing.

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 the resource (countries in the Assay Systems procurement register) and the payload (supplier count per country), so an agent knows exactly what this returns. It does not, however, differentiate itself from the many assay_* siblings that also read the same register.

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

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

No guidance on when to call this versus assay_search, assay_supplier, or the other siblings. There are no prerequisites or exclusions stated, leaving the agent to infer usage entirely from the name.

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 openWorldHint=false, so safety is covered. The description adds genuinely non-structured context: the result ordering, the fact that only still-running contracts are returned, and the billing model (USD 0.01/call via x402 USDC on Base or an X-API-Key). Pagination/result-size behavior is not disclosed.

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

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

Two sentences, front-loaded with the scope and sort order an agent needs to route the call; the payment clause is verbose but conveys information an agent must know before calling. No filler or repetition.

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, no-output-schema query tool, the description covers scope, ordering, and cost, and annotations cover the safety profile. The remaining gap is pagination behavior for the `page` parameter and any hint about result shape, which is a minor omission rather than a blocker.

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

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

Schema description coverage is 100%, so all four parameters (line, country, page, before) are already documented in the schema; baseline 3 applies. The description adds only the implicit "one line" framing, no format or filtering nuance beyond what the schema already says.

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 the resource (contracts of one line) and its exact scope (still running) plus the ordering (soonest end first), so an agent knows precisely what comes back. It stops short of explicitly naming a sibling (e.g. assay_line_contracts or assay_uncontested) that an agent might otherwise confuse it with.

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 next tenders to come" implies the intent (finding upcoming renewal/tender opportunities), which is useful usage context. But there is no explicit when-to-use statement, no exclusions, and no named alternative for when the agent wants all contracts of a line rather than only still-running ones.

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 openWorldHint=false, so the safety and replay profile is covered. The description adds the useful fact that the payload contains buyers, suppliers and totals, which partially compensates for the absent output schema. It adds nothing about freshness, aggregation semantics, or error 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?

A single front-loaded sentence with no filler; the parenthetical '(what is bought)' efficiently defines the domain term. It is not padded, though brevity here shades into under-specification rather than crisp economy.

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 output schema, the description is the only source on return contents and it names them, which is adequate minimum coverage. It stops short of explaining what the totals represent or the shape of buyer/supplier entries, so a consumer still faces ambiguity about the payload.

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%: the id parameter explains it is the part after the country in the endpoint and points to assay_search, and country points to assay_countries. The description itself contributes no parameter meaning, so the baseline of 3 is correct when the schema carries the full load.

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 identifies the resource (a line of business in one country) and enumerates the returned content (buyers, suppliers and totals), which is more than a tautology. However, it uses no verb and gives no explicit differentiation from nearby siblings like assay_line_contracts or assay_contract, so an agent must infer the boundary. Purpose is discernible but not sharp.

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 statement of when to use this tool versus the ten sibling lookups, and no prerequisites or exclusions. The only routing hints (id comes from assay_search, country from assay_countries) live in the input schema descriptions, not the tool description. An agent gets no guidance on choosing this over assay_line_contracts.

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 cover the safety profile (readOnly, idempotent, no open-world access), and the description adds material context beyond them: the call is metered at USD 0.01 per call payable in USDC on Base via x402, or via an X-API-Key Commercial key. That payment/auth requirement is exactly the kind of behavioral detail an agent needs before invoking.

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: the first front-loads what the tool returns, the second carries the billing/auth mechanics. No filler or redundancy, though the pricing clause could be split more cleanly from the purpose statement.

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 output schema, the description names the main return fields (contact, end dates, amounts), and it discloses the payment requirement. For a read-only filtered-list tool this is nearly sufficient; pagination and exact record shape are left implicit.

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 explains id, page, buyer, country, and ends_before in detail. The description adds no syntax or constraint information beyond echoing the returnable fields, so the baseline 3 applies.

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

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

States a specific verb/resource: contract rows for one line of business, with the fields returned (contact, end dates, amounts). It is distinguishable from siblings like assay_contract or assay_line, though it does not explicitly say how it differs from them.

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 never states when to use this tool versus assay_contract, assay_line, or assay_supplier_contracts. Usage is only inferable from the name and the required (country, id) pair, which mirrors assay_search output.

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 openWorldHint=false, so the safety profile is covered. The description adds real value by listing the returned fields (names, countries, ids, endpoints), which matters because no output schema exists, but it stays silent on result limits/pagination and on what happens when no match is found.

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 short sentences, front-loaded with purpose and then return contents. 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 simple three-parameter read-only search with no output schema, the description covers purpose, search keys and returned fields, which is close to sufficient. The remaining gap is the undocumented limit parameter and the lack of any routing hint against the near-identical sibling assay_supplier.

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 67%: q and country are documented, limit is not documented anywhere. The description adds a small increment over the schema by noting q can take a line of business, not just a name, but it says nothing about limit or its 1-200 range.

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 (search the register for a supplier/firm) plus the two search keys, name or line of business. However, it never distinguishes itself from the very similarly named sibling assay_supplier, so an agent cannot tell from the description alone which of the two is the lookup-by-id versus the free-text search.

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 or when-not-to-use guidance and no mention of alternatives such as assay_supplier or assay_countries. The search keys are named but no prerequisites, exclusions, or routing logic are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-structured context: the call is paid at USD 0.01 in USDC on Base via x402, or authenticated with an X-API-Key Commercial key. That payment/auth disclosure is real value 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?

It is short, but the single packed sentence is grammatically fractured and forces re-reading; the kind-mapping content is front-loaded but the phrasing is not clean enough to earn a 4.

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 output schema, the description must carry the return-shape burden, and it only partly does: the kind→output mapping helps, but pagination behaviour, result format and the semantics of the optional buyer/supplier filters are left to the schema. Adequate but with clear 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?

Schema coverage is 80%, so the baseline is 3, but the description goes further by mapping the `kind` enum values to outputs (pairs, locks, buyers) and explaining the `country` behaviour (omitting it yields the country list). This adds meaning the schema alone does not carry.

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 title and description identify the resource (buyer×supplier pairs where a supplier won uncontested) but the body sentence is jargon-heavy and syntactically broken ('locks and buyer shares; without country — the list of countries'), so the exact scope is hard to pin down. It never names the sibling it is not, and 'won without a rival' reads nearly identically to the sibling assay_uncontested, leaving the boundary ambiguous.

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 explicit when-to-use guidance and no reference to any of the ten sibling tools, even the obviously overlapping assay_uncontested. The agent is left to infer selection from the name alone.

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 openWorldHint=false, so the safety profile is covered. The description adds essentially nothing behavioral beyond that — no explanation of what 'built' means, no freshness thresholds, no indication of whether results are cached or live.

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 short sentence with no filler, and the key content (per-source last read/built) is front-loaded. It is arguably too terse to be maximally useful, but nothing is wasted.

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 output schema, the description carries the burden of explaining return content; it gestures at per-source timestamps but never defines 'register' or 'source', and gives no sense of the shape or granularity of the response. Adequate but with clear gaps for a zero-param status tool.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry; the baseline of 4 applies. Schema coverage is 100% by definition for an empty object.

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 says what the tool returns (per-source last-read and last-built times) but has no verb and no resource framing beyond the vague word 'register'. It does not distinguish itself from any of the ten sibling assay_* tools, several of which are also register queries.

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 indication of when to call this versus alternatives such as assay_search or assay_line, and no mention of prerequisites or context. The agent must infer freshness-checking intent entirely on its own.

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 openWorldHint=false, so the safety profile is covered. The description adds value by disclosing the record's payload contents, but says nothing about auth, rate limits, or whether a missing id/country errors versus returns empty. Adequate but not rich 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?

A single front-loaded noun phrase that lists the returned fields without padding; every word earns its place. It is slightly terse as a fragment with no verb, but nothing is wasted.

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?

There is no output schema, so the description usefully compensates by enumerating the record's contents. For a read-only, two-parameter lookup whose safety profile is fully carried by annotations, this is nearly complete; the only gap is how it relates to assay_supplier_contracts and other supplier-oriented siblings.

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

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

Schema coverage is 100%: both id and country are fully documented in the schema, including the 'id as given by assay_search' provenance and the country-code format. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

It states a specific resource and scope ('One supplier's record') and enumerates the record contents (contracts won, buyers, totals, exclusions, grants, source, licence), which tells an agent exactly what it gets back. It does not distinguish itself from close siblings such as assay_supplier_contracts or assay_contract, so the agent must infer the boundary.

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 no when-to-use guidance, no prerequisites, and names no alternative. The only routing hint ('the part after the country in the endpoint') lives in the schema, not the description, and no sibling is contrasted.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, closed-world), so the description's real value is the pay-per-call disclosure: USD 0.01 per call in USDC on Base via x402, or an X-API-Key Commercial key. That is material cost/auth context an agent cannot get from annotations, though pagination behavior for the 'page' parameter is not disclosed.

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

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

Two sentences, front-loaded with what the tool returns and followed by the non-obvious billing/auth requirement. No filler; 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?

With no output schema, the description partially compensates by naming the returned fields (buyer contact, end dates, amounts) and the pricing model. It stops short of describing result-list size or pagination semantics, which matter given the 'page' parameter.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the 'id' provenance from assay_search and the 'country' code format. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific resource and scope: 'All contract rows of one supplier', plus the fields carried (contact, end dates, amounts). An agent can distinguish it from the singular assay_contract or assay_line_contracts, though no sibling is named 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives such as assay_contract for a single row or assay_supplier for supplier-level data. The only contextual direction is the payment note, which is about access, not selection.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds that the output is a 'summary' (aggregated rather than row-level) and the domain meaning of 'uncontested', but says nothing about aggregation granularity or time scope 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?

A single efficient sentence with the resource definition front-loaded and the scoping qualifier trailing. Nothing is wasted, though it is almost too terse to carry usage and behavioral nuance.

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 aggregation tool with one fully documented optional parameter and safety annotations, the definition is nearly sufficient. The only gap is that with no output schema it doesn't characterize the returned summary shape.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: omitting the single optional parameter yields all countries rather than an error, which the schema does not state.

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 resource and scope: a summary of uncontested (single-bid) awards, either globally or filtered to one country. The parenthetical defines 'uncontested' so the agent needn't guess. However it does not differentiate itself from siblings with potentially overlapping meaning such as assay_solo.

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?

Usage is only implied: 'for all countries or one country' hints that omitting the argument returns the full set. There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the many assay_* siblings.

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