What can you do with this server?

This server provides access to Swedish statutes (SFS, Svensk författningssamling) from the Riksdagen open data API, enabling search, metadata retrieval, and full-text access with verifiable citations. * se_search(query): Free-text search over SFS statutes by title and full text (e.g., "dataskydd" for data protection laws), returning matching acts with metadata including SFS number, title, authority, and date. * se_get_act(sfs_number): Fetch detailed metadata for a specific statute by SFS number (e.g., "2018:218"), including title, issuing authority, publication date, and consolidation marker. * se_get_text(sfs_number): Retrieve the full consolidated plain text of a statute, reflecting all amendments up to the latest consolidation marker (ändrad t.o.m.). Every response includes a citation contract with: * eli_uri — the official Riksdagen document URI (Sweden does not publish native /eli/ URIs; this server never fabricates one) * human_readable_citation — act title with embedded SFS number * source_url — a browsable link to the official source * consolidated_through — the last amendment incorporated Note: This server covers Swedish statutes (SFS) only — not case law. It uses public data from data.riksdagen.se and is designed to fail loudly rather than fabricate data.

How do I use se-eli-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@se-eli-mcp Find the Swedish Data Protection Act" 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.

se-eli-mcp

by matematicsolutions

Overview Schema Related Servers Score Discussions

Python

Remote

se-eli-mcp

Install (one command)

Published on PyPI + MCP Registry (io.github.matematicsolutions/se-eli-mcp). Run without cloning:

uvx se-eli-mcp

Configure your MCP client (stdio):

{ "mcpServers": { "se-eli-mcp": { "command": "uvx", "args": ["se-eli-mcp"] } } }

Windows 11 with Smart App Control

Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe and the se-eli-mcp.exe launcher that pip writes at install time. The python.exe and py.exe from the python.org installer are signed by the Python Software Foundation, so running the module through the interpreter works:

python -m pip install se-eli-mcp
python -m se_eli_mcp

pip.exe is blocked for the same reason, so install with python -m pip, not pip install. If python is not on PATH, use the Windows launcher: py -3 -m se_eli_mcp.

{ "mcpServers": { "se-eli-mcp": { "command": "python", "args": ["-m", "se_eli_mcp"] } } }

Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.

Building from source: see Install.

An MCP server for Swedish statutes (SFS, Svensk författningssamling), served as open data by the Riksdagen (parliament) at data.riksdagen.se (keyless). It gives an AI agent the consolidated text of an act with a verifiable citation: a persistent identifier, a human-readable citation, and a link to the official source.

Part of the eu-legal-mcp line by MateMatic — one connector per EU member state, the same citation contract everywhere.

On ELI. Sweden does not publish native ELI (/eli/) URIs. To keep the line's contract honest, eli_uri carries the official persistent document identifier instead — the data.riksdagen.se/dokument URI (e.g. https://data.riksdagen.se/dokument/sfs-2018-218). The SFS number (2018:218) is the canonical Swedish citation. The connector never fabricates an /eli/ URI and says so in its tool instructions. See DISCOVERY.md.

Related MCP server: Danish Law MCP Server

Tools

Tool	What it does
`se_search(query)`	Free-text search over SFS statutes (title and full text). Returns acts, each with the citation contract.
`se_get_act(sfs_number)`	Metadata for one act by its SFS number (e.g. `2018:218`) — title, authority, date, consolidation marker.
`se_get_text(sfs_number)`	The full consolidated plain text of one act.
`se_coverage()`	Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback.

Every response carries the citation contract:

eli_uri — the official persistent identifier (document URI; see the ELI note above).
human_readable_citation — the act title, which embeds the SFS number, e.g. Lag (2018:218) med kompletterande bestämmelser till EU:s dataskyddsförordning.
source_url — the browsable data.riksdagen.se page for the act.
consolidated_through — the last amendment folded into the text (the "ändrad t.o.m." marker).

Install

pip install -e ".[dev]"

{
  "mcpServers": {
    "se-eli-mcp": {
      "command": "se-eli-mcp",
      "env": {
        "SE_ELI_BASE_URL": "https://data.riksdagen.se",
        "SE_ELI_CACHE_DIR": "~/.matematic/cache/se-eli",
        "SE_ELI_AUDIT_DIR": "~/.matematic/audit"
      }
    }
  }
}

Design

