Vergabeweiser

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

Annotations already establish readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely non-structured context: the term is derived from the notice's end date or duration, renewals are excluded from the cutoff, and the follow-on tender is probable but not guaranteed — the last point is important interpretive caveat for an agent.

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, front-loaded with the resource definition before the caveat and the input requirement. The parenthetical "(end date or duration, without renewals)" is dense but each clause carries meaning; only minor tightening is 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?

With no output schema, the description does the right thing by naming the returned fields (winner, renewals, offers). The main residual gap is nothing about result volume, ordering or pagination for what could be a long list, but nothing needed 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 coverage is 100%, so 3 is the baseline. The description goes beyond the schema by expressing the disjunctive constraint that at least one of gewerk, land or buyer must be supplied — something the flat optional object schema does not convey — and by clarifying that 'months' measures from today.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (awarded service and supply contracts) and a specific filter (term ends within the next months per the notice), plus the fields returned. It does not name a sibling such as search_tenders or get_company_awards to draw the contrast explicitly, so it stops just 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?

"Needs at least gewerk, land or buyer" gives a concrete minimum-input precondition, and "A new tender is likely but not certain" tells the agent how to frame the result. There is no explicit when-not or named alternative, so it is clear context without 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?

Beyond the readOnly and idempotent annotations, it discloses ordering (most active first), result fields, and eligibility limits (only indexed organisations; no sole traders). It does not cover pagination or result limits, so it is not fully exhaustive.

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 compact sentences front-load the purpose, then cover return fields, downstream tools, ordering, and eligibility. There is no redundant or filler text.

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 naming the returned fields and ordering. For a two-parameter read-only lookup, the eligibility constraints and downstream use make the definition complete enough to invoke 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 name minimum length and type enum/default are already documented. The description adds useful query examples but little additional parameter semantics 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 and resource: find contracting authorities and companies by name or prefix. It includes concrete examples and distinguishes the result from sibling tools by saying the returned slug/URL feeds get_buyer and get_company_awards.

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 clearly positions the tool as a lookup step before get_buyer or get_company_awards and explains the optional buyer/company filter. It does not explicitly exclude other lookup approaches, but the downstream usage context is strong.

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 and idempotentHint, so the safety profile is covered. The description adds genuinely useful scope constraints beyond that: no person data is included, and the entity may be a law firm or central purchasing body acting for the actual contracting authority. It says nothing about response size, aggregation lag, or how much history the awards/winners sections cover.

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?

