Zephior Discovery

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one genuinely new behavioral fact — that absent fields are surfaced as explicitly unavailable rather than omitted — which is useful, though the enumerated return areas partly duplicate the output schema.

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 tight sentences with no filler, and the core 'read a published notice' action is front-loaded before the detail sentence. The comma-separated content list is dense but not wasteful.

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 values need not be re-explained, and annotations cover the safety profile. The remaining gaps — no parameter meaning and no routing guidance against the search/list siblings for a read-by-ID tool — leave the definition adequate but not 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%, so the description carries the burden of explaining the two parameters, yet it says nothing about the UUID 'id' format or the 'locale' enum/default. An agent gets no help beyond the raw schema constraints on either parameter.

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 ('Read') and resource ('a published notice') and enumerates the content areas returned (facts, requirements, original source, history), so an agent knows this is a single-record retrieval. It does not distinguish itself from the search/list siblings, but the purpose itself is 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?

No guidance on when to use this versus search_public_tenders, list_public_tender_changes, or the facets tool. 'Missing information is explicitly unavailable' describes output behavior, not invocation conditions, so the agent must infer that this is the by-ID fetch.

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 the safety profile is covered. The description adds genuinely useful behavior beyond that: only published countries appear, category results are capped at 100, and categoriesTotal reflects all matches rather than the returned page. No auth or rate-limit context, but the cap and count semantics are the important traits.

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 tight sentences with no filler, and the most important output (the filter vocabulary) is front-loaded before the parameter detail. Every clause carries information.

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 values need no further explanation, and the description still usefully summarizes what the facets contain. The main shortfall is the silent locale parameter on a low-coverage schema; otherwise an agent has enough to call it 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?

With 0% schema description coverage the description must carry the parameter burden, and it does well for categoryQuery (purpose, an example, and the categoriesTotal count it drives). The locale parameter (enum en/de/fr) is never mentioned, leaving one of two parameters undocumented anywhere, so it only partially compensates.

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 (Discover) plus the exact resources returned: published country IDs, supported statuses, and up to 100 category IDs. This clearly separates it from the search/list siblings, which retrieve tenders rather than filter vocabulary. It stops short of naming an alternative tool, so it is clear but not fully sibling-aware.

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 explains how to use one parameter (pass categoryQuery to find matching categories) but never states when to reach for this tool versus search_public_tenders or list_public_tender_sources, nor any exclusions. Usage is only implied: fetch filter values before filtering a search.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description echoes 'read-only' and adds a mild scope note (canonical/public documents), but contributes no new behavioral context such as auth requirements 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?

One sentence, front-loaded with the retrieval verb and scope, with 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 single-parameter, enum-driven fetch tool with an output schema already present, the description covers purpose and read-only nature adequately. Only the lack of sibling routing keeps it from being 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 description coverage is 100% and the single parameter is a fully described enum. The description restates the three options in prose ('service selection, developer integration or current pricing'), which is a minor readability aid but adds no syntax or selection guidance 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 gives a specific verb ('retrieve') and resource ('one canonical public document') and enumerates the three covered topics, which maps cleanly to the enum. It implicitly separates itself from siblings like get_zephior_overview and search_zephior_resources, but never names them, so an 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?

'Use this read-only tool to retrieve...' establishes the general context of use but offers no when-not guidance and no comparison to the sibling retrieval tools (overview, resource search). Usage is implied rather than stated.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description's 'read-only' label merely restates that; it does add the content scope (overview/identification), but no extra behavioral traits 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 sentence with no filler; the imperative 'Use this read-only tool to...' is efficient. The triple-goal phrasing is slightly dense 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?

An output schema exists, so return values need no explanation, and the lone parameter is fully specified. The remaining gap is orientation: with three same-named Zephior siblings, the description never clarifies which one to reach for, leaving the agent to guess.

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% with a single enum-constrained 'locale' parameter that defaults to English, so the schema fully documents the input. The description adds nothing about locale or how it affects output, which is the expected baseline when the schema does the work.

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 a resource (Zephior) and three goals: identify Zephior, compare Ziva and Zelius, and locate canonical contact/developer resources. However, 'identify Zephior' is vague and it draws no boundary against the siblings get_zephior_document and search_zephior_resources, so an agent cannot easily tell when this overview is preferred over those.

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 opens with an implied directive ('Use this read-only tool to...') and lists the situations it serves, which gives a reasonable sense of context. But it names no alternatives, no exclusions, and no conditions that select it over get_zephior_document or search_zephior_resources.

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, non-destructive. Description adds ordering semantics ('in the order they changed'), that items name changed fields (not full content), and pagination via nextCursor, going 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?

