Bundestag, Lobbyregister und Abstimmungen mit Belegen recherchieren. Zugang: polradar@glits.de
Scored across 7 tools
find_actor vs get_actor follow a clear find/get split, and search targets documents rather than actors. However, get_document, get_vorgang, and get_relations overlap somewhat — get_document already returns linked actors/relations, and both get_document and get_vorgang surface voting results, which the descriptions explicitly try to disambiguate.
Most tools follow a consistent snake_case verb_noun pattern (find_actor, get_actor, get_document, get_relations, get_vorgang, verify_quote). The single bare 'search' verb is a minor deviation but still readable and conventional.
Seven tools is well within the ideal 3-15 range. Each tool maps to a distinct retrieval concern (actors, documents, relations, processes, search, verification), so none feel redundant or missing.
For a read-only political-data retrieval server the surface covers the core lifecycle: discovery (find_actor, search, get_vorgang), detail retrieval (get_actor, get_document), relations, and quote verification. Minor gaps remain, such as no direct enumeration of topics/sources or aggregate/statistics helpers, but agents can work around these.
Akteure mit öffentlicher Rolle finden (Abgeordnete, Fraktionen, Parteien, Ministerien, Interessenvertretungen). kind: person | fraktion | partei | ministerium | behoerde | interessenvertretung | gremium | sonstige_org.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| name | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it reveals almost nothing: it does not say whether matching is exact or fuzzy, whether results are paginated, or that it is a safe read-only lookup (though 'finden' implies read). An output schema exists, so return format is partly covered elsewhere, but matching semantics remain undisclosed.
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 sentences, purpose front-loaded before the kind enumeration. The pipe-delimited value list is slightly awkward formatting but wastes no 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?
Output schema existence removes the need to describe return values, and the operation is clearly a lookup. However, for a search-style tool with three parameters at 0% schema coverage and no annotations, the gaps around matching semantics and sibling routing leave the definition only minimally sufficient.
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 compensate. It usefully enumerates the valid `kind` values, which the schema lacks as an enum, but says nothing about `name` matching behavior or the `limit` parameter's meaning and default.
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 ('Akteure ... finden') and scopes it to actors with a public role, then enumerates the actor categories (Abgeordnete, Fraktionen, Parteien, Ministerien). An agent can distinguish this from get_actor by the 'find' vs 'get' verb, though the description never explicitly contrasts them.
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 guidance on when to use this versus the sibling tools get_actor (fetch by identifier) or search (general discovery). The list of actor kinds implies a lookup/discovery use case but the description never states the condition that selects this tool over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Akteur mit Rollen: Mitgliedschaften, verfasste Drucksachen/Anfragen, Reden, Abstimmungsverhalten (Abgeordnete), Nebentätigkeiten, Lobbyregister-Angaben (Interessenvertretungen: Regelungsvorhaben, Adressaten, Finanzangaben).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| actor_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It enumerates returned data categories, which is some signal, but never states that this is a read-only operation, whether the response is paginated (despite a limit parameter), or how large nested actor data can get. The mutation/read distinction is left to inference.
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 dense sentence with no waste, but it spends its whole budget enumerating return fields that an existing output schema already covers, while omitting purpose and usage. The German text under English tool names also sits awkwardly for a router-facing definition.
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 an output schema exists, the description need not explain return values — yet that is all it does. Purpose framing, the find_actor alternative, and parameter meaning are all absent, so an agent lacks what it needs to select and 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 0% and the description says nothing about either parameter — no actor_id source or format, no explanation that limit caps nested collections. The tool name weakly implies actor_id semantics, but nothing compensates for the fully undocumented 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 is a noun phrase enumerating what an actor record contains (memberships, speeches, votes, lobby register entries) rather than a verb+resource statement, but an agent can infer this fetches a single actor's full profile. It offers no differentiation from the sibling find_actor, which likely does lookup/search — the one distinction that matters here is unstated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of when to prefer this over find_actor or get_relations, and no prerequisites or identifier sourcing hints. The agent must guess that this is the direct-fetch-by-ID path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dokument mit Metadaten, Textausschnitt ab offset, verknüpften Akteuren, Themen und
Beziehungen. Weiterlesen mit offset = next_offset. Bei namentlichen Abstimmungen
(source_type poll) zusätzlich vote_result: Stimmen je Fraktion und Summen, vollständig
(ja, nein, enthalten, nicht_abgegeben).
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | ||
| offset | No | ||
| max_chars | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the pagination contract via next_offset, the conditional extra vote_result payload for polls (with its enum-like value set), and the returned content categories. It does not state permission requirements or read-only guarantees, but as a read-style retrieval tool there is little destructive behavior to warn about.
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 returns, followed by the paging rule and the poll special case. No filler, though the poll clause is fairly dense and the sentence boundaries could be cleaner.
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 three-parameter read tool with an output schema present, the description covers the essentials: content shape, paging, and the poll-specific return behaviour. The only real hole is max_chars, which the agent must guess from the schema default alone.
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% for all three parameters, so the description must compensate. It explains offset well (start of the excerpt, continue with next_offset) and doc_id is self-evident from the name, but max_chars is never mentioned in the description despite having a non-obvious default of 6000.
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 verb and resource and enumerates exactly what is returned: metadata, a text excerpt, linked actors, topics and relations. It implicitly separates itself from siblings like get_vorgang or get_relations by listing its own payload, but it never names an alternative, so it stops short of the top band.
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 concrete continuation guidance ('Weiterlesen mit offset = next_offset') and a conditional branch for source_type poll, which is genuine usage help. However there is no guidance on when to pick this tool over search, verify_quote or get_vorgang, which is the main selection decision an agent faces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Beziehungen eines Akteurs (kind='actor') oder Dokuments (kind='document') in beide Richtungen. predicate z. B. member_of, authored, asked, spoke_in, answered_by, part_of_vorgang, voted, lobbies_on, addresses, mentions. Für Abstimmungsergebnisse nicht die Einzelstimmen (voted) zählen, sondern get_document bzw. get_vorgang verwenden – nur dort sind alle Stimmen enthalten.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| kind | Yes | ||
| limit | No | ||
| predicate | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the 'both directions' semantics and the incompleteness of 'voted' edges for counting purposes, which is genuinely useful behavioral context. But it says nothing about pagination/interaction with limit, permissions, or the shape of the response, leaving gaps for a no-annotation tool.
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 returns, followed by predicate values and the voting caveat. No filler. Slightly dense but every sentence 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?
An output schema exists, so return values needn't be explained. But with 4 parameters at 0% schema description coverage and no annotations, the description should cover more; it leaves 'limit' (pagination behavior) and the id format undocumented, which an agent needs 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 0%, so the description must compensate. It successfully documents 'kind' (actor vs document), 'predicate' with a rich list of example values (member_of, authored, voted, etc.), and ties id to the entity. However it never explains 'limit' (default 50) or the integer id format, so compensation is partial.
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 resource and scope: relations of an actor (kind='actor') or document (kind='document'). It goes further by noting relations are returned 'in beide Richtungen' (both directions), which is a concrete behavioral detail. It's clearly the relation-lookup tool among siblings, though it doesn't sharply differentiate itself from get_actor/get_document beyond the voting caveat.
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 when-not-to-use rule: for vote results, do not count individual 'voted' edges, use get_document or get_vorgang instead, because only those contain all votes. That names alternatives and a selecting condition. It doesn't, however, state when to prefer get_relations over get_actor or get_document in general cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gesetzgebungs- oder sonstiger DIP-Vorgang (doc_id eines Dokuments vom Typ vorgang): Zeitachse der Positionen, beteiligte Akteure, namentliche Abstimmungen mit Ergebnis je Fraktion und Summen, Lobbyregister-Bezüge, Pressemeldungen, die Reden im Plenum (reden: Sprecher, Fraktion; Text per get_document) und – bei EU-Vorlagen – das EU-Gesetzgebungsverfahren (eu_verfahren: Status, Zeitleiste, Rechtsakt; EUR-Lex).
| Name | Required | Description | Default |
|---|---|---|---|
| vorgang_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose real behavioral traits beyond the schema: which sub-collections are returned and that speech text requires a separate get_document call. It omits any statement about read-only nature, error behavior, permissions, or pagination, which for a zero-annotation tool leaves meaningful gaps.
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 dense, run-on sentence with a heavily nested content list. It is front-loaded with the resource, which helps, but much of the enumeration duplicates what a return value/output schema would convey and crowds out actionable guidance such as parameter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values, yet it spends nearly all its length doing exactly that. Given the tool's complexity, the definition is workable but thin on the two things the schema cannot supply: how to form the ID and when this tool beats its siblings.
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% for the single parameter, so the description must compensate. It partially does by saying the input is the 'doc_id eines Dokuments vom Typ vorgang', but this wording conflicts with the declared parameter name and type (vorgang_id: integer), creating ambiguity about whether a numeric Vorgang ID or a document ID is expected.
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 (a DIP Vorgang / legislative procedure) and enumerates the concrete sub-entities it exposes, so an agent knows it is a rich detail-retrieval tool rather than a search. It also names a sibling (get_document) for speech text, giving partial differentiation. However, the purpose is buried under a long content inventory rather than stated as a crisp verb+resource.
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 agent learns it must call get_document to obtain the reden text, which is a genuine routing hint. There is no explicit when-to-use vs search/find_actor/get_relations, no statement of prerequisites for the ID, and no 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.
Dokumente suchen (Volltext + Vektor) oder nur nach Filtern auflisten (neueste zuerst). Antworten aus polradar belegen jede Aussage mit polradar_url als Markdown-Link (siehe belegregel im Ergebnis), nicht mit der Original-URL.
source: dip | lobbyregister | abgeordnetenwatch | rss | eu (EU-Gesetzgebungsverfahren zu
EU-Vorlagen des Bundestages, aus EUR-Lex).
source_type: z. B. vorgang, drucksache, plenarprotokoll, register_entry, poll, article,
rede (eine Rede aus einem Plenarprotokoll), schriftliche_frage (Frage mit Antwort),
haushalt (ein Kapitel bzw. Einzelplan aus einem Entwurf zum Bundeshaushaltsplan).
Namentliche Abstimmungen: source="abgeordnetenwatch", source_type="poll" – das Ergebnis
nach Fraktion liefert danach get_document. Eine query mit „Abstimmung“/„abgestimmt“
bringt passende Abstimmungen auch ohne diese Filter nach oben.
date_from/date_to: YYYY-MM-DD. topic: Themen-Slug (z. B. energie, rente, migration).
actor_id: nur Dokumente mit Bezug zu diesem Akteur (siehe find_actor).
Ohne query muss mindestens ein Filter gesetzt sein.
offset: zum Weiterblättern den Wert next_offset aus dem vorigen Ergebnis übergeben
(limit bis 30). Mit query werden nur die ~200 besten Kandidaten gerankt; für vollständige
Listen besser ohne query nur mit Filtern (Zeitraum, Quelle, Thema, Akteur) blättern –
dort nennt total die Gesamtzahl.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| topic | No | ||
| offset | No | ||
| source | No | ||
| date_to | No | ||
| actor_id | No | ||
| date_from | No | ||
| source_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden and delivers real behavioral detail: the ~200-candidate ranking cap with query, the total count only in filter mode, the limit ceiling of 30, and the citation rule that results must be linked via polradar_url rather than the original URL. It omits auth/permission requirements, which keeps it 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-loaded with the core action before citation rules and per-parameter notes; each sentence carries operational content. It is dense and slightly sprawling, but no sentence is 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?
An output schema exists so return values need no explanation, and the description still covers every parameter plus the cross-tool paths. The only gap is default values and any note on error behavior when no filter is supplied.
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% across 9 parameters, and the description compensates by defining source enum values, source_type examples, date format (YYYY-MM-DD), topic slug examples, actor_id cross-reference to find_actor, and offset/limit semantics. It does not explain the limit default of 10 or offset default of 0, so it is strong but not exhaustive.
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 first sentence names a specific verb and resource ('Dokumente suchen (Volltext + Vektor)') and explicitly covers the alternate mode ('oder nur nach Filtern auflisten'). It also distinguishes itself from siblings by routing actor filtering to find_actor and deferring vote results to get_document.
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?
Explicit conditions are given: 'Ohne query muss mindestens ein Filter gesetzt sein', query mode ranks only ~200 candidates while filter-only listing gives complete results with total, and offset paging uses next_offset. The namentliche Abstimmungen path is spelled out with exact source/source_type values and a query fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prüft, ob ein wörtliches Zitat (normalisiert: Groß-/Kleinschreibung, Leerraum, Anführungszeichen) in Titel oder Text des Dokuments steht.
| Name | Required | Description | Default |
|---|---|---|---|
| quote | Yes | ||
| doc_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does disclose a key behavioral trait: matching is literal and normalized for case, whitespace and quotation marks. It does not state return behavior, but an output schema exists, which lowers the disclosure burden. No indication of permissions or failure modes beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that leads with the core verb and resource. The parenthetical normalization detail is informative but slightly interrupts the flow; otherwise efficient with no wasted sentences.
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 two-parameter, read-only-style verification tool with an output schema, the description covers the essential operation and matching semantics. The main gap is the absence of usage context relative to siblings, but the functional core is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly tells the agent that 'quote' is the string being matched and that 'doc_id' identifies the document whose title/text is searched. That adds meaningful semantic context beyond the bare parameter names, though it does not specify formats or constraints.
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 (prüft) and a precise resource/condition (wörtliches Zitat in Titel oder Text). It is distinguishable from sibling tools, none of which deal with quote verification. The only slight weakness is that the normalization semantics are bundled in rather than the purpose being stated in a single crisp clause.
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 gives no when-to-use or when-not-to-use guidance and does not reference any alternative tool. An agent learns what the tool does but not when it is the right choice versus, say, searching the document directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_actorget_actorget_documentget_relationsget_vorgangsearchverify_quoteIndependent European news from Pollar: search, explainers, brief, threads, audio, films. Read-only.
Abgeordnetenwatch MCP — German federal & state parliament data.
Sveriges riksdag: vem sa vad, hur röstade ledamöter och partier — med källänkar.
Federal and state lobbying data: who lobbies for whom, spending, bills, agencies. From LDA filings.
Add one secure layer between your agents and this server.
