search_queues

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it delivers: it reveals the return payload (first-available date and average wait time per provider), the partial case-insensitive matching behavior of benefit, and the case semantics. It does not cover result ordering or no-results behavior, but the core behavioral traits an agent needs are disclosed upfront.

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 with the core purpose and payload front-loaded before parameter detail. The case explanation repeats schema-stated information, which is mild redundancy, but the prose remains compact and every sentence earns its place meaningfully.

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 annotations and no output schema, the description compensates well by stating the return content (first-available date and avg wait time), matching behavior, and enum semantics. It could add result ordering or pagination notes for a provider-list search, which keeps it a notch below fully 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 coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: it explains that benefit is a partial case-insensitive match against the official service name and routes uncertain agents to search_benefits. The case explanation duplicates the schema enum descriptions, but the partial-match clarification is no free value from the structured fields.

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 action (search waiting lists) with a clear resource (NFZ kolejki), scope (by province) and outcome (returns first-available date and average wait time per provider). Differentiates cleanly from search_benefits (finds service names) and list_provinces (province codes), so an agent can tell them apart without opening 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?

Explicitly advises 'use search_benefits first if unsure' about the service name, which is direct routing guidance to a sibling. It defines the case enum values clearly. It does not state when to prefer list_provinces or explicitly exclude alternatives, but given the siblings are narrow utility lookups, the guidance is adequate.

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