transparent.ruhr

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the payload shape (documents, inquiry answers, Urheber, related Drucksachen), which matters because no output schema exists. It stops short of describing failure or empty-result behavior.

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

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

The purpose sentence comes first, followed by compact parameter hints in the same 'field: values' style. No filler, though the opening sentence is long and packs several distinct return elements together.

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 two required string params, no output schema, and read-only annotations, the description covers both the input vocabulary and the returned content. Remaining gaps are minor: no error/not-found behavior and no statement that identifiers are scoped per parliament.

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 0%, so the description must carry the parameters and it largely does: it enumerates the accepted parlament values (bundestag, berlin, brandenburg, sachsen) and defines nummer's format as "Wahlperiode/Nummer" with the concrete example "21/8318". It does not explicitly state that the parliament list is exhaustive or address casing, keeping it from 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 concrete resource (a Drucksache from parlamente.org) and specifies exactly what comes back: all documents, the answer for inquiries, authors, and related papers of the same Vorgang. It is clearly a direct fetch-by-identifier rather than a search, but it never names drucksachen_suchen as the contrasting search tool.

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: you need both a parliament and a Wahlperiode/Nummer, which signals a known-item lookup. There is no explicit statement of when to use this versus drucksachen_suchen, nor any note about what happens when the identifier does not exist.

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 establish readOnlyHint=true and openWorldHint=false, and the description adds useful behavior: newest-first ordering, cross-parliament scope, and the important counting rule that fraktion refers to the introducing caucus, not the answering government. It does not describe pagination or response/error behavior, but the core behavioral context is strong.

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 compact and front-loaded: first the resource and ordering, then an example, then parameter-by-parameter semantics. Every sentence adds usable information without repetition.

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 six-parameter search tool with no output schema, the description covers scope, ordering, filtering, and all parameter meanings thoroughly. It could mention result structure or pagination behavior, but nothing essential to invoking the search correctly appears 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?

With 0% schema description coverage, the description fully compensates by defining all six parameters: suchbegriff prefix/all-words matching, parlament allowed values and empty behavior, fraktion accepted abbreviations and counting semantics, art examples, seit date format, and anzahl range 1–50. This is exactly the parameter meaning an agent needs beyond the bare 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 clearly states a specific search operation over Drucksachen from Bundestag and Landtage, cross-parliament, newest first, and gives an example. It does not explicitly differentiate this search tool from siblings such as drucksache (singular) or vorlagen_suchen.

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 use case implies a search/list scenario, but the description does not explicitly say when to use this tool versus siblings like drucksache or vorlagen_suchen. Use is inferable but not 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral constraints beyond the annotations: only current committees are returned, and member lists are excluded. It does not describe the shape of the returned records or any ordering/paging behavior, so the added value is real but limited.

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

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

A single well-formed sentence with the resource and scope front-loaded and the parenthetical examples doing useful disambiguation. Nothing is redundant, though the terseness leaves gaps that a slightly longer sentence could have closed cheaply.

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 one-parameter read tool with no output schema, the definition is minimally sufficient: it says what is listed and what is excluded. It is incomplete on the identifier format for 'kommune' and on the fields an agent can expect per Gremium, both of which matter for chaining into sitzung or vorlage calls.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and 'kommune' is undocumented in the schema. The description only implies it identifies the Körperschaft; it never says whether it is a name, an official municipality key, or an internal ID, nor what happens on an unknown value. With one parameter and no schema help, the description should have compensated and did not.

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 (Gremien) with concrete examples of what it covers (Rat, Ausschüsse, Bezirksvertretungen, Fraktionen) and a scope qualifier (aktuelle, einer Körperschaft). The retrieval verb is only implied by 'Die aktuellen Gremien', and there is no explicit reference to a sibling, but no sibling covers committees so the intent is still 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?

There is no statement of when to use this tool versus alternatives such as kommunen (to resolve the Körperschaft) or sitzung/vorlage (for members and agenda items). The only guidance is the negative 'ohne Mitglieder', which tells the agent what it will not get but not where to go instead.

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 openWorldHint=false, so the safety profile is covered. The description usefully discloses the return content (Kürzel, Website, Vorlagen count) that no output schema provides, though it says nothing about ordering, pagination, or freshness of the data.

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

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

Three short sentences, each earning its place: what is listed, what the key is for, and which sibling covers the other scope. The core purpose is front-loaded in the first 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 zero parameters and no output schema, the description carries the burden of explaining the return shape and does so by listing the fields. Combined with the routing hint to a sibling, an agent has everything needed to call and use the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the schema imposes nothing to explain, which sets the baseline at 4. The description adds value by explaining what the returned `kommune` key is used for, even though that is an output rather than an input concern.

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 ('Listet die Körperschaften auf transparent.ruhr') and enumerates the returned fields (Kürzel, Website, Zahl der Vorlagen). It also distinguishes scope from `drucksachen_suchen` (Landes-/Bundesparlamente), so an agent can tell the two apart 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?

Explicitly routes the agent to `drucksachen_suchen` for state and federal parliaments, which is a real exclusion rule. It also signals that the returned `kommune` key is the input other tools need, implying this is the entry point, though it never states outright that it should be called first.

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 openWorldHint=false, so safety is covered; the description adds real value by disclosing completeness behavior — results are included only 'soweit die Quelle sie liefert' and nichtöffentliche Punkte are excluded. That tells the agent the payload may be partial, which is exactly the kind of trait annotations cannot express.

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

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