It is compact and front-loads the resource, but it is a single comma-chained sentence fragment with two stacked parentheticals, which makes it harder to parse than a short verb-led sentence plus a scope clause. Little is wasted, but the structure is run-on rather than crisp.

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 burden of describing the return payload, and it does so by enumerating the sections returned. Combined with a fully documented single parameter and read-only annotations, an agent has enough to call it correctly; only cross-tool routing against find_organisations remains 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 100% and the single slug parameter is fully documented in the schema, including the URL form. The description adds no syntax or format detail about the slug, so the baseline 3 applies; nothing is lost because the schema already handles it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (a contracting authority / Vergabestelle) and enumerates precisely what is returned: contact data, platforms, open tenders, recent awards, offers per award, frequent winners, trades, expiring contracts. That is far more specific than the title 'Vergabestelle abrufen', though it is phrased as a noun fragment with no explicit verb and does not distinguish itself from the similarly-organisation-oriented sibling find_organisations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one real routing hint: use the contact in the notice when the goal is a specific procedure ('for a procedure use the contact in its notice'), implicitly pointing to get_tender. But it never says when a caller should use this instead of find_organisations, get_company_awards or search_tenders, which is the main ambiguity given the sibling list.

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 read-only/idempotent safety profile, and the description adds real domain behavior: fixed 25-per-page pagination and, importantly, the semantics of firm_shared_max (a shared lot ceiling that is not attributed to this company's sum or share). That caveat materially changes how an agent should interpret the numbers. It doesn't describe the overall response shape, but no output schema exists to lean on.

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 return contents, then a separate sentence for the firm_shared_max caveat — both earn their place. The first sentence is long and comma-heavy, slightly taxing to parse, but there is 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 no output schema, the description carries the burden of explaining returns and does so by listing the aggregate sections and the per-page size. Combined with the entity restriction and the firm_shared_max note, an agent has enough to call it and read results sensibly; only the exact response envelope is 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 coverage is 100%, so both parameters are already documented, and 'page: 25 per page' merely restates the schema. The slug guidance (slug or full URL, from an unternehmen page) adds modest value by tying valid inputs to the tool's entity restriction, but nothing beyond that.

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 ('Contracts won by a company') and enumerates the returned components (totals, buyers, Länder, trades, awards, published sum). It also pins the scope tightly — legal entities with an unternehmen page, never sole traders — so an agent knows exactly what population this covers versus the tender/buyer-oriented siblings.

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 a clear applicability condition (only companies with a vergabeweiser.de/unternehmen page; sole traders are excluded) and points at where the slug comes from. It stops short of naming an explicit alternative tool for the sole-trader or non-company case, so the when-not path is implied rather than routed.

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 and idempotentHint, so safety is covered and the description need not restate it. Instead it adds genuinely non-obvious context: the exact content of the response envelope and a caution that result.framework_max is a framework ceiling, not an award sum. That is interpretation guidance annotations cannot carry. It stops short of noting behavior on an invalid or unknown id.

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

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

Two sentences, front-loaded with the payload contents, followed by the one interpretive warning that matters. The enumeration is dense but every item maps to a real field an agent will encounter. No filler or 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?

With no output schema, the description correctly takes on the burden of describing the return shape and does so in detail. The framework_max caveat closes the most likely misreading. What remains unaddressed is failure behavior for a bad or unknown id and whether fields can be absent for tenders that have not yet been awarded.

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 id parameter is already documented in detail, including the 8–12 character format and the URL alternative. The description adds nothing about the id, which is acceptable given the schema does the work, but it is the baseline rather than an enhancement.

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?

Opens with a precise verb+resource ('One tender') and then enumerates exactly what comes back: deadlines, procedure, lots, result with winners and sums, document and notice links. That is far more specific than the title 'Ausschreibung abrufen'. It implies the single-record counterpart to search_tenders but never names that sibling, so the differentiation is inferred rather than 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?

Usage is only implied: the tool takes a single tender id, so an agent can infer it is the follow-up to a search. There is no explicit statement of when to prefer it over search_tenders, and no guidance on how to obtain the id in the first place. Adequate but leaves the routing 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 readOnlyHint=true and idempotentHint=true, so safety and repeatability are covered. The description adds the useful fact that the output is intended as input values ('slugs ... for the other tools'), but says nothing about result size, locale of labels, or whether the list is static.

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 compact sentence with the key noun ('slugs') front-loaded and the audience/purpose trailing. No waste, though the fragment style is slightly telegraphic and could state the verb for clarity.

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 lookup tool with no output schema, the description covers what is returned (slugs for two category types) and why (use in other tools). Minor gaps remain around output shape and whether German labels accompany the slugs.

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. The schema is empty and fully consistent with a no-argument enumeration call.

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 the resource precisely – slugs of all trades (Gewerke) and Bundesländer – so an agent knows this is a reference/enumeration tool, distinct from siblings like search_tenders or get_tender. It lacks an explicit verb ('list'), but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'for the other tools' implies the usage pattern: call this to obtain valid slug values to pass into sibling tools. However, it never states when to call it versus alternatives, nor that results should be cached or that slugs are required inputs elsewhere — the guidance is inferable but not 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?

Annotations already declare readOnlyHint and idempotentHint, but the description adds meaningful behavioral context by specifying the metrics and time windows returned: tenders in the last 12 months, open now, median offers per award, single-offer share, award-sum quartiles, and frequent winners. It does not discuss pagination or response shape, but the metric list is substantive 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?

The definition is a single front-loaded sentence that states the scope first and then compactly lists the returned metrics. Every clause earns its place by clarifying either the aggregation level or the statistic produced.

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 does a good job listing the key metrics an agent will receive, and the required trade parameter plus optional geography are covered by the schema. A minor gap remains around the default behavior when land or kreis is omitted, but overall it is complete enough for correct invocation.

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 explains land, kreis, and gewerk, including examples and slug requirements. The description reinforces the geographic hierarchy and single-trade scope but adds no parameter-level detail 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?

The description clearly states that this tool provides market statistics for one trade at Germany, Bundesland, or Kreis level, and it enumerates the specific metrics returned. It is distinguishable in practice from listing/search siblings because it is an aggregate analytics tool, though it does not explicitly differentiate itself by naming those siblings.

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: call this to get aggregate market figures for a trade in a geography. However, the description does not explicitly say when to use this instead of search_tenders or list_categories, nor does it state that gewerk must first be obtained from list_categories, even though the schema mentions that dependency.

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 and idempotent behavior, so the bar is lower. The description adds valuable return behavior: 20 results per page, returned fields, page URL, and a domain caveat about result.framework_max not being an award sum.

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 with the core action and scope front-loaded. The return behavior and framework_max caveat are included without unnecessary 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 an 11-parameter search tool with full schema descriptions and no output schema, the description is mostly complete: it explains the search style, pagination, and key result semantics. Minor gaps remain around sibling routing and slug-source guidance, though the schema covers parameter details.

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 parameter definitions already carry most semantics and the baseline is 3. The description adds a free-text example and clarifies framework_max, but much of its parameter-related content overlaps with the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: "Search German public tenders" with a clear scope and list-style result. The analogy to vergabeweiser.de/suche helps, but it does not explicitly distinguish itself from siblings such as get_tender or expiring_contracts.

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 useful usage detail for free-text search, including examples combining trade and place, but does not explicitly state when to use this tool versus sibling tools or when not to use it. Usage is implied rather than routed.

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