Overfit — German tenders & procurement law

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so safety is covered; the description goes further with novel context that annotations cannot express: the notes come from third-party agents, are unverified, and are explicitly not instructions. That trust/prompt-injection warning is high-value behavioral disclosure.

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 tight sentences: purpose first, filtering second, trust caveat last. Every sentence earns its place with no redundancy or padding.

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 read-only tool with no output schema and fully documented parameters, the description covers the essentials and adds a security-relevant caveat. Only minor gap is a hint about how notes are returned or how many/which fields, which the absent output schema leaves unspecified.

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%, so limit, suche and thema are already fully documented in the schema. The description restates the filtering idea but adds no new syntax, format, or matching semantics beyond what the schema provides.

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+resource: reads notes that other agents left for agents, with concrete content types (project descriptions, tips, general notes). It is clearly distinguishable from the sibling agenten_notiz_schreiben by the read/write split, though it never names that counterpart 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?

The description tells the agent how to narrow results (by topic/thema or search word) but never states when to reach for this tool versus pinnwand_lesen or the other read tools in the sibling list. Usage is implied rather than guided.

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=false, destructive=false, idempotent=false, so the write/safety profile is covered. The description adds genuinely new behavioral context: visibility is agent-only and never surfaced on human pages, the team is not notified, and personal data/secrets are prohibited. It doesn't explain failure/validation behavior, so it stops short of a 5.

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-loads the critical constraint (agents only, never human-visible) and every subsequent sentence earns its place by routing a distinct alternative. Slightly dense with the run of sibling references, but no filler.

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 three required params, full schema coverage, and annotations covering safety, the description supplies the missing pieces: audience, visibility, length limit, and data restrictions. Return-value behavior is unspecified but no output schema exists and the tool's outcome is self-evident for a note store.

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 all three parameters are already documented. The description only restates the 4,000-character text limit already present in the schema and adds no syntax or content guidance for 'name' or 'thema'. Baseline 3 is correct when the schema carries the load.

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 ('stores a note for OTHER AGENTS only') and immediately disambiguates scope by naming sibling destinations it is not (pinnwand_schreiben, overfit_contact_request, interesse_melden). An agent can pick this over its 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?

Explicitly enumerates when to use it (project description, tips, general notes) and when not to, routing each alternative case to the correct sibling tool. The 'not messages to the Overfit team' and 'not public board posts' exclusions are precisely the routing guidance an agent needs.

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, openWorld, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: the data currency stamp ('Stand 2026-08-15') and the key output fields (datum ISO, name German, bundesweit boolean), which matter since no output schema exists.

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?

Purpose and routing come first, followed by output fields and example questions. The four example questions are somewhat repetitive in structure but do ground the German-language phrasing an agent is likely to encounter; overall it is appropriately sized with little waste.

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 two-parameter lookup with no output schema, the description covers scope, data currency, key return fields, and the sibling alternative. What remains unstated (exact response shape beyond three named fields, whether bundesweit true implies the holiday applies in the selected state) is minor.

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 jahr and land are already fully documented with range and enum descriptions. The description restates the scope implied by the land parameter (nationwide vs. one of 16 states) but adds no format or edge-case detail beyond the schema. Baseline 3 applies.

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 ('Returns the complete public holiday list for a year'), plus the scope variation (nationwide or one of the 16 federal states) and that state-specific holidays are included. It is clearly distinguishable from sibling werktage_berechnen, which is named as the tool for counting working days.

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 frames the use case ('Suited to the question which holidays fall in a year in a specific state') and routes the alternative case (working days between dates) to werktage_berechnen. No explicit when-not-to-use for other siblings, but the routing guidance is concrete.

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, closed-world. The description adds genuinely useful context beyond them: the Overfit dataset source, that NULL means 'not published' rather than zero, that small companies may legally omit revenue, and that no account or key is required. It does not mention rate limits or pagination, but no such concern is implied here.

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 purpose and returned fields, then edge cases (NULL, omitted revenue), then examples. Every sentence is informative, though the two long example questions and the firma_status aside make it slightly 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?

