Zephior Discovery

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real interpretive context beyond that: the three status fields are distinguished, stale true/false is qualified, and revisions are bounded by historyTotal/historyNextBefore.

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 core read action, and the status/staleness/history sentences each carry load, but the text is a dense semicolon-chain with multiple concerns interleaved and no separation between output semantics and guidance, making it heavier than necessary.

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 record with an output schema, the description supplies the interpretation an agent needs: status vs recordedStatus vs sourceStatus, staleness caveats, related-notice comparison, and history pagination. It stops short on error/not-found behavior and sibling routing, but is otherwise thorough.

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 low (25%) — only historyBefore is documented in the schema. The description partially compensates by explaining that historyNextBefore should be passed as historyBefore for older revisions, but locale and historyLimit remain unexplained in both places, leaving the gap only partly filled.

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 what is returned: source-backed facts, requirements, original source, related notices and history. The read-by-id nature separates it from siblings like search_public_tenders and list_public_tender_changes, though no sibling is named explicitly.

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?

Offers actionable guidance on handling related notices ('compare them, prefer the latest official change notice, and check the submission platform before relying on a deadline') and pagination. However it never states when to choose this tool versus search_public_tenders or the list_* siblings, so routing guidance is only implied.

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, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: categories are returned 100 at a time ordered by notice count, each carries its notice count, and categoriesTotal reflects all matches. It does not describe ordering or shape of the country/status/sector lists, which is the remaining gap.

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?

Dense but front-loaded: the resource list comes first, then pagination mechanics, then the sector-vs-category preference. Every clause carries information, though the middle sentence is a run-on that mixes input guidance with output-field names and could be split.

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 not be explained, and the description still helpfully ties inputs to output fields (nextCategoryOffset, categoriesTotal). It is nearly complete for a three-parameter read tool; only the locale parameter and the ordering of the non-category facet lists are unaddressed.

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 full burden. It does explain categoryQuery with a concrete example ('road construction') and categoryOffset indirectly by mapping it to the output field nextCategoryOffset, but the locale enum is never mentioned, leaving one of three parameters undocumented anywhere.

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 concrete resource – published country IDs, statuses, sectors and category IDs – so an agent can tell this is the facet/lookup tool rather than a tender-search tool. It never names a sibling explicitly, but the resource list is specific enough to separate it from search_public_tenders and get_public_tender without opening a schema.

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 real guidance for choosing between facets ('prefer sectors for broad needs') and for narrowing with categoryQuery, plus how to page with categoryOffset. What is missing is any statement of when to reach for this tool at all versus search_public_tenders or get_public_tender – the routing decision is left implicit.

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 carry the safety profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), so the description earns credit by adding ordering semantics (change order), the response shape (event kind, changed fields, cursor) and an explicit disambiguation that a revision is a Zephior version rather than an official amendment. It omits rate limits and the default seven-day window, which lives only in the since schema field.

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 list behavior front-loaded, then filters, then a domain caveat. Efficient, though the final clause about 'corrected a Zephior correction' is garbled enough to cost a point.

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 not be re-explained, and the description covers windowing, filtering and cursor continuation for a nine-parameter, all-optional feed. Missing only the default-window behavior and non-filter parameters (limit, locale), which keeps it short of a 5.

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 only 44% (limit, events, sectors, countries, locale undocumented), yet the description names countries, sources, sectors, events, since/until and the cursor, and goes beyond the enum list by explaining what source_changed and corrected actually mean. It still leaves limit and locale unexplained.

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?

Specific verb (List) plus resource (published notice changes) with the payload spelled out: event kind, changed fields, continuation cursor. It also defines the temporal shell (change order, since/until window), though it never names a sibling such as search_public_tenders or get_public_tender to route against.

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 states what can be filtered (countries, sources, sectors, events) and how to bound the window, which implies the intended polling/feed use case, but gives no when-to-use vs when-not guidance and names no alternative among the seven siblings.

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, openWorldHint and destructiveHint, so the safety profile is fully covered. The description adds a freshness nuance ('when each source was last checked (null when unknown)'), but since an output schema exists, most of the field detail is redundant with structured data. Value added is real but modest.

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 ('List the procurement sources') and then enumerates the returned fields. No filler, no repetition of the title.

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 zero-parameter, read-only catalog listing with an output schema and full annotation coverage, the description is essentially complete: purpose plus freshness semantics. The only missing piece is routing guidance relative to sibling list/search tools.

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 zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly avoids inventing parameter behavior and simply describes the result set.

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: 'List the procurement sources behind published notices', with the returned attributes spelled out. It is clearly distinguishable from search_public_tenders or list_public_tender_changes, but it never explicitly contrasts itself with the sibling 'facets' or 'changes' tools, so it stops short of a 5.

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 when-to-use statement and no mention of alternatives such as get_public_tender_facets or search_public_tenders. The agent must infer that this is the catalog-enumeration call from the name alone. This matches the calibration case for 'no guidance'.

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 the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: default/max page size, the requirement to read each nextPage before treating a list as complete, the total-vs-procedures counting semantics, how sort=deadline treats date-only deadlines, and how q tokenizes and matches accents/compounds. That is real context beyond the structured fields.

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 purpose and scope lead, followed by pagination, semantics, and recovery advice in roughly descending importance. It is dense and on the long side for a search tool, but nearly every sentence carries non-redundant information; only minor trimming would be possible.

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 an 18-parameter, all-optional search tool with an output schema and full annotation coverage, the description supplies the filtering semantics, pagination contract, result-counting caveats, and zero-result interpretation. Nothing an agent needs to call it correctly is 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?

Schema description coverage is only 56%, so the description must compensate, and it does for the highest-risk parameters: q's word/compound/accents matching, the sectors-vs-cpv-vs-categories preference, and sort=deadline behavior. A few parameters (buyer, countries, page) get no additional explanation, but the ambiguous ones are clarified well above baseline.

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 precise verb (Search) plus resource (published tender notices) and enumerates the filterable facets, then explicitly routes the agent to get_public_tender for notice text and history. An agent can distinguish it from the get_/list_ siblings without opening any schema.

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?

Gives concrete when-to-use routing ('read get_public_tender for notice text, facts, related notices and history'), selection advice among filters ('for broad needs prefer sectors or cpv over category IDs'), and even failure recovery ('a zero result can mean no coverage, a narrow filter or different wording: widen filters or try source-language keywords'). This is exactly the guidance an agent needs before choosing filters.

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.