swissco_tenders

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses real behavior: the date filter matches each project's newest publication of any type, and that suppliers named on awards carry no UID so the tool returns projects and buyers only. It omits ordering, pagination, and rate-limit behavior, but the annotations already cover the safety profile.

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

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

Front-loaded with the tool's purpose, then structured into field list, vocabulary, and semantics. The 11-field enumeration is partly redundant given an output schema exists, but the publication-type list is not available elsewhere in structured form, so most sentences earn their 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 an output schema, full parameter descriptions, and annotations present, the description only needed to add behavioral nuance — which it does via the newest-publication date semantics and the award/vendor caveats. Ordering and pagination behavior remain unspecified, a minor gap for a list 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?

Schema coverage is 100%, so the baseline is 3, and the description adds genuine meaning on top: it explains that since/until bind to the newest publication date per project and that pub_types is the lever for narrowing to awards. It even supplies the publication-type vocabulary that the schema leaves as a free string.

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 concrete resource (public-procurement projects from simap) and enumerates the row fields it returns, so the agent knows exactly what it gets. It explicitly carves out a boundary against swissco_vendor, though it does not distinguish itself from possibly-overlapping siblings like swissco_publications or swissco_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?

It gives one explicit routing rule — use swissco_vendor to check whether a company is in simap's vendor directory — plus the condition that pub_types narrows results to awards. There is clear context but no broader when-not-to-use guidance relative to other simap-related siblings.

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