search_procurements

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

The annotations already declare read-only/idempotent behavior, but the description adds substantial non-obvious context: simap indexes projects rather than publications, a project appears once under its newest publication, filterless queries return nothing, and place_of_delivery misses ~60% of publications. It also discloses that canton_match='both' costs two upstream calls and disables cursors.

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 it is well-organized with a use-case tag, summary paragraphs, and an Args block. Virtually every sentence adds operational value—coverage, update frequency, project-indexing model, required filters, and parameter caveats—though a bit more trimming would make it even more concise.

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

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

The description is complete for a complex search tool: it covers scope, update cadence, the project-vs-publication model, required filters, pagination behavior, parameter quirks, and links to related tools. Given the output schema is present and the description provides deep operational context, an agent can invoke this tool reliably.

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?

Even though the context signal claims 0% schema description coverage, the schema actually includes property descriptions, and the tool description's Args section goes much further. It explains bare canton format (NOT CH-ZH), the meaning and caveats of each canton_match value, the exact award pub_type strings, and the fact that a plain 'award' is rejected by the API.

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

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

The description opens with a clear use case: 'Find open tenders matching a topic, canton, CPV code or date window — the default entry point...' and explicitly states it searches Swiss public procurement projects on simap.ch. This specific verb-plus-resource framing distinguishes it from siblings like get_procurement_details and get_publication_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?

The description explicitly labels itself as the default entry point for 'what is being tendered?' and directs the agent to use get_procurement_details for full records and get_publication_history for earlier publications. It also references search_cpv_codes for resolving CPV names, providing concrete alternatives.

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