This MCP server enables AI models to answer questions about mandatory health insurance (OKP/KVG) coverage in Switzerland using live public data from the Federal Office of Public Health (BAG).
Search the Spezialitaetenliste (epl_sl_suche): Look up whether a specific medication (by name or active ingredient, e.g. "Ritalin", "Aspirin") is covered by mandatory health insurance (KVG Art. 52).
Check GGSL coverage for congenital disorders (epl_ggsl_abfrage): Determine which medications disability insurance (IV) covers for a specific congenital disorder (e.g. diabetes, cystic fibrosis), with legal basis (IVG/GgV).
Search the MiGeL for medical devices & aids (epl_migel_suche): Find out whether a medical device or aid (e.g. wheelchair, hearing aid) is covered under KLV Art. 20.
List pending SL admission requests (epl_gesuchseingaenge): See which medications are currently under review for inclusion in the Spezialitaetenliste.
Get legal/regulatory context (epl_rechtskontext): Retrieve structured legal information including WZW criteria, relevant laws (KVG, KLV), and Fedlex links.
Check server status and roadmap (epl_server_info): Discover available tools, API phase, MCP protocol version, and planned upgrades.
Key notes:
All tools are read-only (HTTP GET only) — no data is written or modified
No API key required — data is publicly accessible Swiss Open Government Data (CC BY 4.0)
Returns both human-readable Markdown/JSON and typed structuredContent for programmatic use
Not a substitute for official BAG sources or qualified professional advice
Click on "Install 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., "@bag-epl-mcp Is Methylphenidate (Ritalin) covered by mandatory health insurance?"
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.
\U0001f1e8\U0001f1ed Part of the Swiss Public Data MCP Portfolio
MCP Server for the Swiss BAG electronic benefits platform (ePL) — Spezialitaetenliste, GGSL, MiGeL
\U0001f1e9\U0001f1ea Deutsche Version
bag-epl-mcp enables AI models to answer questions about mandatory health insurance coverage in Switzerland — in natural language, grounded in real data.
List | Purpose | Legal basis |
Spezialitaetenliste (SL) | Compulsory-insurance medications | KVG Art. 52 |
GGSL | Medications for congenital disorders (IV) | IVG Anhang |
MiGeL | Medical devices & aids | KLV Art. 20 |
Anchor query: "Is this medication covered by mandatory health insurance?"
→ epl_sl_suche: Live lookup in the Spezialitaetenliste (SL)
→ More use cases by audience →
Related MCP server: Swiss Health MCP Server
\U0001f48a 6 tools, 2 resources, 2 prompts for Swiss health insurance data
\U0001f50d epl_sl_suche — search the Spezialitaetenliste for medications
⚖️ epl_rechtskontext — legal context with Fedlex links
\U0001f513 No API key required — all data publicly accessible
☁️ Dual transport — stdio (Claude Desktop) + Streamable HTTP (cloud)
\U0001f4da Prompt templates for insurance coverage checks and school health queries
Python 3.11+
uv (recommended) or pip
# Clone the repository
git clone https://github.com/malkreide/bag-epl-mcp.git
cd bag-epl-mcp
# Install
pip install -e .
# or with uv:
uv pip install -e .Or with uvx (no permanent installation):
uvx bag-epl-mcp# stdio (for Claude Desktop) — default, opens no network ports
python -m bag_epl_mcp.server
# Streamable HTTP (cloud) — transport selected via env var
MCP_TRANSPORT=streamable-http MCP_HOST=0.0.0.0 MCP_PORT=8000 \
pip install -e ".[http]" && python -m bag_epl_mcp.serverTransport & host are configured exclusively via environment variables (
MCP_TRANSPORT,MCP_HOST,MCP_PORT). The default isstdiobound to nothing;MCP_HOSTdefaults to127.0.0.1and should only be set to0.0.0.0inside a container/cloud environment.
Try it immediately in Claude Desktop:
"Is Methylphenidate (Ritalin) covered by mandatory health insurance?" "Which laws regulate admission to the Spezialitaetenliste?" "Is a wheelchair covered by mandatory insurance?"
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"bag-epl": {
"command": "python",
"args": ["-m", "bag_epl_mcp.server"]
}
}
}Or with uvx:
{
"mcpServers": {
"bag-epl": {
"command": "uvx",
"args": ["bag-epl-mcp"]
}
}
}Render.com (recommended):
Push/fork the repository to GitHub
On render.com: New Web Service → connect GitHub repo
Build command: pip install -e ".[http]"
Set the following environment variables:
MCP_TRANSPORT=streamable-http
MCP_HOST=0.0.0.0 (required so the container accepts external traffic)
MCP_PORT=8000 (or Render's $PORT)
(optional) MCP_CORS_ORIGINS='["https://claude.ai"]' to extend the
browser CORS allow-list
(optional) OpenTelemetry tracing is on by default but a no-op unless
the tracing deps are installed — build with pip install -e ".[http,otel]"
and point OTEL_EXPORTER_OTLP_ENDPOINT at your collector. Set
MCP_OTEL_ENABLED=0 to disable.
Start command: python -m bag_epl_mcp.server
In claude.ai under Settings → MCP Servers, add: https://your-app.onrender.com/mcp
Security note: the server exposes only public, read-only data and uses no authentication. See
docs/SECURITY.mdfor the threat model (egress allow-list, host binding, Lethal-Trifecta assessment).
Tool | Description |
| Search the Spezialitaetenliste for compulsory-insurance medications |
| Check GGSL coverage for congenital disorders |
| Search the MiGeL for medical devices & aids |
| List pending SL admission requests (transparency) |
| Legal context for coverage questions (WZW criteria) |
| Server status and API phase information |
Query | Tool |
"Is Ritalin covered by insurance?" |
|
"Which medications for congenital disorder GG-313?" |
|
"Is a wheelchair covered?" |
|
"Which laws regulate the SL?" |
|
Data flow (Phase 1):
bag-epl-mcp (FastMCP)
┌────────────┐ MCP ┌───────────────────────────────┐ HTTPS GET ┌──────────────────┐
│ MCP Client │◀───────▶│ tools (read-only) │─────────────▶│ sl.bag.admin.ch │
│ (Claude │ stdio / │ ├─ epl_sl_suche │ egress │ www.bag.admin.ch │
│ Desktop, │ Stream- │ ├─ epl_ggsl_abfrage │ allow-list │ www.fedlex... │
│ claude.ai)│ able │ ├─ epl_migel_suche │◀─────────────│ (public OGD) │
│ │ HTTP │ ├─ epl_gesuchseingaenge │ (no auth) └──────────────────┘
│ │ │ ├─ epl_rechtskontext │
│ │ │ └─ epl_server_info │ structured JSON logs → stderr
└────────────┘ │ resources: epl://uebersicht …│
│ prompts: epl_kassenpflicht…│
└───────────────────────────────┘Phase roadmap (details in docs/ROADMAP.md):
Phase 1 (current) → legal context + entry points, no data retrieval
Phase 2 (planned) → FHIR/IDMP API, once publicly accessible
Phase 3 (vision) → MiGeL + AL via ePL-FHIRWhat Phase 1 does, and what it does not. Five of the six tools make no network request at all — there is exactly one outgoing HTTP call in the whole module. They return the legal basis and an entry point, and they now say so. The previous wording, "XML/XLSX downloads + SL website access", advertised a capability with no code path behind it; on 2026-08-08 it was removed rather than implemented, because the underlying source is not machine-readable.
That one HTTP call goes to sl.bag.admin.ch/api/search and receives HTTP 200
with text/html — the 51 KB Angular shell. A freely invented path under the
same prefix returns the identical response, byte for byte: there is no API at
that address. Previously the resulting JSON parse error was caught by a bare
except Exception and turned into the claim "the SL database API is not
publicly documented" — a statement about the BAG's publishing practice,
derived from a parser error. The tool now reports what was measured.
The SL front end calls https://epl.bag.admin.ch/api/sl/ instead, on a
different host. That host answers 401 without authentication — but it answers
401 for invented paths too, so this does not establish that any particular
route exists. It is deliberately not on the egress allow-list: without
verifiable access, adding it would be a grant on suspicion.
MCP protocol version: 2025-11-25 (surfaced via epl_server_info) — the
initialize handshake ceiling, derived from the SDK rather than written down
here a second time. See MCP Protocol Version for both
eras. SDK
updates are proposed monthly via Dependabot; the protocol version is reviewed on
every mcp SDK bump — see the versioning policy in docs/ROADMAP.md.
Read-only: All tools perform HTTP GET requests only — no data is written, modified, or deleted.
No personal data: The server accesses public regulatory lists (SL, GGSL, MiGeL). No personally identifiable information (PII) is processed or stored.
No medical advice: This server provides informational access to regulatory data only. For medical or legal decisions, always consult the official BAG sources and qualified professionals.
Rate limits: The SL website (sl.bag.admin.ch) is a public Angular SPA; the server enforces a 30s timeout per request. Use limit parameters conservatively.
Data freshness: Phase 1 tools link to live BAG sources. No caching is performed by this server.
Links are measured, not assumed: the addresses handed out as "official source" are re-checked by scripts/record_fixtures.py on every run, together with a control request to an invented path. Two BAG pages previously handed out (.../Arzneimittel/geburtsgebrechen-spezialitaetenliste.html and .../Arzneimittel/gesuchseingaenge.html) answered HTTP 404 on 2026-08-08 and were replaced by the entry point that verifiably resolves — not by a guessed replacement URL.
Legal references are checked against the register: every SR number the server prints is resolved to its ELI via the Fedlex SPARQL endpoint. This detour is necessary: Fedlex's web front end is a single-page app that answers HTTP 200 with the same byte count for any ELI, including an invented one. That is how a wrong GgV link (eli/cc/1986/40_40_40, no register entry) went unnoticed; the correct ELI is eli/cc/1986/46_46_46.
Data licence (OGD-CH): The underlying BAG/Fedlex data is Swiss Open Government Data, licensed CC BY 4.0. Tool outputs carry a source / provenance block (JSON) or a source-and-licence footer (Markdown) so attribution is preserved.
Structured output: every tool returns both a human-readable Markdown/JSON block (content) and a typed structuredContent validated against a per-tool output schema, so MCP clients can consume results programmatically without parsing prose.
Terms of service: Data is subject to the ToS of sl.bag.admin.ch, bag.admin.ch, and fedlex.admin.ch.
No guarantees: This is a community project, not affiliated with the BAG or any government entity. Availability depends on upstream sources.
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.
# Unit + contract tests (no network) — this is what CI runs
PYTHONPATH=src pytest tests/ -m "not live"
# Live tests against the real BAG/Fedlex sources
PYTHONPATH=src pytest tests/ -m "live"
# Re-record the measurements (writes tests/fixtures/ + PROVENANCE.md)
PYTHONPATH=src python scripts/record_fixtures.py100 tests — 88 offline, 12 against the live sources.
Until 2026-08-08 six of the eight live tests could not pass. They compared a string against a tool's return value:
assert "BAG ePL MCP Server" in result # result is a CallToolResultCallToolResult is a Pydantic model; in iterates over (field, value)
pairs, so the comparison is always false. Nobody noticed, because CI excludes
-m live — a test that only runs outside CI and is always red there reports to
no one.
And even fixed, four of them would have proved nothing: assert "313" in result against a tool that writes its own input into a template, assert "Rollstuhl" in result likewise. They asserted that a tool echoes its input —
which is precisely what those tools do.
What must hold permanently therefore lives in tests/test_quellen_vertrag.py,
which runs inside CI against the recorded measurements under
tests/fixtures/. PROVENANCE.md records source, date, selection rule and
SHA-256 for each one.
Four of the recorded measurements are controls — an invented path under
sl.bag.admin.ch/api/, an invented path in the BAG portal, an invented ELI,
and an invented SR number. Without them each measurement would only show what
we received, not what the source actually holds. The recorder aborts if a
control stops discriminating, if a live entry point dies, if one of the dead
pages returns, or if a legal reference drifts from the register.
See CHANGELOG.md
See CONTRIBUTING.md
See SECURITY.md (Deutsch) for the security posture and how to report a vulnerability.
MIT License — see LICENSE
Hayal Oezkan · malkreide
BAG Spezialitaetenliste: sl.bag.admin.ch — Federal Office of Public Health
KVG: SR 832.10 — Health Insurance Act
KLV: SR 832.112.31 — Healthcare Benefits Ordinance
Protocol: Model Context Protocol — Anthropic / Linux Foundation
Related: fedlex-mcp — Swiss federal law
Related: swiss-cultural-heritage-mcp — Cultural heritage data
Portfolio: Swiss Public Data MCP Portfolio
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": {
"bag-epl-mcp": {
"command": "uvx",
"args": [
"bag-epl-mcp"
]
}
}
}Aktuelle Gesuchseingaenge fuer die Spezialitaetenliste abrufen.
Transparenzliste: Zeigt, welche Medikamente aktuell zur Aufnahme in die SL beantragt sind.
Beantwortet «Welche Medikamente sind aktuell zur Aufnahme in die SL beantragt?» (Transparenz/Monitoring). Verweist auf die offizielle BAG-Transparenzliste.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| link | Yes | |
| source | Yes | |
| hinweis | Yes | |
| provenance | Yes | |
| beschreibung | Yes | |
| direkt_link_bag | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which the description complements with 'abrufen' (retrieve) and 'Transparenzliste'. No destructive behavior is implied, and the description adds context about the official BAG list. With annotations covering safety, the description adds moderate value.
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 extremely concise: two short sentences plus a structured use_case block. The main purpose is front-loaded, and every sentence adds value without redundancy.
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 zero parameters and presence of an output schema, the description fully covers the tool's purpose and use case. It explains what information is returned (medications applied for SL) and references the official source. No gaps remain.
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 has no parameters, and schema coverage is 100%. Per guidelines, baseline is 4. The description does not need to explain parameters but adds value by describing what data is retrieved (current applications for SL).
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 the tool retrieves current applications for the specialty list (SL) and specifies the action 'abrufen' and resource 'Gesuchseingaenge'. The use case further clarifies it answers which medications are being considered for SL inclusion, making it highly specific and distinct from siblings.
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 use case block explicitly states the question the tool answers ('Welche Medikamente sind aktuell zur Aufnahme in die SL beantragt?') and characterizes it as transparency/monitoring. However, it does not provide explicit when-not-to-use guidance or compare with sibling tools like epl_sl_suche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GGSL-Deckung bei Geburtsgebrechen pruefen.
Die Geburtsgebrechen-Spezialitaetenliste (GGSL) enthaelt Arzneimittel, die bei anerkannten Geburtsgebrechen von der Invalidenversicherung (IV) uebernommen werden.
Beantwortet «Welche Medikamente uebernimmt die IV bei Geburtsgebrechen Nr. X?». Liefert Rechtsgrundlage (IVG/GgV) und die offizielle BAG-Quelle. Im Gegensatz zu epl_sl_suche geht es hier um IV- statt OKP-Leistungen.
| Name | Required | Description | Default |
|---|---|---|---|
| eingabe | Yes |
| Name | Required | Description |
|---|---|---|
| link | Yes | |
| source | Yes | |
| status | Yes | |
| hinweis | Yes | |
| erklaerung | Yes | |
| provenance | Yes | |
| rechtsgrundlage | Yes | |
| geburtsgebrechen_nr | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description does not contradict this. Moreover, it adds valuable behavioral context by stating that the tool provides legal basis and official BAG source information, which is beyond what annotations provide.
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 concise, with no extraneous words. It front-loads the main action and includes a clear use case section that adds value without redundancy.
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 tool has a simple input (one required parameter plus optional format) and an output schema (not shown but indicated), the description covers the purpose, usage, and behavioral context thoroughly. It provides sufficient information for an agent to select and invoke the tool 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?
The input schema already provides descriptions for both parameters (geburtsgebrechen_nr and format), so schema coverage is high. The description adds an example use case (e.g., '313' for Diabetes) which helps parameter understanding, justifying a score above baseline.
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 the tool checks GGSL coverage for birth defects, specifying the exact use case: to answer which medications the IV covers for a given birth defect number. It also distinguishes itself from the sibling tool epl_sl_suche by noting the difference between IV and OKP benefits.
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 explicitly provides when to use the tool: to determine IV coverage for birth defects. It includes a contrasting sibling tool (epl_sl_suche) for OKP coverage, giving clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suche in der Mittel- und Gegenstaendeliste (MiGeL) nach Medizinprodukten.
Die MiGeL enthaelt alle von der OKP vergueteten Mittel und Gegenstaende (KLV Art. 20), z.B. Rollstuehle, Hoergeraete, Inkontinenzprodukte.
Beantwortet «Uebernimmt die OKP das Hilfsmittel X (z.B. Rollstuhl, Hoergeraet)?». Liefert Rechtsgrundlage (KLV Art. 20) und die offizielle MiGeL-Quelle. Fuer Medikamente stattdessen epl_sl_suche.
| Name | Required | Description | Default |
|---|---|---|---|
| eingabe | Yes |
| Name | Required | Description |
|---|---|---|
| link | Yes | |
| count | No | |
| source | Yes | |
| status | Yes | |
| results | No | |
| erklaerung | Yes | |
| match_type | No | |
| provenance | Yes | |
| suchbegriff | Yes | |
| rechtsgrundlage | Yes | |
| migel_integration | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so description's search nature aligns. Description adds that it returns legal basis and official MiGeL source, providing context beyond the annotation. No contradiction.
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?
Concise: two sentences plus a use_case block. No unnecessary words. Front-loaded with purpose.
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 single required parameter, output schema present, and read-only annotation, the description is complete. It explains purpose, use case, and alternative tool.
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 already describes parameters (suchbegriff, limit, format) with descriptions. Description adds example search terms (e.g., 'Rollstuhl', 'Hoergeraet'), which is helpful but not essential. Baseline 3 due to schema coverage.
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?
Description states 'Suche in der Mittel- und Gegenstaendeliste (MiGeL) nach Medizinprodukten'—specific verb and resource. It differentiates from sibling 'epl_sl_suche' by noting the MiGeL is for medical devices vs medications.
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?
Use case explicitly states: addresses whether OKP covers a medical device, provides legal basis, and directs to 'epl_sl_suche' for medications. Clear when to use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rechtlichen Kontext zur Kassenpflicht liefern.
Gibt strukturierte Informationen zu den Rechtsgrundlagen der obligatorischen Krankenpflegeversicherung (WZW-Kriterien, KVG, KLV).
Beantwortet «Auf welcher rechtlichen Grundlage beruht die Kassenpflicht?» und erklaert die WZW-Kriterien (Wirksamkeit, Zweckmaessigkeit, Wirtschaftlichkeit) mit Fedlex-Verweisen. Ergaenzt die Such-Tools um den juristischen Kontext.
| Name | Required | Description | Default |
|---|---|---|---|
| eingabe | Yes |
| Name | Required | Description |
|---|---|---|
| frage | Yes | |
| source | Yes | |
| gesetze | Yes | |
| hinweis | Yes | |
| provenance | Yes | |
| wzw_kriterien | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, consistent with the description that the tool provides information only. The description adds behavioral context (Fedlex references, structured information) beyond the annotations, with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear structure including a <use_case> tag. Every sentence adds value, no fluff.
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 tool's limited complexity (one required parameter) and the presence of an output schema (not shown), the description adequately covers the tool's function and intended use cases.
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?
Although context signals indicate 0% schema description coverage, the actual input schema includes descriptions for both parameters ('frage' and 'format'). The tool description does not add additional parameter meaning beyond what is already in the schema, so baseline 3 is appropriate.
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 the tool's purpose: providing legal context for the mandatory health insurance obligation ('Kassenpflicht'). It specifies the verb 'liefern' and the resource, and distinguishes itself from sibling tools by mentioning it supplements search tools with legal context.
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 includes a <use_case> block that tells when to use the tool (for legal basis questions about 'Kassenpflicht' and WZW criteria) and that it complements search tools. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Serverstatus und API-Phaseninformation anzeigen.
Liefert Informationen zum aktuellen Funktionsumfang und den geplanten Erweiterungen des BAG-ePL-MCP-Servers.
Beantwortet «Was kann dieser Server, welche MCP-Version und welche Phase?». Nuetzlich zum Discovery der verfuegbaren Tools und des Roadmap-Stands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| phase | Yes | |
| tools | Yes | |
| phasen | Yes | |
| server | Yes | |
| source | Yes | |
| license | Yes | |
| version | Yes | |
| provenance | Yes | |
| datenquellen | Yes | |
| protocol_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnlyHint=true) by specifying that the tool returns information about current functionality, planned extensions, MCP version, and phase. This contextual detail is useful for an agent.
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 extremely concise, with a clear front-loaded purpose sentence, a brief detail sentence, and a structured use case. Every sentence serves a purpose with no redundancy.
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 zero parameters and the existence of an output schema, the description sufficiently explains the tool's output: current functionality, planned extensions, MCP version, and phase. It is complete for an info tool.
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?
There are no parameters, so the description does not need to add parameter semantics. Baseline score of 4 is appropriate as the description does not contradict or miss any parameter-related details.
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 the tool displays server status and API phase information, with a specific use case about answering questions regarding server capabilities and roadmap. It distinguishes itself from sibling tools (all epl_* but different purposes) with no ambiguity.
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 <use_case> explicitly defines when to use this tool: to discover available tools and the roadmap status. It provides clear context without needing to mention alternatives, as the tool is unique in its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suche in der Spezialitaetenliste (SL) nach kassenpflichtigen Medikamenten.
Die SL enthaelt alle Arzneimittel, die von der obligatorischen Krankenpflegeversicherung (OKP) verguetet werden (KVG Art. 52).
Beantwortet «Ist Medikament X kassenpflichtig?». Liefert Treffer aus der SL bzw. — solange die BAG-API nicht oeffentlich ist — einen Direktlink plus Rechtsgrundlage. Fuer Geburtsgebrechen siehe epl_ggsl_abfrage, fuer Hilfsmittel epl_migel_suche.
| Name | Required | Description | Default |
|---|---|---|---|
| eingabe | Yes |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| source | Yes | |
| hinweis | No | |
| results | No | |
| match_type | Yes | |
| provenance | Yes | |
| direkt_link | No | |
| fhir_status | No | |
| suchbegriff | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by noting that it returns a direct link and legal basis currently due to the BAG-API not being public, implying fallback behavior. No contradictions with annotations.
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?
Description is concise with 5 sentences, front-loaded with the main action, and no unnecessary text. The use_case section is well-structured and adds value without redundancy.
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 tool's complexity (search with pagination and format), the description covers the purpose, use cases, and current behavior. Output schema exists for return values. Minor gap: does not explain how to interpret multiple results or the precision of the search, but overall 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?
Input schema has high description coverage (100%) with each parameter described (suchbegriff, limit, format). The tool description does not add further parameter details, so baseline 3 is appropriate.
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 the verb 'Suche' (search) and the specific resource 'Spezialitaetenliste' (SL) for medications covered by insurance. It further specifies the use case of determining if a medication is covered, and distinguishes from siblings by referencing epl_ggsl_abfrage and epl_migel_suche.
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 states when to use this tool: to answer 'Ist Medikament X kassenpflichtig?'. It also provides alternatives for birth defects (epl_ggsl_abfrage) and aids (epl_migel_suche), giving clear guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool serves a distinct purpose in the Swiss health insurance domain: drug specialty list, birth defects coverage, medical devices, legal context, server info, and pending applications. No overlap in functionality.
All tools use the prefix 'epl_' followed by descriptive snake_case names (e.g., epl_sl_suche, epl_migel_suche), forming a clear and consistent pattern.
With 6 tools, the server covers the core queries related to Swiss health insurance lists and legal context without being overwhelming or sparse.
The tool set provides comprehensive coverage for the domain: drug search, birth defects, medical devices, pending applications, legal explanations, and server metadata. No obvious gaps for an information-retrieval server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search Swiss federal legislation: laws, articles, amendments via the Fedlex SPARQL endpoint.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Live US drug acquisition costs (CMS NADAC) for AI assistants. Free, no auth, weekly data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/malkreide/bag-epl-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