Public data only. Read-only against the keyless Riksdagen open-data API; nothing is sent beyond the query / SFS number.
Audit log. Every call appends one JSON line to ~/.matematic/audit/se-eli-mcp.jsonl (AI Act art. 12 record-keeping).
Vendor-neutral. No LLM provider, no telemetry; own backoff + on-disk cache.
No fabrication. Identifiers and titles are parsed from the source record. If Riksdagen's schema changes, the connector fails loudly rather than returning stale or invented data.

See CONSTITUTION.md (the 4 principles) and DISCOVERY.md (how the source was mapped).

Tests

pytest tests/test_instructions_drift.py tests/test_parse.py   # offline
pytest tests/test_smoke.py                                     # live Riksdagen API

Licence

Apache-2.0. The Swedish legislation served is official public data of the Kingdom of Sweden; this connector adds no rights over it.

Available Tools

4 tools

se_coverageA

Read-onlyIdempotent

Declare what this connector covers, how it is sourced, and what it does NOT cover.

Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.

Returns: Coverage with families, an as-of note, and a non-empty list of known gaps.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	No
`families`	No
`as_of_note`	Yes	States what the dates mean, and what they do not promise.
`known_gaps`	No	Never empty. An empty list would mean 'not checked', not 'no gaps'.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark it read-only/open-world/idempotent; the description adds crucial context: an empty result may reflect a connector gap, not the law, and every gap includes a fallback location. This materially shapes agent behavior and supplements the structured hints without contradicting them.

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 front-loaded with the core purpose, then gives actionable usage guidance, fallback behavior, and return shape. Every sentence earns its place and there is no filler.

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 no-parameter, no-side-effect tool with an output schema, the description fully covers when to call it, what behavioral caveat matters (open world), and what the response contains. Nothing necessary for correct invocation is missing.

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, so schema coverage is trivially complete. The description does not need to document parameter meaning; baseline 4 applies because no parameter semantics are absent.

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 names a specific verb and resource: 'Declare what this connector covers, how it is sourced, and what it does NOT cover.' It distinguishes this meta/coverage tool from the sibling search/get tools by framing it around connector gaps rather than law content.

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?

It gives explicit trigger conditions: call before claiming the law does not contain something and whenever a search returns empty. It does not explicitly name sibling alternatives, but the fallback pointer and open-world framing make the intended use clear.

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

se_get_actA

Read-onlyIdempotent

Fetch metadata for a Swedish statute by its SFS number.

ParametersJSON Schema

Name	Required	Description	Default
`sfs_number`	Yes	e.g. ``"2018:218"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No
`title`	No
`dok_id`	No
`eli_uri`	No
`text_url`	No
`authority`	No
`sfs_number`	No
`source_url`	No
`date_issued`	No
`consolidated_through`	No
`human_readable_citation`	No

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Description adds minimal behavioral context beyond stating 'Fetch metadata,' which aligns with readOnly. 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.

Conciseness5/5

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

Single sentence that is front-loaded, concise, and contains no extraneous information. Every word contributes to understanding.

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?

Tool is simple with one parameter, has rich annotations, and an output schema exists. The description adequately covers what is needed for an agent to use it correctly.

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?

Schema description coverage is 100% with a clear example for sfs_number. Description mentions 'SFS number' but does not add significant meaning beyond the schema's provided example.

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?

Description clearly states the action (Fetch), resource (metadata for a Swedish statute), and key parameter (SFS number). It distinguishes from sibling tools se_get_text and se_search by focusing on metadata retrieval.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like se_get_text or se_search. The description does not provide context for appropriate usage.

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

se_get_textA

Read-onlyIdempotent

Fetch the full consolidated plain text of a Swedish statute by its SFS number.

ParametersJSON Schema

Name	Required	Description	Default
`sfs_number`	Yes	e.g. ``"2018:218"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`dok_id`	Yes
`format`	No
`content`	No
`eli_uri`	No
`text_url`	No
`byte_size`	No
`sfs_number`	No
`source_url`	No
`dataset_note`	No
`consolidated_through`	No
`human_readable_citation`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that the output is 'full consolidated plain text,' but no additional behavioral context 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.

Conciseness5/5

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

Single sentence, front-loaded with key information, no wasted words.

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 tool's simplicity (1 parameter, output schema present, annotations complete), the description provides sufficient context for an agent to use it correctly.

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?

Schema coverage is 100% with an example. The description does not add semantic meaning beyond the schema, achieving baseline.

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's purpose: fetching full consolidated plain text of a Swedish statute by SFS number. It is specific and distinct from sibling tools like se_get_act and se_search.

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

