Skip to main content
Glama
Sign In
malkreide

lobbywatch-mcp

by malkreide
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

lobbywatch_get_parlamentarier

Read-onlyIdempotent

Look up a Swiss federal parliamentarian by name or Lobbywatch ID to retrieve their full profile and declared lobbying interests. Returns near-miss suggestions for fuzzy name misses.

Instructions

Look up a Swiss federal parliamentarian and return their full profile, including all declared/researched interessenbindungen.

On a fuzzy miss, the response surfaces near-miss candidates so the LLM can prompt the user with "did you mean…?" suggestions instead of treating the empty result as authoritative (audit ARCH-003).

Args: name_or_id: Either the numeric Lobbywatch ID (as string) or a name. Name matching is fuzzy — partial last names work.

Use cases: - "Show me Anna Mustermann's full lobbying profile" - "What conflicts of interest does parliamentarian #42 declare?" - "Look up Wehrli — give me everything you have"

Input Schema

NameRequiredDescriptionDefault
name_or_idYes

Output Schema

NameRequiredDescriptionDefault
staleNoSet only when the dump could not be refreshed and an older cached copy answered instead. The data may miss changes made since `stale.cached_at` — say so when relaying it.
sourceNoData: Lobbywatch.ch — CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/). Not an official register; community-researched records.
provenanceYesWhich endpoint / dump the payload came from
suggestionsNoNear-miss fuzzy candidates when the lookup failed (ARCH-003)
parlamentarierNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.8
    • addedOutput schema / $defs / StaleDump
      Added value: +{
+  "description": "The weekly dump could not be refreshed; an older cached copy answered.",
+  "properties": {
+    "age_seconds": {
+      "description": "Age of the answering copy",
+      "title": "Age Seconds",
+      "type": "integer"
+    },
+    "cached_at": {
+      "description": "When the answering copy was downloaded (UTC, ISO 8601)",
+      "title": "Cached At",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Why the refresh failed",
+      "title": "Reason",
+      "type": "string"
+    }
+  },
+  "required": [
+    "cached_at",
+    "age_seconds",
+    "reason"
+  ],
+  "title": "StaleDump",
+  "type": "object"
+}
    • addedOutput schema / properties / stale
      Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/StaleDump"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Set only when the dump could not be refreshed and an older cached copy answered instead. The data may miss changes made since `stale.cached_at` — say so when relaying it."
+}
  2. First observedv0.3.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower, and the description adds non-obvious behavior: fuzzy miss returns near-miss candidates rather than an authoritative empty result. Useful and specific, though nothing is said about profile size, rate limits, or error behavior.

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

Conciseness4/5

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

Purpose and fuzzy-miss caveat are front-loaded, followed by clearly labeled Args and Use cases blocks. Slightly verbose with the use-case list and audit reference, but every section is scannable and none of it is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A single-parameter lookup with an output schema present, so return-field detail is not required, and the description still explains the fuzzy-miss return behavior. Complete enough for correct invocation; only marginal gaps remain around input sanitization and failure modes.

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

Parameters4/5

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

With schema description coverage at 0%, the description carries the burden and does so: it explains name_or_id accepts either a numeric Lobbywatch ID as a string or a name, and that name matching is fuzzy with partial last names supported. That is substantive semantics beyond the bare string type in the schema, though it omits edge cases like max length behavior.

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

Purpose5/5

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

States a specific verb (look up) and resource (Swiss federal parliamentarian) plus what it returns (full profile including interessenbindungen). Clearly distinct from siblings like lobbywatch_search_parlamentarier_nach_branche and lobbywatch_list_interessenbindungen.

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

Usage Guidelines4/5

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

Provides three concrete use cases that make the intended invocation context clear, and explains the fuzzy-miss path. It does not, however, explicitly name alternatives or state when not to use it (e.g., vs. the search-by-branche sibling), so it stops short of full routing guidance.

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

Deploy Server

Other Tools