Three short sentences, front-loaded with purpose, then content pointer, then pagination instruction. Every sentence adds 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?

Output schema exists, so return values needn't be explained. Description covers ordering, content scope, and pagination, but could mention default time window or locale effect given schema 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 50%; cursor and since have descriptions, limit and locale do not. Description reinforces cursor pagination and hints at feed timespan, but adds little beyond schema for undocumented params like limit and locale.

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 specific verb and resource ('Follow new, amended and withdrawn published notices') and distinguishes scope from siblings by directing content retrieval to get_public_tender.

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?

Clear context: use to follow changes in order, read get_public_tender for content. Pass nextCursor to continue. No explicit when-not to use vs search_public_tenders, but the sibling reference provides routing.

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, openWorldHint=true, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds useful context about what the listing contains (portal URLs and last-checked timestamps), but says nothing about ordering, staleness, or result size.

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 sentence that front-loads the action and resource, then lists the return fields efficiently. Every clause earns its place and nothing is padded.

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 zero parameters, rich annotations, and an output schema that documents return shape, the description has little left to cover. Detailing the returned fields is mildly redundant against the output schema but confirms the tool's content at a glance, so the definition is essentially 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?

The tool takes no parameters, so the schema cannot add or omit semantic detail; the baseline for a zero-parameter tool is 4. The description correctly implies an unfiltered, full listing without fabricating filter semantics that do not 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 states a specific verb (List) and resource (procurement sources behind published notices), then enumerates the fields returned (names, official portals, notice counts, countries, last-checked timestamps). This is distinct from search_public_tenders, but it never explicitly contrasts itself with metadata siblings like get_public_tender_facets, so it falls short of full sibling differentiation.

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 call this tool versus search_public_tenders, get_public_tender_facets, or search_zephior_resources. Usage is only implied by the resource being described; no prerequisites, exclusions, or alternatives 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: results are limited to published notices and paginated at 20 records per page with canonical citations. It stops short of describing ordering behavior or what the citations represent.

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, zero filler, with the core search scope front-loaded and the return/pagination behavior second. Every clause carries information.

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 present, return values need less prose, and the description covers filters and page size. However, for an 8-parameter tool with low schema coverage, the leaving of sort, locale and pagination control unexplained, and no routing among the many sibling search/list tools, is a real gap.

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 only 13% (just the statuses field), so the description must compensate, and it does name the filter axes: country, category, status, buyer and text. It leaves page, sort and locale semantics entirely undocumented in both places, so compensation is partial rather than complete.

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 published tender notices) plus the filter dimensions it combines, so the operation is unambiguous. It does not distinguish itself from siblings such as list_public_tender_changes or get_public_tender_facets, which is the only thing keeping it out of the top band.

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 implies a filtered lookup but never states when to use this tool rather than a sibling (e.g. changes list, facets, or the single-tender getter). No preconditions or exclusions are given, matching the calibration case of 'clear fields but no when-to-use' at a 2.

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, openWorldHint=false and destructiveHint=false, so 'read-only' in the description is largely redundant. The description adds no behavior beyond annotations: no result-limit behavior, no locale handling, no indication of what the search covers or how results are ranked.

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 well-formed sentence with the action and resource front-loaded and no filler. It is appropriately sized for a search tool, though there is room to use the remaining space for parameter or usage guidance.

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 values need not be described, and annotations carry the safety profile. The remaining gaps are the unaddressed limit/locale parameters and the lack of routing versus sibling retrieval tools, leaving the definition minimally viable but incomplete.

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% and the description only obliquely characterizes 'query' as a task/decision/topic phrasing; it says nothing about the 'limit' cap (max 10) or the 'locale' enum (en/de/fr). With three undocumented parameters, the description does not compensate for the schema gap.

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 ('find') and resource (Zephior articles, guides, comparisons, industry briefs, glossary resources), so the agent knows this is a content search over Zephior's public library. It does not explicitly name the sibling it contrasts with (e.g., get_zephior_document for direct retrieval), so differentiation is inferable but not stated.

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 phrase 'by the user task, decision or topic they answer' implies what kinds of queries belong here, which is a useful usage signal. However, there is no explicit when-not-to-use condition and no named alternative among the many siblings (get_zephior_document, get_zephior_overview, search_public_tenders).

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