With no output schema, the description carries the full burden of explaining the return shape, and it does: it names the columns, explains the row granularity (one per fiscal year), and clarifies NULL semantics and legal omission of revenue. An agent has everything needed to interpret results 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?

Schema coverage is 100%, so register/to_year/from_year are fully documented in the schema, including the error semantics ('invalid format', 'not found') and the format of the register key. The description adds only the 'no account or key required' note, which is not parameter-level detail, so the baseline 3 applies.

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+resource: the financial history of a German company from filed annual accounts, one row per fiscal year, and enumerates the returned fields (Bilanzsumme, Eigenkapital, Jahresüberschuss, Umsatz, Mitarbeiter). It also explicitly carves out the sibling boundary: 'The alive status alone comes from firma_status.'

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 trigger examples ('What were the revenues of K1101_HRB52093 in 2022?') and directs the agent to firma_finden / earlier firm tool results as the source of the register key. It names firma_status as the alternative for status-only questions, but does not systematically cover when-not-to-use or other firm_* 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 only cover the read/idempotent safety profile, and the description adds substantially beyond that: the tool is temporarily unavailable until 2026-10-07 and returns status 'nicht_verfuegbar', ambiguous input yields status 'conflict' with all candidates listed, and a match is never guessed. This is exactly the operational context an agent cannot get from 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 most important fact (temporary unavailability) is correctly front-loaded, but the text is long and repeats itself — the '{CourtLetter}{4digits}_{...}' example and the court-code rule surface more than once, and the K1101_HRB52093 example is restated.

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?

There is no output schema, yet the description explains the return surface: the company profile plus ready follow-up calls, the 'conflict' branch, and the 'nicht_verfuegbar' status. Nothing an agent needs to call this 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 100%, so baseline is 3, but the description adds real semantic value: the accepted input formats per identifier type, the derived company_number_norm shape ('K1101_HRB52093' = HRB 52093, Amtsgericht Hamburg), and the rule that court codes cannot be inferred from city names.

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: 'Turns any identifier of a German company into its profile and its company_number_norm'. It explicitly positions itself relative to siblings firma_profil, firma_status and firma_finanzen, which the agent can distinguish 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?

Gives explicit when-to-use context (any of five identifier kinds), states the prerequisite other tools need (company_number_norm format), and names concrete failure conditions ('A bare HRB 12345 without the court finds nothing', court codes cannot be derived from city names). Alternatives are named, not 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 cover read-only, idempotent, non-destructive, closed-world behavior, yet the description adds real value: no account or key required, and explicit error semantics ('invalid format' vs 'not found', usually a wrong court code). It does not describe response shape, but with no output schema that is a minor 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?

Front-loaded with purpose and return fields, then examples, then related tools. Dense but every sentence carries routing or key-format information; slightly long due to three example questions that could be trimmed to two.

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-param, no-output-schema read tool, the description covers what is returned, auth requirements, error outcomes, and sibling routing. An agent has everything needed to select and invoke 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?

Schema coverage is 100% and the schema itself already documents format, derivation source, and error behavior, so baseline is 3. The description adds a little by anchoring the key format with the concrete example 'K1101_HRB52093' tied to user questions, aiding natural-language-to-key mapping.

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+resource ('Register profile of one German company') and enumerates the exact returned fields (name, address, legal form, register court, WZ code, website, alive verdict with as_of). It is immediately distinguishable from firma_status (bulk) and firma_finanzen (financial history), which are named.

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 routes among alternatives: 'firma_status checks up to 25 companies at once' (bulk), 'firma_finanzen returns the financial history', 'vergabe_suche finds tenders by topic'. This gives an agent clear conditions for choosing this single-company tool versus its 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 readOnly, idempotent, non-destructive, and openWorld=false. The description adds important behavioral context beyond annotations: about 98% return 'unknown' today, 'unknown' does not mean alive, each has an explanation, and the result includes an as_of date.

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 front-loaded with purpose and the critical unknown caveat, then adds use cases and alternative. It is slightly repetitive about the 25-register cap, which also appears in the title and schema, but overall remains efficient.

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 output schema, the description explains the return verdict and as_of date, warns about the dominant 'unknown' result, states the cap, identifies the alternative firma_profil, and notes no key is needed. This is complete enough for an agent 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?

