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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: the office list is large (~1 MB), fetch-once and client-side filtering, and the returned fields (id, type, linked institution id). This goes beyond annotations without contradicting 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 concise and front-loaded with a use_case tag, then a clear function statement and two additional useful details (performance, return fields). Every sentence earns its place. Minor redundancy between the use_case and first sentence, but it is efficient overall.

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 filtered-list tool with strong annotations and a detailed input schema, the description is complete. It covers the use case, behavior, performance note, and key return fields. The output schema exists, so return-value detail is optional; the description provides enough context for correct selection and 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?

The input schema already provides descriptions for all parameters (name_contains, limit, language), so the baseline is 3. The description's mention of '(partial) name' aligns with name_contains but does not add semantics beyond the schema. No ambiguity or gap that requires compensation.

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 clear, specific purpose: find public procurement offices by partial name. It explicitly distinguishes this tool from sibling tools that search procurements/awards by noting it resolves an authority name rather than a project. The use_case tag adds valuable 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 includes a clear when-to-use clause ('when the user names an authority rather than a project'), which guides selection. It does not explicitly name alternative tools, but the context strongly implies the distinction. This is clear context without formal 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context about what the record contains (order description, CPV, BKP/NPK codes, deadlines, procurement office) and highlights the joinability of BKP codes with construction cost data. This goes beyond the annotations without contradicting 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 front-loaded with a use case but contains redundancy: 'Retrieve the full record' and 'Return the full record' say the same thing. The second paragraph adds useful detail, but the opening could be tightened without losing meaning.

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 explains the source of the IDs, the specific fields included in the record, and even a downstream use (joining with construction cost data). With an output schema present, return-value documentation isn't needed. This is comprehensive for a single-record retrieval tool, though it could mention error behavior.

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

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

The input schema provides comprehensive descriptions for both project_id and publication_id (e.g., 'Project id from a search_procurements result'), giving near-total schema coverage. The description's mention that both IDs come from a search result largely repeats the schema, adding no new parameter-level syntax or constraints.

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's function: 'Return the full record for one procurement publication' and specifies the required inputs ('once you have its ids'). It distinguishes itself from sibling search tools by focusing on a single record's full details, including specific content like CPV codes and the procuring body.

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 notes that 'Both ids come from a search_procurements result', establishing a clear prerequisite and usage context. It doesn't enumerate alternatives or exclusions, but given the sibling list, the intended workflow (search first, then retrieve full record) is clear enough.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: an empty list is a normal result for a first publication, and the upstream service rejects requests for lot-based publications without lot_id.

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

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

Front-loaded with the use case, then the core function, then the edge cases. Every sentence carries information; the XML-style <use_case> wrapper is slightly ornamental but costs almost nothing.

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 structure needn't be explained, and the description still pre-empts the two things an agent could get wrong: interpreting an empty list and omitting lot_id on lot publications. Nothing further is needed to call this 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?

The included-schema descriptions already document publication_id and language; the prose adds real semantics for lot_id by explaining the failure mode (upstream keeps history per lot and refuses without one) and where to source the value from the search result. Minor gap: language selection is not addressed in the description.

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 — 'Return earlier publications of the same procurement project' — and frames it as a lifecycle trace (tender → correction → award). This clearly distinguishes it from the sibling search_* tools, which find procurements rather than trace one project's history.

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 an explicit trigger ("Use when the question is 'what happened to this procurement?'") and a conditional rule for when lot_id is required. It does not name an alternative sibling tool or state when not to use it, which keeps it 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 cover read-only, idempotent, open-world, and non-destructive behavior, but the description adds important caveats: uneven canton award coverage, absence not proof, and the newest-publication filter that can drop corrected awards. This goes well beyond what annotations 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?

Front-loaded with a clear use-case summary, then caveats. There is some redundancy between the `<use_case>` tag and the following sentence, and the wrapper sentence repeats 'all four award types', but overall the structure is efficient.

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 filtered search wrapper with coverage caveats and an existing output schema, the description supplies purpose, routing, and limitations. 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?

The nested schema already documents canton, cursor, language, canton_match, and date fields thoroughly. The description only cross-references `canton_match` semantics and its default, adding little beyond what the schema provides, 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?

States a specific verb ('Search') and resource ('awarded contracts'), plus scope ('all four award types at once'). Distinguishes from siblings by contrasting completed procurement with current opportunities and naming `search_procurements` as the wrapper base.

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 says to use it when the question is about completed procurement rather than current opportunities, effectively stating when-not. It also names `get_publication_history` as an alternative for checking older awards, and the caveats guide appropriate use.

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 clear. The description adds the use-case context but does not elaborate on behavioral details like return format, pagination, or error handling. No contradiction with 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 structured and mostly concise, with a use_case tag, a one-sentence summary, an Args list, and a brief context paragraph. Each section adds relevant context, though the final paragraph could be tightened without losing value.

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

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

The tool has an output schema and annotations that cover safety, so the description adequately explains the purpose and domain. It does not discuss optional parameters like limit and language, but the schema fills that gap, making it complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema provides descriptions for all four parameters (system, query, limit, language), including enum values. The tool description redundantly lists system enum values and describes query as 'Keyword,' but omits limit and language, adding minimal semantic value beyond 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 clearly states the tool translates a keyword into Swiss construction cost codes (BKP, NPK, eBKP, OAG, CPC). It uses specific verbs like 'search' and 'translate' with a well-defined resource, distinguishing it from sibling tools like search_cpv_codes by the Swiss classification 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?