Three short clauses, front-loaded with the resource and its contents, then the exclusion caveat. No filler, though the phrasing is a noun phrase rather than a directive 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 must describe returns, which it does adequately, but for a tool requiring two mandatory arguments at 0% schema coverage the definition leaves the caller without any parameter context. Return-shape coverage is good; input coverage is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and both required parameters (kommune, id) are completely undocumented in schema and description. The description never mentions that a municipality and a session identifier are needed or what format they take, so it fails to compensate for the coverage gap, though the singular 'Sitzung' faintly implies an id lookup.

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 single Sitzung) and enumerates its payload: Tagesordnungspunkte, zugehörige Vorlagen, and Ergebnisse. That distinguishes it from siblings like sitzungen (list) and vorlage/drucksache (individual documents), though the retrieval verb is only implied.

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

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

No statement of when to use this versus sitzungen or vorlage, and no prerequisites are given. The only usage-adjacent information is the exclusion of non-public agenda items, which is a scope constraint rather than 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral details beyond annotations: the default date window and the prefix-matching semantics of `gremium` with a concrete exclusion example ("Rat" finds the Rat, not Integration or Beirat). It does not mention pagination or result-count behavior, 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 description is front-loaded with the core purpose, followed by focused notes on key parameters and a pointer to the related tool. Every sentence earns its place; there is no redundancy or 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?

Given the 5-parameter schema with 0% description coverage and no output schema, the description should do more. It covers purpose, default date range, and `gremium` semantics well, but omits the meaning of the required `kommune` parameter and the `anzahl` control. It also does not describe the shape of returned meeting data. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the full burden. It thoroughly explains `von`/`bis` (format YYYY-MM-DD, default range) and `gremium` (prefix matching with examples), but leaves the required parameter `kommune` and the `anzahl` parameter completely undocumented. Partial compensation justifies a 3, but the gap is significant for a 5-parameter 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?

The description states a specific verb (lists) and resource (Sitzungen von Rat, Ausschüssen und Bezirksvertretungen) with a time-period scope. It also names the sibling tool `sitzung` for agenda details, clearly distinguishing the two without requiring an agent to open either 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?

The description provides clear context: default date range (next 30 days) when none is given, and it explicitly directs the agent to `sitzung` for the agenda. It stops short of explicitly saying when not to use this tool (e.g., for document searches), but the resource distinction is clear enough for an agent to infer.

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 openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing the shape of the payload, including the conditional branch (bei Anfragen die Antwort der Verwaltung, bzw. umgekehrt). It does not mention behavior on invalid ids or unknown Kommunen, but for a read-only lookup 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?

Two compact blocks: the return-contents inventory first, then the parameter glossary. Every clause carries information and nothing is padded. Minor cost is the long comma-chained field list, which is dense but appropriate for enumerating a rich payload.

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 only two required params, no output schema, and safety covered by annotations, the description supplies the two things an agent actually needs: what comes back and where the identifiers come from. Missing only edge-case behavior (invalid id, ambiguous Kürzel), which is tolerable for a simple read lookup.

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 0%, so the description must carry both parameters, and it does: `kommune` is defined as a Kürzel and `id` as the number taken from the Vorlagen-URL or from `vorlagen_suchen`. That is a real semantic gain over bare string fields, especially the provenance of the id. It stops short of giving the id's concrete format or pointing to the source of valid Kürzel values.

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 specific resource (a Vorlage) and enumerates exactly what is returned: Titel, Art, Datum, Gremium, Zusammenfassung, Dokument, Beratungsfolge, plus the Antwort der Verwaltung for Anfragen. This is materially more specific than a tautology. It never explicitly contrasts itself with the sibling `vorlagen_suchen`, though the reference to obtaining the id from that tool implies the detail-vs-search split rather than stating it.

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 note that the id comes 'aus der Vorlagen-URL bzw. aus `vorlagen_suchen`' tells an agent this is the detail-fetch following a search, which is a useful path hint. There is no explicit when-to-use/when-not statement and no guidance on prerequisites such as where a valid `kommune` Kürzel comes from (e.g. the `kommunen` sibling).

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 establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful non-obvious behavior: the date is typically the first-session date rather than the submission date, empty kommune means all bodies, and anzahl is capped at 30. It does not say whether results are paginated or what fields come back, which leaves a small 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 one-sentence purpose followed by a compact parameter glossary and a notable caveat about the date field. Every line carries information; only minor loss from the run-on, bullet-less parameter 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 six-parameter, no-output-schema search tool the description covers purpose, every parameter, key data quirks and an escape hatch to `vorlage`. Missing is any statement of what a result record contains (title, date, link?) and the differentiation from `drucksachen_suchen`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden, and it does: suchbegriff (full text over title and document body), kommune (code from `kommunen`, empty = all), art (free-form, source-native names with examples), jahr, neueste_zuerst (date vs relevance ordering) and anzahl (1–30) are all given meaning. This compensates fully for the empty schema 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?

Names a specific verb (Volltextsuche) plus the exact resources searched (Vorlagen, Anträge, Anfragen, Mitteilungen) and even the fields (Titel und Dokumenttext) and geographic scope (Ruhrgebiet). It partially differentiates from the sibling `vorlage` by deferring details there, but never distinguishes itself from the very similar `drucksachen_suchen`, which is the main ambiguity risk.

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 detail lookups and Beratungsergebnisse to the `vorlage` sibling and tells the agent where kommune codes come from (`kommunen`). What is missing is guidance on when to use this versus `drucksachen_suchen`, so the riskiest choice among siblings is left implicit.

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