Usage Guidelines3/5

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

The description implies usage when the SFS number is known and full text is needed, but it does not explicitly compare to sibling tools or provide 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.

se_searchA

Read-onlyIdempotent

Search Swedish statutes (SFS) by free text (title and full text).

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	e.g. ``"dataskydd"``.

Output Schema

ParametersJSON Schema

Name	Required	Description
`items`	No
`query`	Yes
`returned`	Yes
`dataset_note`	No
`total_matched`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already classify the tool as readOnlyHint, idempotentHint, and destructiveHint false. Description adds that the search is over title and full text, which is behavioral context, but adds little beyond annotations.

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?

Single, concise sentence that front-loads the action and resource. Every word contributes to understanding.

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?

With only one required parameter, clear annotations, and an output schema, the description covers the tool's functionality sufficiently for an agent to correctly select and invoke it.

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 coverage is 100% and provides an example. Description enhances parameter meaning by specifying that 'query' searches both title and full text, adding value beyond 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?

Description clearly states it searches Swedish statutes (a specific resource) by free text in title and full text. It distinguishes from sibling tools 'se_get_act' and 'se_get_text' which likely retrieve specific acts, making purpose unambiguous.

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?

Description implies usage for searching statutes, but does not explicitly state when to use this tool vs siblings or when not to use it. It provides clear context for use.

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. Dates show when Glama detected each change.

1 tool updatev0.3.3Aug 28, 2026
- Addedse_coverage
3 tool updatesv0.1.0Jun 24, 2026
- First observedse_get_act
- First observedse_get_text
- First observedse_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: search by text, fetch metadata by SFS number, fetch full text, and declare coverage gaps. No two tools could be confused for one another.

Naming Consistency4/5

All tools share the se_ prefix and mostly follow a verb-based pattern (se_search, se_get_act, se_get_text). se_coverage is a noun instead of a verb, which is a minor deviation but still predictable and readable.

Tool Count5/5

Four tools is a well-scoped set for a Swedish legal information connector. Each tool has a clear role with no redundancy.

Completeness4/5

The connector provides search, metadata retrieval, full text retrieval, and explicit coverage gap handling, which covers the core research workflow. A minor gap is the lack of functions for listing or browsing statutes, but the coverage tool mitigates confusion from missing results.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

kvasir — verifiable German, Austrian, Swiss & EU lawOAuth
legal.kvasir
Resolve, search and verify legal citations against the official sources, with provenance.
Legal & Compliance Search
2
OpenHelvetia Gateway A
swiss.openhelvetia
Swiss federal law (Fedlex) and political data (LINDAS) for agents, every answer with sources
521
Ansvar: Swedish LawOAuth
eu.ansvar
Swedish law + work env. via Ansvar Gateway. Cited, OAuth + paid tier.
Legal & Compliance Government Data Search
2
Ansvar: EU RegulationsOAuth
eu.ansvar
EU regulations (GDPR, DORA, NIS2, AI Act, etc.) via Ansvar Gateway. Cited, OAuth + paid.
Legal & Compliance Government Data
2

Related MCP Servers

Apiverket MCP Server
Government Data Open Data
vinvuk
A
license
A
quality
D
maintenance
Query Swedish public data from AI tools. Includes company data, SCB statistics, weather, transport, public agencies, and more through the Apiverket API.
Updated 2 months ago (2026-06-23 05:55 UTC)
2
57
2
MIT
Danish Law MCP Server
Legal & Compliance Search Knowledge & Memory
Ansvar-Systems
A
license
A
quality
F
maintenance
Enables querying and analyzing Danish legislation, including search, citation validation, currency checks, and EU law integration, directly from AI assistants.
Updated a month ago (2026-07-22 10:34 UTC)
15
72
1
Apache 2.0
Swedish Law MCP
Legal & Compliance Search Research & Data
Ansvar-Systems
A
license
A
quality
F
maintenance
Enables querying Swedish statutes, provisions, case law, preparatory works, and EU law cross-references from any MCP-compatible client.
Updated 2 months ago (2026-07-07 03:57 UTC)
19
180
Apache 2.0
dk-eli-mcp
Legal & Compliance Government Data
matematicsolutions
A
license
A
quality
A
maintenance
Provides access to Danish legislation from Retsinformation.dk, enabling retrieval of act metadata, full text, and recent changes with verifiable citations.
Updated 13 days ago (2026-08-24 13:55 UTC)
4
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/se-eli-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server