It provides strong context that this is for Swiss construction cost standards used in building tenders, relevant for school-building procurement. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity compared to similar 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the tool's role in the overall search pipeline but does not disclose additional behavioral traits like matched/unmatched behavior, result ordering, or rate limits. It is adequate, but not rich beyond 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 concise and well-structured, starting with a clear use_case tag, followed by a one-sentence summary, and then context about CPV and integration. Every sentence contributes to understanding the tool's purpose and usage. No redundant or fluff 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?

For a read-only search tool, the description covers purpose, usage timing, and integration with `search_procurements`. It does not explain the return format, but an output schema is present. It also doesn't address edge cases like no matches, but given the tool's simplicity and the presence of annotations/schema, this is sufficiently complete.

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% – the tool description does not explain any parameters. Although the schema itself provides detailed descriptions for `query`, `limit`, and `language`, the instruction states that with low coverage the description must compensate. It only gives a single example keyword ('Metall') but does not explain the other parameters or their constraints, so it fails to add meaningful value beyond 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 clearly states the tool's function: 'Search CPV classification codes by keyword.' It also specifies that it translates a keyword into CPV codes for filtering `search_procurements`, which differentiates it from sibling tools like `search_construction_codes`. The verb 'search' + resource 'CPV classification codes' is specific and 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?

The use_case explicitly states when to call this tool: 'Call this first when the user names a subject rather than a code.' It also explains the workflow: resolve keyword to code, then pass to `search_procurements(cpv_codes=[...])`. This provides clear when-to-use guidance and distinguishes it from the procurement search 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?

The annotations already mark this as read-only, open-world, idempotent, and non-destructive. Beyond that, the description discloses important behavior: simap indexes projects rather than publications, only the newest publication represents a project, filterless queries return nothing, and canton_match='both' costs two upstream calls and disables pagination.

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 front-loaded and well organized: use case, core behavior, sibling routing, indexing caveat, filter requirement, then Args. Every section adds practical guidance for invoking the tool correctly.

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 complex procurement search tool with an output schema available, the description covers purpose, alternatives, filtering rules, pagination limitations, and regional/classification semantics. Nothing critical for correct invocation appears to be 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?

Although the input schema contains parameter descriptions, the tool description adds substantial semantic guidance: canton must be a bare id like ZH rather than CH-ZH, canton_match meanings and caveats, cpv_codes should be resolved via search_cpv_codes, pub_type 'award' is rejected, dates filter on the newest publication date, and cursor comes from next_cursor.

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: searching Swiss public procurement projects on simap.ch. It clearly identifies itself as the default entry point for 'what is being tendered?' and distinguishes itself from get_procurement_details and get_publication_history by explaining the project/publication indexing difference.

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

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

It explicitly says when to use this tool ('default entry point when the question is what is being tendered?'), how to follow up with get_procurement_details and get_publication_history, and how to resolve CPV codes with search_cpv_codes. It also states the non-obvious rule that at least one filter is required.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it runs a search then fetches get_procurement_details in parallel for top_n hits, and each result carries CPV/BKP codes, deadlines, and office. This goes beyond basic safety disclosure to explain the composite 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?

Longer than typical, but well-structured with a <use_case> tag, a one-sentence summary, explanation of aggregation, and an Args block. Every sentence contributes value; no redundancy from the schema.

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 composite tool with one parameter and a sibling reference, the description covers use case, internal behavior, result contents, alternatives, and parameter semantics. The presence of an output schema lowers the burden for return-value details, making this complete.

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% for the single 'args' parameter, but the description explicitly defines top_n as 'How many of the top hits to expand to full detail (1-5)' and states all other params are 'identical to search_procurements', linking to a sibling for full semantics. This compensates for the schema gap well.

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?

Description opens with 'Search publications and return the FULL record for the top matches at once' – a specific verb+resource+scope statement. It also explicitly contrasts with sibling search_procurements, clarifying its unique aggregation behavior.

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?

Provides explicit when/when-not guidance: 'Prefer this over search_procurements followed by N detail calls' and 'Prefer search_procurements when you only need the summaries or want to paginate'. This disambiguates tool selection clearly.

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 indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds context beyond annotations by clarifying that the tool reports reachability and latency, and by explaining the semantic importance of distinguishing source failures from empty results. This is useful behavioral context without contradicting any 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 concise and well-structured. It begins with an XML-like use_case tag conveying the scenario, then a direct statement of what the tool reports. Every sentence is meaningful, with no fluff 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?

The tool is simple: it checks reachability and latency, with no parameters. The description explains both purpose and usage context, while annotations cover safety and idempotency. An output schema exists (not shown), so return-value details are not required in the description. The description is fully complete for this 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 no arguments (StatusInput has no properties, and the optional 'args' defaults to null). With 0 parameters, the baseline score is 4. The description does not repeat schema details, and no parameter explanations are needed since none exist.

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 explicitly states the tool's function: 'Check whether simap.ch is reachable and how fast it is responding.' It specifies the resource (simap.ch read API) and the action (checking reachability and latency), clearly distinguishing it from sibling tools that search or retrieve procurement 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 provides a clear scenario for when to use the tool: 'Call this when a search returns nothing and you need to distinguish "no matching tenders" from "the source could not be asked".' This explains the context and decision point, though it does not explicitly mention alternative tools or when not to use it.

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