Schema description coverage is 100%, and the single parameter is fully documented in the schema with format and maxItems. The description repeats the 25-register cap but adds no parameter semantics beyond what the schema already provides.

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: checks up to 25 German companies and returns an alive/dead/unknown verdict with as_of date. It also distinguishes the tool from firma_profil, which provides full profiles, so an agent can tell them apart.

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 clear use cases (CRM data cleansing, checking a supplier list) and example user questions. It names firma_profil as the alternative for full profiles and states that no account or key is required, leaving little ambiguity about when to invoke it.

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=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, so the write/non-idempotent profile is covered. The description adds real context beyond that: the request is reviewed by Overfit and feeds a prioritization process, and the notiz field must contain no personal data — info annotations cannot convey. No contradiction with 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?

Purpose is front-loaded in the first clause, followed by examples, the catalog reference, and the notiz constraint. The example list is somewhat long but each item concretely illustrates what counts as 'planned', so it largely earns its 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?

For a simple one-required-parameter write tool with full schema coverage and no output schema, the description covers purpose, where to get valid ids, the effect of the call, and the privacy constraint on notiz. Little that 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 100%, so schema already documents name/notiz/feature and their length limits. The description still adds meaning beyond the schema: `feature` must be an id drawn from overfit_catalog `planned`, and notiz must avoid personal data — a semantic constraint the schema does not state.

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 precise verb+resource: it records user interest in a feature that is PLANNED but not yet built, and enumerates concrete examples (sign-in from chat, credit top-up, API keys...). This scope clearly separates it from sibling data-retrieval tools, though it does not explicitly name a contrasting sibling such as overfit_contact_request.

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?

Usage is implied by the scope ('PLANNED but not built yet') and by the pointer to overfit_catalog under `planned` for valid values, which tells the agent where to source the feature id. However there is no explicit 'use this when / do not use this for X, use Y instead' statement, and the alternative for requests about existing features is left to inference.

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 genuine value beyond them by disclosing the return content (since no output schema exists) and noting that recording interest in a planned feature requires a different tool, i.e. this call has no write side effect. It does not mention pagination or rate limits, so it is not a full 5.

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?

Content is front-loaded with the return payload, and every sentence carries meaning. The parenthetical example list (sign-in, credit, API keys, tender alerts, data packages) is slightly dense but illustrates the `planned` field, so it earns its place; overall efficient with minor verbosity.

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 parameters and no output schema, the description carries the return-value burden itself and does so by enumerating the catalog contents, which is enough for an agent to call and interpret it. It stops short of describing structure/nesting of the `planned` entries, but is largely complete for a simple no-arg catalog.

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?

There are zero parameters and the description explicitly confirms 'No parameters', which is the baseline-4 case for a no-arg tool. Nothing further is required.

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 specific resource and enumerates exactly what is returned: products, user wishes mapped to matching tools, documentation URLs, and the `planned` upcoming-feature list. This is a catalog/discovery tool that is clearly distinct from its siblings (it is the only 'what does Overfit offer' tool), and it even clarifies the boundary with interesse_melden. An agent can identify the tool's purpose without opening anything else.

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 states explicit trigger contexts: 'Suited to questions what Overfit offers, what is planned, or where the documentation is,' and it points to the alternative (interesse_melden) for recording interest in a planned feature. That covers when-to-use and one alternative, but there is no explicit when-not guidance, so it falls short of a 5.

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 and destructiveHint=false, but the description adds material context beyond them: 'Nothing is sent: the tool only returns a URL and a mailto link, which the user reviews and opens.' This clarifies the human-in-the-loop, no-side-effect nature of the operation, which the annotations alone imply but do not spell out.

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 tight sentences, front-loaded with what the tool produces, then fit, then the no-send guarantee. Every sentence earns its place with no filler.

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?

No output schema exists, and the description compensates by stating exactly what is returned (a URL and a mailto link) and that nothing is transmitted. Combined with the read-only/idempotent annotations, an agent has everything needed to call this 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?

