Sitzungen von Rat, Ausschüssen und Bezirksvertretungen in einem Zeitraum.
von/bis: Datum JJJJ-MM-TT; ohne Angabe die nächsten 30 Tage ab heute.
gremium: Wortanfang im Gremiennamen, z. B. "Rat", "Mobilität" oder "Bezirksvertretung Mitte"
("Rat" findet den Rat, nicht "Integration" oder "Beirat").
Die Tagesordnung liefert `sitzung`.| Name | Required | Description | Default |
|---|---|---|---|
| bis | No | ||
| von | No | ||
| anzahl | No | ||
| gremium | No | ||
| kommune | Yes |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.