A
licenseA
qualityA
maintenanceMCP server connecting AI models to Swiss Federal Food Safety and Veterinary Office open data, enabling queries about food recalls, animal disease surveillance, food control results, and more.
11
MIT
lobbywatch-mcp
by malkreide
The lobbywatch-mcp server connects AI models to Lobbywatch.ch, the largest database of Swiss federal parliamentarians' conflicts of interest, lobby connections, and transparency scores. Capabilities include:
Look up parliamentarian profiles: Retrieve a full profile by name (with fuzzy matching) or ID, including declared conflicts of interest (interessenbindungen), party, canton, commission memberships, and compensation transparency rating.
List conflicts of interest: Get a filtered list of a parliamentarian's mandates, optionally restricted to active or full-time (hauptberuflich) mandates. Returns near-miss suggestions if the name isn't found exactly.
Search by industry or commission: Find which parliamentarians hold mandates in a specific industry (e.g. "Pharma", "Bank", "Bildung"), optionally filtered by commission (e.g. "WBK-N").
Rank parliamentarians: Generate top-N rankings by total number of mandates or full-time mandates, filterable by party (e.g. "SP", "SVP") and/or commission.
Analyze transparency distribution: View the distribution of compensation transparency scores across all parliamentarians or a specific commission.
Fetch lobby group details: Look up a lobby group (interessengruppe) by name or ID, including its connected organisations and linked parliamentarians (e.g. "economiesuisse").
Manage data cache: Force a re-download of the weekly Lobbywatch JSON data dump, or check the current cache status (age, record count, last loaded timestamp).
Data is provided under a CC BY-SA 4.0 license. The server is designed to complement parlament-mcp for comprehensive insights into Swiss parliamentarians' official activities and lobby connections.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@lobbywatch-mcpWhich Swiss MPs have conflicts with pharma companies?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🏛️ lobbywatch-mcp
An MCP server that connects AI models to Lobbywatch.ch, the largest lobby database of the Swiss Federal Parliament — conflicts of interest, lobby groups, access badges, and transparency scores.
Part of the Swiss Public Data MCP Portfolio — connecting AI models to Swiss public data sources.
🎯 Anchor Demo Query
"Welche Mitglieder der WBK-N haben Interessenbindungen zu Bildungsverlagen oder privaten Bildungsträgern, und wie ist ihre Transparenz-Bewertung?"
Which members of the National Council's Education Commission have declared conflicts of interest with educational publishers or private education providers, and how does their compensation transparency score compare?
→ More use cases by audience →
Demo
Related MCP server: parlament-mcp
Overview
Lobbywatch.ch maintains the largest public database on Swiss federal parliamentarians and their connections to lobby organisations: 245 parliamentarians, ~7'800 interessenbindungen (declared mandates), 139 lobby groups, 368 access-badge holders, updated weekly, licensed CC BY-SA 4.0.
lobbywatch-mcp exposes this data to Large Language Models via the Model Context Protocol. It is designed to be used alongside parlament-mcp (the official Swiss Parliament's Curia Vista data): the pair makes it possible to ask what a parliamentarian did officially and who they are connected to — in a single conversation.
Features
Dump-first, API-fallback architecture. The weekly JSON dump is the primary source (stable, verified in production); the live
dataIFREST API is used only where it returns reliable data (lobby groups, search).Seven Phase 1 tools — parliamentarian lookup, conflict-of-interest listing, branche search, lobby group fetch, rankings, transparency quota, cache control.
CC BY-SA 4.0 attribution baked into every response via Pydantic envelopes.
Dual transport —
stdiofor Claude Desktop,streamable-http/ssefor cloud deployments.Fuzzy name matching via rapidfuzz for natural LLM input like "Jositsch" or "Wehrli".
No authentication required (Phase 1 — No-Auth-First).
Architecture
┌─────────────────────────────┐
LLM client │ LobbywatchClient │
(Claude Desktop, │ │
Inspector, …) │ ┌───────────────────┐ │
│ │ │ Dump cache │ │ cms.lobbywatch.ch
│ MCP │ │ (24 h TTL, │ │ ┌──────────────────┐
▼ stdio / │ │ ~80 MB resident)├─────┼─────►│ weekly JSON │
┌─────────┐ HTTP │ └───────────────────┘ │ │ export (~17 MB) │
│ FastMCP │◄────►│ │ └──────────────────┘
│ server │ │ ┌───────────────────┐ │ ┌──────────────────┐
└─────────┘ │ │ dataIF REST ├─────┼─────►│ /interface/v1/ │
│ │ (live fallback) │ │ │ json/… │
│ └───────────────────┘ │ └──────────────────┘
└─────────────────────────────┘Outbound HTTP runs through a single httpx.AsyncClient with follow_redirects=False, an SSRF guard that blocks RFC1918 / link-local / metadata IPs, and an httpx event hook that re-resolves on every request. The dump path is the primary source of truth for parliamentarian queries; dataIF is only used for lobby group lookups and the search endpoint.
Prerequisites
Python 3.11 or newer
Internet access to download the weekly Lobbywatch JSON export (~17 MB zipped)
Installation
From PyPI (after first release):
pip install lobbywatch-mcpFrom source:
git clone https://github.com/malkreide/lobbywatch-mcp.git
cd lobbywatch-mcp
pip install -e ".[dev]"Usage
Standalone
lobbywatch-mcpThis starts the server in stdio mode. For HTTP:
LOBBYWATCH_MCP_TRANSPORT=http LOBBYWATCH_MCP_PORT=8000 lobbywatch-mcpContainer
A hardened multi-stage Dockerfile ships with the repo (non-root,
read-only-rootfs compatible). See docs/deployment.md
and deploy/docker-compose.example.yml
for resource limits, sticky-LB guidance and egress hardening.
docker build -t lobbywatch-mcp:0.2.0 .
docker run --rm -p 127.0.0.1:8000:8000 lobbywatch-mcp:0.2.0Claude Desktop
Add to your claude_desktop_config.json:
{
"mcpServers": {
"lobbywatch": {
"command": "uvx",
"args": ["lobbywatch-mcp"]
}
}
}A full example is provided in claude_desktop_config.json.
Example Queries
Once connected, try prompts such as:
"Give me the top 10 parliamentarians by number of interessenbindungen in the SP party."
"Which WBK-N members have mandates in the publishing or education industry?"
"Look up the lobby group 'economiesuisse' and list its connected parliamentarians."
"What is the compensation-transparency score distribution for the finance commission (FK-N)?"
Tools
All tool names use the lobbywatch_ namespace prefix (since 0.2.0) to
avoid collisions with sibling portfolio servers.
Tool | Purpose | Source |
| Full profile + all conflicts of interest | Dump |
| Filtered mandate list | Dump |
| Cross-filter by industry and commission | Dump |
| Lobby group with connected MPs and organisations | Live dataIF |
| Top-N by criterion | Dump |
| Distribution of compensation transparency labels | Dump |
| Cache control | Dump |
Configuration
All behaviour is controlled via environment variables:
Variable | Default | Purpose |
|
| Transport ( |
|
| HTTP bind host (set to |
|
| HTTP bind port |
|
| Dump cache location |
|
| Cache time-to-live in seconds |
|
| HTTP timeout in seconds |
| (unset) | Comma-separated origin allow-list for HTTP/SSE; when set, exposes |
|
|
|
|
|
|
|
| Set to |
| (unset) | OTLP/HTTP collector endpoint (e.g. |
Project Structure
lobbywatch-mcp/
├── src/lobbywatch_mcp/
│ ├── __init__.py
│ ├── __main__.py # CLI + transport selection
│ ├── config.py # URLs, cache paths, attribution
│ ├── client.py # Dump download + dataIF client
│ ├── models.py # Pydantic v2 response envelopes
│ └── server.py # FastMCP tool registrations
├── tests/
│ ├── conftest.py # Fixture parliamentarians
│ ├── test_client.py # Respx-mocked unit tests
│ ├── test_server.py # Tool integration tests
│ └── test_live.py # @pytest.mark.live — excluded from CI
├── .github/workflows/
│ ├── ci.yml # Test matrix + ruff
│ └── publish.yml # PyPI OIDC Trusted Publisher
├── claude_desktop_config.json
├── pyproject.toml
└── ...Data License & Attribution
The code is released under the MIT License.
The data served through this MCP is © Lobbywatch.ch and licensed under CC BY-SA 4.0. Every response envelope includes the attribution string. Downstream users must:
Credit Lobbywatch.ch as the data source.
Share derivative datasets under the same CC BY-SA 4.0 terms.
Understand that Lobbywatch is a community-researched database — not an official register. It is authoritative for transparency research but should not be confused with the Federal Parliament's own declarations.
Known Limitations
The upstream
/table/parlamentarier/...dataIFREST endpoint currently returns empty result sets. The server works around this by using the weekly JSON dump instead.zutrittsberechtigungen(access badges) are not populated in the "essential" dump variant used here. A future release will add a dedicated tool using the non-essential dump.
Contributing
See CONTRIBUTING.md.
Security
See SECURITY.md for the security posture, accepted-risk decisions, and how to report a vulnerability.
MCP Protocol Version
This server speaks two protocol eras over the same endpoint. The client's first request on a connection decides which one applies; a later claim from the other era is refused.
Era | Revision | Who reaches it |
|
| What today's clients speak. The server answers with the revision asked for, or with the |
Per-request envelope |
| A request carrying the |
Both revisions are pinned in
tests/test_protocol_version.py and asserted
against the installed SDK, so a Dependabot bump of mcp cannot move either one
silently. This server builds no ASGI app to send an initialize through, so
the gate asserts the SDK constants rather than a measured response — the
weaker form, named rather than left unsaid.
Note that the SDK's LATEST_PROTOCOL_VERSION is an alias for the modern
era, not for the handshake era — pinning against it alone would leave the era
that current clients actually negotiate free to drift.
Update policy. When the gate fails, do not edit the constant blindly: read
the spec changelog between the two revisions, verify the server still behaves,
then move the constant, this section, README.de.md and
CHANGELOG.md together.
Changelog
See CHANGELOG.md.
License
MIT License — see LICENSE. Data CC BY-SA 4.0 — see NOTICE.md.
Author
malkreide · GitHub
Part of the Swiss Public Data MCP Portfolio.
Installation
Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):
{
"mcpServers": {
"lobbywatch-mcp": {
"command": "uvx",
"args": [
"lobbywatch-mcp"
]
}
}
}Available Tools
8 toolslobbywatch_dump_statusARead-onlyIdempotent
Return current dump cache status without forcing a refresh.
Use cases: - "How fresh is the cached data right now?" - "When was the dump last loaded?"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| loaded | Yes | |
| cached_at | No | |
| age_seconds | No | |
| record_count | No |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description adds no new behavioral details beyond reaffirming no side effects. No contradiction; bar is lower with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines plus bulleted use cases. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and an output schema present, the description is fully sufficient. It covers purpose, when to use, and no missing info.
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?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline of 4 is appropriate for this case.
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?
The description clearly states 'Return current dump cache status without forcing a refresh,' specifying the action and the resource. Use cases further clarify the tool's purpose, and it distinguishes itself from sibling tools like lobbywatch_refresh_dump.
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?
Explicit use cases are provided, indicating when to check freshness vs. refresh. While it doesn't explicitly state when NOT to use, the contrast with refresh_dump is clear enough for an AI agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_get_lobbygruppeARead-onlyIdempotent
Fetch a lobby group (interessengruppe) from the live Lobbywatch dataIF, including its connected organisations and parliamentarians.
Uses the live REST API since this endpoint returns fresh data.
Use cases: - "Look up 'economiesuisse' and list connected MPs" - "Who's affiliated with the lobby group #42?" - "Show me all parliamentarians linked to the pharma lobby"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| lobbygruppe | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds transparency by noting the live REST API and fresh data, plus the inclusion of connected entities. No contradictions, but more detail on rate limits or auth could further enhance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement followed by illustrative use cases. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers what the tool does, including its return content (connected organisations and parliamentarians). With an output schema available, further detail on return format is unnecessary.
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?
The input schema has no parameter descriptions (0% coverage), but the description compensates by showing examples of using a name or ID, clarifying the parameter's purpose and format.
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?
The description clearly states the tool fetches a lobby group including connected organisations and parliamentarians. It is specific and distinguishes from sibling tools that focus on individual parliamentarians, rankings, or transparency quotes.
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?
The description provides example use cases that illustrate common queries, giving clear context for when to use the tool. However, it lacks explicit guidance on when not to use it or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_get_parlamentarierARead-onlyIdempotent
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"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| parlamentarier | No | |
| suggestions | No | Near-miss fuzzy candidates when the lookup failed (ARCH-003) |
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by describing fuzzy miss handling and that the profile includes interessenbindungen. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, args, use cases, and note. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers all relevant aspects: behavior on hit/miss, parameter explanation, and use cases. Output schema exists but is not needed in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains that name_or_id can be a numeric ID or fuzzy name, and that partial last names work. Schema coverage is 0%, so the description fully compensates.
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?
The description states it 'Look up a Swiss federal parliamentarian and return their full profile', clearly identifying the resource and action. It also distinguishes from sibling tools like lobbywatch_search_parlamentarier_nach_branche.
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 explicit use cases ('Show me Anna Mustermann's full lobbying profile') and explains fuzzy miss behavior. Does not explicitly contrast with siblings but offers sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_get_rankingARead-onlyIdempotent
Rank parliamentarians by a criterion.
Args: kriterium: One of "anzahl_interessenbindungen", "anzahl_hauptberuflich". kommission: Optional commission abbreviation filter (e.g. "WBK-N"). partei: Optional party filter (e.g. "SP", "SVP", "Mitte"). limit: Top-N to return (1–100).
Use cases: - "Top 10 SP MPs by total mandate count" - "Which Mitte-Fraktion members have the most full-time mandates?" - "Rank WBK-N by IB count — who's most involved?"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kriterium | No | anzahl_interessenbindungen | |
| kommission | No | ||
| partei | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| kriterium | Yes | |
| eintraege | No |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; description aligns by describing a read-only ranking. No additional behavioral traits (e.g., rate limits, data freshness) are disclosed beyond what annotations provide, but no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: single sentence intro, clear Args section, and two-line Use cases. Every sentence adds value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, no need to describe return values. All parameters are covered, use cases illustrate typical applications, and the tool's purpose is fully contextualized for an AI agent.
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?
Schema description coverage is 0%, so description compensates by explaining each parameter: enum values for kriterium (with examples), optional filters for kommission and partei (with sample values), and range for limit. Provides meaning beyond raw schema.
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?
The description clearly states 'Rank parliamentarians by a criterion', specifying the verb and resource. It distinguishes from sibling tools like lobbywatch_get_parlamentarier or lobbywatch_list_interessenbindungen which do not perform ranking.
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 concrete use cases (e.g., 'Top 10 SP MPs by total mandate count') and explains parameters like kriterium, kommission, partei, limit. Lacks explicit when-not-to-use or alternatives, but examples strongly imply appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_get_transparenzquoteARead-onlyIdempotent
Aggregate the verguetungstransparenz_beurteilung values across all parliamentarians (or a commission subset) and return the distribution.
Useful to answer: 'How transparent is the education commission on compensation disclosure?'
Use cases: - "How transparent is the FK-N on compensation disclosure?" - "Distribution of transparency labels across the whole parliament" - "Compare WBK-N transparency vs the council average"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kommission | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| scope | Yes | |
| total | Yes | |
| nach_bewertung | No | |
| quote_ausreichend | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by stating it aggregates and returns a distribution. No contradiction. The description provides sufficient behavioral context for a read-only, idempotent tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a summary sentence and three bullet-point use cases. Every sentence adds value and the structure is front-loaded with the core action.
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?
Given the tool has one optional parameter and an output schema, the description covers the main purpose and usage scenarios adequately. It does not discuss limits or edge cases but is complete for a simple aggregation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description mentions commission filtering and uses cases reference specific commissions. However, it does not explicitly describe the parameter name or format, leaving some ambiguity despite the context.
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?
The description clearly states the tool aggregates 'verguetungstransparenz_beurteilung' values across parliamentarians or a commission subset and returns the distribution. It provides specific verb 'Aggregate' and resource, and the use cases differentiate it from siblings like 'lobbywatch_get_ranking'.
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?
The description gives explicit use cases (e.g., 'How transparent is the FK-N on compensation disclosure?') and implies when to use, but does not explicitly state when not to use or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_list_interessenbindungenARead-onlyIdempotent
Return the list of interessenbindungen (conflicts of interest) for one parliamentarian, optionally restricted to full-time or currently-active mandates.
On a fuzzy miss, near-miss candidates are returned in
suggestions (audit ARCH-003).
Args: name_or_id: ID or name (fuzzy). nur_hauptberuflich: If True, only main-occupation mandates. nur_aktiv: If True, drop mandates with an end date (bis) set.
Use cases: - "Which active mandates does Jositsch hold today?" - "List Anna Mustermann's full-time mandates only" - "Give me every IB ever declared by parliamentarian #1"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name_or_id | Yes | ||
| nur_hauptberuflich | No | ||
| nur_aktiv | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| parlamentarier_id | Yes | |
| count | Yes | |
| interessenbindungen | No | |
| suggestions | No | Near-miss fuzzy candidates when the lookup failed (ARCH-003) |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds key behaviors: fuzzy matching with suggestions on near-miss, and optional restrictions (nur_hauptberuflich, nur_aktiv). It does not contradict annotations.
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?
The description is well-structured with sections for purpose, behavior, Args, and use cases. It is slightly verbose but each sentence adds value, and it is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the parameters are simple, the description covers all necessary aspects: input parameters, fuzzy matching, optional filters, and common use cases. It does not require further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter clearly in the Args section (e.g., 'nur_hauptberuflich: If True, only main-occupation mandates'), compensating for the 0% schema description coverage. Use cases further illustrate parameter usage.
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?
The description clearly states 'Return the list of interessenbindungen (conflicts of interest) for one parliamentarian', using a specific verb and resource. It distinguishes from sibling tools like 'lobbywatch_get_parlamentarier' by focusing on conflicts of interest.
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?
The description provides three concrete use cases (e.g., 'Which active mandates does Jositsch hold today?') that illustrate when to use the tool. However, it does not explicitly mention when not to use it or name alternatives, though the sibling tools cover different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_refresh_dumpAIdempotent
Force re-download of the weekly Lobbywatch dump. Returns the new cache status.
Reports progress via the MCP Context (audit SDK-003) so long-running downloads (~17 MB compressed) surface useful feedback to the calling LLM and operator.
Use cases: - "Force a fresh download — the data looks stale" - "I just heard about a new declaration — refresh and re-check"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| loaded | Yes | |
| cached_at | No | |
| age_seconds | No | |
| record_count | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it reports progress via MCP Context (audit SDK-003) during long-running downloads (~17 MB compressed). This provides valuable information about execution time and user feedback. Annotations already indicate non-read-only, non-destructive, idempotent, and open-world hint, and the description complements these without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the first sentence stating the primary action and return value. The following sentences add important context about progress reporting and use cases. Every sentence is meaningful, and the structure is front-loaded with the core purpose.
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?
The description covers the purpose, behavior, and usage context adequately. It mentions the return value ('new cache status') and progress reporting. Given that no parameters are needed and an output schema exists, the description is complete enough for an agent to invoke and interpret the result. Minor improvement could be a brief note on what 'cache status' entails, but the output schema likely handles that.
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?
The tool has zero parameters, and the input schema is empty with 100% coverage. According to guidelines, 0 parameters yields a baseline of 4. The description does not need to add parameter information, so this score is appropriate.
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?
The description clearly states the tool forces a re-download of the weekly Lobbywatch dump and returns the new cache status. It uses specific verbs (force re-download, returns) and resource (Lobbywatch dump). It distinguishes from siblings by implying this is for forcing a refresh, while siblings like lobbywatch_dump_status are likely for status checks without triggering a download.
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?
The description provides explicit use cases ('Force a fresh download — the data looks stale' and 'I just heard about a new declaration — refresh and re-check'), which guide the agent on when to use the tool. It does not explicitly state when not to use it or mention alternatives, but the presence of sibling tools and the context of 'force re-download' vs. status check is implied. Slightly lacking in explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lobbywatch_search_parlamentarier_nach_brancheARead-onlyIdempotent
Find parliamentarians with interessenbindungen matching a search term against the linked organisation's name, alias, and (when available) branche field. Optional commission filter.
Note: the Lobbywatch "essential" dump does not embed a branche taxonomy on each organisation — branche is referenced by id and resolved via the separate interessengruppe table. Version 0.1 therefore performs a substring match against organisation names and the branche field when present. Version 0.2 will add full cross-reference resolution.
Args:
branche_query: Substring match (case-insensitive) against
organisation.anzeige_name, organisation.name,
organisation.branche (where present), e.g. "Verlag",
"Pharma", "Bank", "Krankenkasse", "Bildung".
kommission: Commission abbreviation to restrict the result to,
e.g. "WBK-N" for the education commission of the National Council.
limit: Max number of {parlamentarier, ib} pairs returned (1–200).
Use cases: - "Which WBK-N members hold mandates in the publishing industry?" - "Cross-filter Pharma × FK-N to surface health-policy lobbyists" - "List every parliamentarian with a 'Krankenkasse' connection"
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| branche_query | Yes | ||
| kommission | No | ||
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | No | |
| provenance | Yes | Which endpoint / dump the payload came from |
| query | Yes | |
| count | Yes | |
| treffer | No | List of {parlamentarier, interessenbindung} pairs matching the branche |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds specific behavioral details such as substring matching, case-insensitivity, and version 0.1 limitations, which go 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, limitations, Args, and Use cases. While informative, it could be slightly more concise; the version note and future improvements add length but are still relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description adequately covers input semantics, use cases, and behavioral nuances. No critical gaps remain for agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully explains all three parameters: branche_query (matching fields), kommission (commission abbreviation), and limit (range 1-200). It compensates completely for the missing schema descriptions.
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?
The description clearly states it finds parliamentarians based on a search term against organisation fields, with optional commission filter. It distinguishes from siblings like 'lobbywatch_get_parlamentarier' by focusing on industry/commission search.
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 clear use cases (e.g., 'Which WBK-N members hold mandates in publishing?') and explains limitations like substring matching. However, it does not explicitly mention when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
8 tool updates
v0.3.1- First observed
lobbywatch_dump_status - First observed
lobbywatch_get_lobbygruppe - First observed
lobbywatch_get_parlamentarier - First observed
lobbywatch_get_ranking - First observed
lobbywatch_get_transparenzquote - First observed
lobbywatch_list_interessenbindungen - First observed
lobbywatch_refresh_dump - First observed
lobbywatch_search_parlamentarier_nach_branche
TDQS
A4.3/5.0
Scored across 8 tools
Disambiguation4/5
Most tools have distinct purposes (dump management, parliamentarian lookups, ranking, transparency, search). However, `lobbywatch_get_parlamentarier` and `lobbywatch_list_interessenbindungen` partially overlap since the former returns full profiles including interests, but the latter offers filtering options that reduce ambiguity.
Naming Consistency5/5
All tools follow a consistent `<verb>_<noun>` pattern with snake_case and the `lobbywatch_` prefix. Verbs like `get`, `list`, `refresh`, and `search` clearly indicate the action, and the naming is uniform throughout.
Tool Count5/5
With 8 tools, the set is well-scoped for the lobbywatch domain. Each tool covers an essential aspect (dump status/refresh, parliamentarian/lobby group lookups, ranking, transparency, interest listing, branch search) without bloat or insufficiency.
Completeness3/5
The tools cover core operations but miss basic listing functionality (e.g., no `list_parlamentarier` or `list_lobbygruppen`). Users cannot get an unfiltered list of all parliamentarians or lobby groups, which limits general discovery. Other CRUD operations are absent but presumably out of scope.
Maintenance
ActivityActive
ResponsivenessNo issues
Related MCP Connectors
An MCP server that provides congressional transcripts
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseAqualityAmaintenanceAn MCP server connecting AI models to the Swiss Federal Parliament via the Curia Vista OData API, enabling queries of motions, votes, members, sessions, and debate transcripts without authentication.7MIT
- AlicenseBqualityDmaintenanceMCP server giving AI agents access to US political finance data: campaign contributions, PAC spending, lobbying records, and voting behavior.61MIT
- AlicenseAqualityAmaintenanceAn MCP server for Swiss Federal Railways (SBB) open data, enabling AI models to query real-time disruptions, passenger frequencies, station details, and more without an API key.102MIT