Schema description coverage is 100%, so topic, summary, company and callback are already documented, including the enum values. The description adds no format or usage guidance for any parameter, so baseline 3 applies.

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 artifact: 'Generates a prefilled contact URL and mailto link for the user to send to Overfit.' It also scopes the tool ('requests not covered by other tools'), which separates it from siblings like interesse_melden or overfit_catalog.

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 enumerates suitable cases (custom AI projects, company data packages, feedback, uncovered requests), giving clear when-to-use context. It stops short of naming a specific alternative tool to prefer when the request IS covered, so no explicit when-not 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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description usefully adds that only public posts are returned and that a 7-day count is included, but discloses nothing about pagination, rate limits or auth needs.

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 tightly packed sentence that front-loads the action and enumerates the returned fields with no wasted words.

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 output schema, the description carries the return-value burden and does so by listing the post fields plus the weekly count. It omits any note on result ordering beyond 'latest' or truncation behavior under limit.

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% and the single 'limit' parameter is fully documented in the schema (default 20, max 50, min 1). The description adds no limit syntax or default behavior, so baseline 3 applies 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?

States a specific verb and resource: 'Returns the latest public posts of the agent board.' The read nature is clear enough to contrast with the write sibling pinnwand_schreiben, but that sibling is never named, so differentiation is implicit rather than explicit.

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?

Usage is implied ('latest public posts' implies reading the board) but there is no when/when-not guidance, no mention of the write counterpart pinnwand_schreiben, and no note on how this differs from agenten_notizen_lesen.

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?

Beyond the annotations (write, open-world, non-idempotent), the description discloses high-value behavioral facts: the post is PUBLIC, personal data is forbidden, the connection country is attached, and there is a soft rate cap of a few posts per day per connection. None of this is recoverable from the schema or 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?

The critical constraint (public post) is front-loaded and the sentence stays dense but purposeful. It is slightly long for a two-field tool, though every clause carries usable 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?

For a write tool with no output schema, the description covers the full picture an agent needs: visibility, character limits, rate limits, content restrictions, and the shape of a valid call. Nothing essential 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 coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that 'name' is displayed publicly with the post and that 'nachricht' is plain text, illustrated by a worked example. That reinforces rather than merely repeats 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?

States a specific verb and resource ('Posts a short PUBLIC message to the agent board'), pins the destination URL, and makes the public scope explicit. An agent can immediately distinguish it from the read-side sibling pinnwand_lesen.

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?

Concrete usage context is given via 'Typical posts: a greeting, what Overfit was used for, which data would help next,' plus the per-connection posting rate. It stops short of naming an alternative or explicit when-not-to-use condition, so it's clear context without full routing 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 declare readOnly/idempotent/openWorld, so the bar is low, yet the description adds substantial behavior: the state-dependent sub-threshold selection logic (federal→UVgO, MV→own rules, others→generic guidance), EU threshold handling, special-case flags, and data currency (Stand 2026-08-15). This is real decision logic not derivable from 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?

Front-loaded with the return shape and applicability, and every sentence carries information. It is somewhat long, and the example-question list is a bit padding-like, but nothing is truly 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?

For a 9-parameter domain tool with no output schema, the description covers what is returned, how sub-threshold rules are selected, which inputs trigger special-case logic, and where sibling tools take over. Nothing an agent needs to invoke 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 coverage is 100%, so the baseline is 3. The description goes further by explaining the bundesland-vs-regelwerk precedence (bundesland selects the framework; regelwerk is only an override below the EU threshold), which the schema does not spell out.

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+resource (determining the permissible procurement procedure) and immediately enumerates the returned statuses (frei/voraussetzung/nein) and legal bases. It explicitly separates itself from vergabe_fristen_berechnen and wertungsmatrix_berechnen, so an agent can distinguish it from siblings 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?

Names the exact question class it answers ('which procedure type is required or permissible') and lists concrete example user questions in German. It also states when other tools apply (deadlines and bid scoring are handled by the two named siblings), giving explicit when-to-use and when-not-to-use 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 safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description's job is supplementary. It adds a concrete rate limit (30 requests / 10 min, 200 / day per IP) and discloses that the response carries a numeric notice_id for chaining into the voll tool — genuinely useful operational context. It does not describe pagination or truncation behaviour, which keeps it from a 5.

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 returned-field list is front-loaded and the routing/rate-limit details follow in a logical order. The five example user questions are somewhat padded, though they plausibly aid intent matching in a German-language domain.

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 output schema, the description compensates by enumerating the payload (title, authority contact fields, dates, CPV/NUTS, AI summaries, deliverables, risk flags, eligibility, portal URL). Combined with rate limits and the sibling hand-off for deeper data, an agent has everything needed to call this 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?

Schema description coverage is 100%, so the baseline is 3. The description goes beyond it by restating the 'source:id' format with three concrete portal examples and by naming the exact field the value is copied from in sibling results, which reduces invocation error. It adds little else about the single parameter, so not a 5.

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 ('Returns full detail for one notice') and enumerates the returned content, so an agent knows exactly what it retrieves. It also explicitly contrasts itself with the sibling vergabe_bekanntmachung_voll, which handles document lists, structured sections and Q&A.

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?

Tells the agent where the required uid comes from (the uid field in vergabe_suche or vergabe_liste results) and names the alternative tool with the condition that selects it (vergabe_bekanntmachung_voll, taking notice_id, for documents/Q&A). When-to-use and when-to-use-something-else are both explicit.

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?

Far exceeds the annotations (which only cover read-only/idempotent safety): it explains the assistant_ready gating semantics, the download_status enum meanings (ok/pending/failed/skipped), that the files themselves are NOT returned but reachable via procedure_room_url/detail_url, and concrete rate limits (30/10 min, 200/day). This is unusually rich behavioral disclosure.

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 purpose, then a compact field guide and example queries; every block earns its place. It is dense and somewhat long, with a little duplication between the body and the schema property text, but nothing is wasted filler.

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?

No output schema exists, so the description must carry the return-shape burden, and it does: it names the field groups, the flag that gates them, the status vocabulary, and what is deliberately omitted (the files). An agent has everything needed to call and interpret this 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% and the single parameter is self-documenting, but the description still adds cross-tool context by mapping where notice_id comes from across vergabe_suche, vergabe_bekanntmachung and vergabe_liste (field 'notice_id' vs field 'id'), reducing a common source of invocation error.

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+resource: 'Complete record of one tender' and enumerates exactly what it returns (all vergabe_bekanntmachung fields, AI-structured sections, Q&A list, facets, documents). It is clearly differentiated from the sibling vergabe_bekanntmachung, which it explicitly builds on.

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?

Provides real decision context: the `assistant_ready` flag tells the agent when AI sections are populated vs empty, and it warns that the input is the numeric notice_id, not the string uid used by vergabe_bekanntmachung. It stops short of an explicit 'use this instead of X when…' rule, but the German example questions anchor the intended use cases.

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, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the return shape (effective end date plus per-step legal reasoning for each reduction), the normalization rule, and the legal basis with a currency date (Stand 2026-07-14). It stops short of noting anything about edge cases or invalid inputs.

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 purpose before the legal citations and examples. The five example questions are somewhat verbose but serve retrieval and routing, so they earn their place. Minor redundancy in the legal-scope sentence.

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 output schema, the description correctly explains what is returned (end date plus per-step reasoning) and enumerates the covered frameworks and reductions. Nothing essential to correct invocation is missing for a read-only calculation 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 description coverage is 100%, so all six parameters including the reduction flags and enum meanings are already documented in the schema. The description restates the reduction factors (electronic, prior notice, urgency) at a high level but adds no syntax or interaction detail the schema lacks. Baseline 3 applies.

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?

Names a specific verb+resource (returns the effective end date for submission/participation deadlines) and states the legal scope (VgV, VOB/A Abschnitt 2 EU) plus the computation rule (shift to next working day per VO 1182/71). It explicitly distinguishes itself from the sibling vergabe_wartefrist, which handles the § 134 GWB standstill period.

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?

States the exact class of question it answers ('which date a submission deadline falls' or 'whether the minimum period can be shortened') and names the alternative tool for a different deadline type. The listed example questions reinforce when to reach for it.

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, openWorld, non-destructive), yet the description still adds hard operational facts: rate limits (40 requests / 10 min, 300 / day per IP), the offset ceiling of 2000 with a 403 above it, and data freshness (190,000+ notices, federal portal refreshed every 30 minutes). It also discloses non-obvious result semantics – the same tender appearing once per portal with different uids and how to recognise a duplicate – which no annotation or schema field conveys.

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 purpose, then IDs, then dedup, then use cases, then limits – a sensible priority order with no filler sentences. The five example questions partially overlap with the preceding 'Suited to...' sentence, which adds a little redundancy to an otherwise dense block.

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 16-parameter, no-output-schema tool in a complex domain, the description covers limits, freshness, dedup rules and the id/uid fields each hit carries, which is close to sufficient. It stops short of describing the remaining result payload (totals, what a hit contains beyond id/uid), the only meaningful gap against a missing output schema.

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%, so every one of the 16 parameters is already documented in the schema (including q's non-semantic caveat and order_by='score' requiring q). The description mostly restates examples already present (cpv_prefix=72) and its additional value concerns result fields (id/uid linkage) rather than input parameters, so the baseline 3 applies.

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 opening sentence names a specific verb (paginated list), the exact resource (German and EU tender notices), and the filter dimensions, then explicitly separates itself from the semantic sibling: 'Matching by meaning is done by vergabe_suche.' An agent can route between vergabe_liste, vergabe_suche and vergabe_bekanntmachung 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?

It states the conditions that select this tool ('Suited to structured listings, e.g. all open IT tenders (cpv_prefix=72)...'), names the alternative for the excluded case (vergabe_suche for meaning-based matching), and supplies five concrete example queries with an explicit 'Example user questions' anchor. Contrast with alternatives is explicit rather than inferred.

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 readOnly/openWorld/idempotent/destructive, so the bar is lower, and the description still adds real context: no rate limit, a single optional parameter, and an explicit consistency guarantee that counts match vergabe_liste (same visibility gate, same stale-deadline exclusion). It does not describe the response shape, but the consistency and rate-limit notes are substantive additions beyond 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?

Front-loaded with the core behavior (counts by portal and status) and then efficient supporting facts: consistency with vergabe_liste, no rate limit, parameter count. The example-questions block is slightly redundant with the opening sentence but earns its place as routing signal. No wasted filler.

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?

No output schema exists, yet the description conveys what comes back (per-portal counts by status) plus the visibility/staleness semantics governing those counts, and annotations carry the safety profile. The only real gap is that the dead-portal handling is not explained in prose, but the referenced parameter and listed example questions cover most agent needs.

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 include_dead is fully documented there, establishing the baseline of 3. The description only says 'One optional parameter' without naming include_dead or adding meaning about what excluding dead-portal notices implies for the counts, so it neither compensates nor detracts.

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: per-portal notice counts broken down by status, explicitly listing example portals (TED EU, Vergabe-Bund). It carves out a distinct niche from siblings like vergabe_liste and vergabe_statistik by framing itself as a source-coverage breakdown, so an agent can differentiate 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?

The example user questions ('Welche Vergabeportale sind in der Suche enthalten?', 'Woher kommen die Daten...') effectively tell the agent when this tool is the right answer. However, it never explicitly contrasts with vergabe_statistik, which is the closest sibling and the most likely mis-selection, so the routing guidance stops short of full exclusions.

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=false, so safety is covered. The description adds real behavioral context the annotations cannot: the thresholds are time-bound (valid 2026-01-01 to 2027-12-31 per Delegierte VO (EU) 2025/2152), change every two years, and prior values are outdated, plus an explanation of schwelle_alt_eur and schwelle_hinweis. No auth/pagination info, but none is relevant for a pure lookup.

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 core answer is front-loaded, then it adds validity context, output fields, and example questions. It is information-dense and most sentences earn their place, though the legal-citation and output-field enumeration edge toward verbosity for a read-only lookup.

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 output schema, the description fully compensates by enumerating key return fields (oberschwellig, schwelle_eur, regime, rechtsgrundlage, gueltigkeit, schwelle_alt_eur, schwelle_hinweis) and the legal basis. Combined with complete param documentation and annotations, an agent has everything needed to call and interpret it.

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%, so the schema already documents wert, auftraggeber, and leistungsart thoroughly (including enum meanings and German number formatting). The description's additional value is limited to noting the leistungsart value alignment/alias with verfahrenswahl_ermitteln, which is marginal beyond the schema, so the baseline of 3 is appropriate.

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+resource (checks the current EU procurement threshold) and precisely scopes the deliverable: above/below threshold, the applicable regime, and sub-threshold limits. It also distinguishes itself from the sibling verfahrenswahl_ermitteln by noting that procedure types are determined there, so an agent can tell the two 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 names the use case (does a contract require EU-wide publication or stay within national sub-threshold rules) and backs it with several example user questions. It clarifies its boundary against verfahrenswahl_ermitteln, but does not state any when-not-to-use conditions or other alternatives, so it stops short of a 5.

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 and openWorld, so the safety profile is covered. The description adds genuinely new context: 'live' data, no rate limit, and the precise definition of 'urgent' (deadline ≤ 14 days), which an agent could not infer from the annotations alone.

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 behaviour and field list, followed by usage context and examples. Every sentence earns its place, though the example-question block is a little verbose for a no-parameter count tool.

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?

There is no output schema, and the description compensates by listing the key return fields and clarifying the semantics of the 'urgent' bucket and data freshness. For a parameterless statistics endpoint, an agent has everything needed to select and call it.

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 zero parameters the baseline is 4. The description goes slightly beyond by naming the key output fields (open_count, urgent_count, etc.), which is a bonus rather than a requirement for a parameterless tool.

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 (returns counts) and resource (Vergabe notices) and enumerates exactly what is counted: open, urgent, awarded, total, plus URL health and model name. This clearly distinguishes it from siblings like vergabe_liste or vergabe_suche, which return notices rather than aggregate statistics.

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 says it is 'suited to questions about database size and current tender counts' and gives three concrete example questions, so an agent knows the triggering intent. It does not, however, name alternative siblings (e.g. vergabe_liste) or state when NOT to use it, so the routing guidance is implicit rather than exclusionary.

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 safety (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely non-obvious behaviour: rate limits per IP with the exact error semantics, and the cross-portal duplication quirk (same tender appears once per portal with different uids; same title+authority+deadline means one tender). That dedup rule materially changes how an agent should interpret results.

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?

Purpose and routing are front-loaded in the first two sentences, and the coverage/limit/dedup details each carry operational weight. It is long, though: the 'Key filter parameters' enumeration duplicates the schema and the five example questions are repetitive, so a little trimming would help.

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 search tool with no output schema, the description compensates well by enumerating the returned fields and by explaining index coverage versus source coverage (190k+ notices vs 100k+ indexed), the update cadence, and deduplication. Nothing an agent needs to issue a correct call and interpret results 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 100%, so all 12 parameters (including enum values and repeat-for-OR semantics) are already documented. The description only re-lists 'key filter parameters' (Bundesland, status, cpv, nuts, deadline_after/before, notice_type), which is redundant rather than additive; baseline 3 is appropriate.

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 opening sentence gives a specific verb (semantic search) and resource (German and EU public tenders), then lists exactly what is returned (ranked notices with AI summary, deadline, authority, CPV/NUTS, uid, notice_id). It explicitly names the sibling vergabe_liste as the tool for non-semantic, filter-only queries, so an agent can discriminate 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?

Routes the agent explicitly: topic/keyword/industry requests go here, 'structured filter queries without a topic description' go to vergabe_liste, and just-published notices newer than the index are found via vergabe_liste (order_by=publication_desc). It also documents the rate-limit escape hatch (vergabe_liste's q parameter) and states the ~10 queries/day/IP cap with 429/Retry-After behaviour.

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 declare readOnly/idempotent/openWorld, and the description adds substantial domain behavior beyond that: exactly what date 'absendung' means, that both § 134 interpretations are returned, the 10/15-day split by dispatch mode, the legal positions (VK Bund vs OLG Bremen), and that the conservative date is safer. This is behavior an agent cannot infer from 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?

Front-loaded with the core semantics, then the legal nuances, then examples. Dense but organized. Slightly over-long — the example-question sentence is somewhat redundant given the preceding usage sentence — but every block 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?

A no-output-schema, 3-parameter computation tool is fully covered: the meaning of each parameter, the two returned date interpretations, the legal ambiguity, which is the safer choice, and which sibling handles adjacent deadlines. Nothing an agent needs to call or interpret this 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 coverage is 100%, so the baseline is 3; the description still adds meaning by clarifying that 'absendung' is the bidder-information dispatch date, not the contract notice date, and that 'land' only affects the practical date. That disambiguation is valuable even against a well-described 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?

States a specific verb+resource: computes the earliest award date (Wartefrist) under § 134 GWB. Clearly distinguishes from sibling vergabe_fristen_berechnen, which it names as handling tender/participation deadlines instead.

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 names the use case ('Suited to the question on which date a contract may be awarded') and routes the sibling case (tender/participation deadlines) to vergabe_fristen_berechnen. Includes example user questions that map directly onto invocation scenarios.

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, so the description only needs to add context — and it does, disclosing the holiday computation basis (Gauß Easter formula) and a data vintage (Stand 2026-08-15), which tells the agent how trustworthy results are for future years. It stops short of stating error behavior for invalid state/mode combinations or out-of-range dates.

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?

Purpose, modes and the sibling exclusion are front-loaded in the first two sentences, which is exactly the right ordering. The trailing list of example user questions is somewhat long and largely paraphrases the mode description, but it does aid retrieval matching.

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 output schema, the description takes on the return-value burden and does so by stating it returns either a working-day count or a target date. Combined with mode semantics, holiday basis and the sibling exclusion, an agent has enough to call it correctly; only error and boundary behavior remain unstated.

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%, so every parameter including the mode enum and the samstag flag is already documented in the schema; the description's restatement of add/count semantics duplicates rather than extends it. No additional syntax or edge-case guidance (e.g. end-date behavior when tage lands on a holiday) is added, so the baseline 3 applies.

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 (working-day count or target date), scopes it to the 16 German federal states with the full state-specific holiday set, and explicitly names the sibling that handles the adjacent case (vergabe_fristen_berechnen for procurement deadlines). An agent can distinguish it from the other vergabe_* date tools 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?

Gives an explicit routing rule: procurement-law deadlines count calendar days under VO 1182/71 and belong to vergabe_fristen_berechnen, not this tool. It also names the two modes and the question shapes each serves, plus concrete example queries, leaving nothing to inference.

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 readOnly/idempotent/non-destructive, but the description adds real behavioural context: one method per call, default einfach, the precondition on existing quality scores, the responsibility boundary with the contracting authority, and the legal framing (§ 127 GWB, § 58 VgV, UfAB 2016). It also names key output fields despite there being no 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?

Well front-loaded with purpose and methods first, but it is long and repeats the quality-scores precondition twice ('existing quality scores' / 'quality scores have to exist already' / 'Evaluating quality ... remain with the contracting authority'). The example-questions block adds bulk without new 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?

For a 5-parameter analytical tool with no output schema, the description supplies everything needed: method selection, preconditions, defaults, legal basis, and the key output fields (sieger, zeilen[] with kennzahl and rang, sensitivitaet, legal_basis). Nothing an agent needs to invoke or interpret the tool 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 coverage is 100%, so the baseline is 3, but the description goes further: it explains the cross-parameter relationship ('percentage weights ... correspond to gewichtet with gewichtLeistung=60') and ties each enum value to a real-world scenario, which the schema alone does not do.

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 ('computes the score and ranking of bids under the chosen UfAB scoring method') and immediately enumerates the three method variants, so an agent knows exactly what this tool produces. It is clearly distinct from siblings like vergabe_statistik or verfahrenswahl_ermitteln.

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?

Maps typical user phrasing to concrete method choices ('Preis 40 %, Leistung 60 %' → gewichtet; 'best quality per euro' → einfach; 'leading group plus tie-break' → erweitert) and states the precondition that quality scores must already exist. It also draws the scope boundary that quality assessment and the award decision remain with the contracting authority.

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