Blog

Swedish law as an MCP server: how SFS statutes become a queryable corpus

We took 6,041 Swedish statutes from Riksdagen, segmented them to the section level, and exposed them as an MCP your AI client can query by SFS number, chapter, and paragraf — with a citation on every result. Here is how the corpus is built and what the queries look like.

Sweden publishes its statutes through Riksdagen's open-data API at data.riksdagen.se. It is genuinely open — Swedish statutory text carries no copyright under Upphovsrättslagen (1960:729) 9 §, which excludes författningar from protection — but "open" and "queryable" are not the same thing. The API hands you whole documents with line-break artifacts, embedded amendment notes, and the occasional table-of-contents fragment masquerading as a provision. If you want to ask "what does Chapter 3, Section 12 of this act say," you have a parsing project, not an answer.

We built the Swedish Law MCP to close that gap. It holds 6,041 consolidated statutes and 58,570 provisions, segmented to the section level, and exposes them through the Ansvar gateway as tools your own AI client can call. This post walks the whole path: source, consolidation, segmentation, citation format, and what the queries actually look like from Claude or Copilot. It is the worked example behind every jurisdiction on our coverage page — Sweden happens to be the one we know best, and its page lives at /coverage/sweden.

The source: SFS via Riksdagen#

Svensk författningssamling (SFS) is the official gazette where Swedish laws and ordinances are published. Riksdagen's open-data API is the authoritative channel for the consolidated text — the statute as currently amended, not the original 1962 print. Every statute carries an SFS number of the form year:number: Brottsbalken is 1962:700, Miljöbalken is 1998:808, Avtalslagen is 1915:218. The number is the primary key. It never changes, even as the act is amended hundreds of times across decades.

We pull from Riksdagen on a daily check-for-drift schedule. The API documents statute full text, SFS metadata, issue and in-force dates, and the document's internal structure — chapters, sections, paragraphs. What it does not give you is editorial annotation or commentary; this is plain statutory text. That suits a compliance use case, where you want the law as enacted, not a secondary author's gloss.

On licensing: the underlying statutory text is public-domain by statute, so we can redistribute it without a vendor agreement. We tag every Swedish item with the SE-Statutory-PD licence code and the riksdagen.se publisher, and the gateway enforces that the attribution triple — source URL, publisher, licence — is present on every result before it leaves the edge. An item missing any of the three is dropped, not silently passed through.

Consolidation: the amended text, not the original#

A Swedish statute from 1977 has typically been amended dozens of times. Each amendment is its own SFS publication (Arbetstidslagen is 1982:673, but the act has been changed by scores of later SFS numbers). The version you want to reason about is the consolidated text — every amendment folded in, the law as it reads today.

Riksdagen publishes that consolidated form, which saves us from having to reconstruct it from a base act plus an amendment chain. What we keep is the relationship: each provision's text, and the trailing law-note that records which SFS amendment last touched it. Those notes look like Lag (1987:823). at the end of a section. They are useful provenance but they are not part of the operative text, so the parser strips them from the section body and preserves the SFS lineage separately. That keeps a search for the substance of a section from matching on a string of amendment numbers.

There is a known lag: Riksdagen's consolidated text can trail an official publication by 24–48 hours, and our daily ingest adds its own small window. For compliance work the freshness check matters, which is why the corpus exposes its last-verified date rather than implying it is real-time.

Segmentation: chapter and paragraf#

This is the part that turns a document dump into a queryable corpus. Swedish statutes come in two structural shapes:

  • Flat acts number sections sequentially: 1 §, 2 §, 3 §, sometimes with letter suffixes for inserted sections — 15 a §, 15 b §. Avtalslagen (1915:218) is flat; its first section is just 1 §.
  • Chaptered acts — the balkar (Brottsbalken, Miljöbalken, Jordabalken) and many newer acts implementing EU regulations — number sections within chapters: 3 kap. 12 § is Chapter 3, Section 12. Our parser stores these as a chapter-qualified reference like 3:12.

The parser activates a chapter on a line matching N kap., then attaches each following N § section to it, and enforces section monotonicity — section numbers must increase within a chapter — so a table-of-contents line that lists section numbers out of order does not get mislabelled as an actual provision. It is a conservative parser by design: it would rather skip an ambiguous candidate than invent a section that is not there. That bias matters for a compliance corpus, where a phantom provision is worse than a missing one.

The result is that every one of the 58,570 provisions is addressable by its statute (SFS number) plus its in-statute reference (paragraf, or chapter-and-paragraf). That addressability is what makes citation deterministic, which is the next piece.

Citation format: SFS number plus reference#

A Swedish legal citation is two coordinates. First the statute, identified by SFS number — SFS 2024:1278. Then the location inside it, formatted by structure: a flat statute renders as 34 §, a chaptered statute as 3 kap. 12 §. Put together, a full citation reads 3 kap. 12 § SFS 1998:808 — Chapter 3, Section 12 of Miljöbalken.

The gateway builds that citation from the structured reference, not from prose. When a result comes back, it carries a citation block: the canonical SFS reference, the human display text, the official Riksdagen source URL for that statute, the publisher (riksdagen.se), and the public-domain licence tag. The source URL follows Riksdagen's own pattern — for SFS 2024:1278 it resolves to riksdagen.se/.../sfs-2024-1278, so a reader can click straight to the official text.

This is the difference between a model that says "I think Swedish data-protection law requires X" and a tool that returns the section text with a citation you can verify. The citation is validated deterministically: same reference in, same provision out, every time. That property is what makes the output usable in a regulator-facing or audit context, where "the model said so" is not an acceptable provenance.

What the queries look like#

You drive the corpus from your own AI client — Claude Desktop, Claude Code, Copilot in VS Code or Studio, Cursor, anything that speaks MCP. Connect once to gateway.ansvar.eu/mcp over OAuth 2.1 and the Swedish tools are available scoped to jurisdictions=['SE']. Three patterns cover most of what compliance and engineering teams ask.

Search by topic. Swedish search works in Swedish — the corpus is Swedish-language text, so a Swedish query term matches best. To find personal-data provisions you search the native term:

code
search(query="behandling av personuppgifter", jurisdictions=["SE"])

That returns statute-level hits across the corpus — the acts implementing EU data-protection rules, the Skatteverket personal-data act (SFS 2001:182, which numbers its sections 1 kap. 1 §, 1 kap. 2 §), and related provisions, each item carrying its SFS number and Riksdagen URL.

Fetch an exact provision. When you already know the statute and section, get_provision returns the section text verbatim:

code
get_provision(jurisdiction="SE", law="2024:1278", article="1:1")

SFS 2024:1278 is the Swedish act that complements DORA — the EU Digital Operational Resilience Act, Regulation (EU) 2022/2554 — for the financial sector. Its first section (1 kap. 1 §) states that the act complements that regulation; a later section records that, per Article 46 DORA, Finansinspektionen is the competent authority. That is a clean illustration of why national and EU layers both matter: DORA sets the obligation, the Swedish act names the supervisor and the fee regime. An AI-Act-readiness or DORA gap analysis that stops at the EU regulation misses the member-state machinery that actually enforces it.

Validate a citation you already hold. If a draft policy or a prior report cites 3 kap. 12 § SFS 1998:808, validate_citation confirms whether the reference resolves and returns the current text — useful when a statute has been amended since the citation was written:

code
validate_citation(jurisdiction="SE", law="1998:808", article="3:12")

In every case the agent calls the tool, the gateway returns the cited section, and your client presents it. The model is how you ask; the corpus is what answers. That split is deliberate — there is no server-side model inventing legal text in the loop, only a deterministic lookup against the segmented corpus.

Free, premium, and what each covers#

The full 6,041-statute consolidated corpus and section-level lookups are on the free tier: 100 searches a day, single-jurisdiction, no card. That is enough to wire the Swedish corpus into your agent and run real queries before deciding anything.

Premium (€249/month/seat) adds two things that matter for Swedish legal work specifically. It unlocks multi-jurisdiction fan-out, so a single search can reach Sweden alongside EU regulations and other member states in one call — the pattern you want for a cross-border compliance question. And it unlocks the Swedish premium corpora: 12,767 court-decision summaries from ten-plus courts including the Supreme Court, the Labour Court, and the Supreme Administrative Court, with Swedish originals reaching back to 1981; and 6,735 preparatory-works documents (the förarbeten that Swedish legal interpretation leans on heavily). Those are the sources a Swedish lawyer reaches for when statute text alone does not settle a question.

Why we built it as 30-plus jurisdictions, not one#

Sweden is one audited jurisdiction of 30 live on the platform, drawn from a wider set of 107 law MCPs. Each one follows the same recipe: official source, consolidated text, structural segmentation, deterministic citation, daily drift check. The shapes differ — Sweden's kap. § is not Germany's § Abs. is not France's article numbering — but the contract is identical: every provision addressable, every result cited, every citation verifiable against the official source.

That uniformity is what makes a multi-jurisdiction gap analysis or threat model tractable. Your agent does not need to know that Riksdagen formats sections differently from Légifrance; it calls the same search and get_provision tools with a different jurisdictions scope and gets back the same cited result shape. The per-jurisdiction parsing work is done once, behind the tool, so the compliance team querying it never has to think about Riksdagen's line-break artifacts again.

Try it against Swedish law#

If your client speaks MCP, connecting takes about two minutes:

  1. Point it at https://gateway.ansvar.eu/mcp and complete the OAuth flow — the quickstart has the per-client config.
  2. Ask your agent something concrete: "Use the Ansvar gateway to find Swedish provisions on personal-data processing, scoped to Sweden, and show me the section text with citations."
  3. The agent calls search with jurisdictions=['SE'], returns the cited hits, and you drill into any one with get_provision.

The corpus is the same one behind /coverage/sweden, built from data.riksdagen.se, segmented to 58,570 cited provisions, and free to query up to 100 times a day. If you have ever wanted a Swedish law API that returns the section text and the SFS citation in one call, that is exactly what this is.

Frequently asked

What source does the Swedish law corpus come from?
All statutory text comes from data.riksdagen.se, the Swedish Parliament's official open-data API for Svensk författningssamling (SFS). It is the authoritative publication channel for consolidated statute text, SFS numbers, issue dates, and in-force dates. Swedish statutory text carries no copyright under Upphovsrättslagen (1960:729) 9 §, which excludes författningar — laws and regulations — from protection, so the underlying text is public-domain. Court-decision summaries in the premium corpus carry their own per-item source attribution. We re-check Riksdagen daily for drift; the corpus currently holds 6,041 statutes and 58,570 provisions.
How do I cite a specific Swedish provision through the gateway?
Swedish citations have two parts: the SFS number that identifies the statute (year:number, e.g. SFS 2024:1278) and the provision reference inside it. Flat statutes use a bare paragraf — '34 §'. Chaptered statutes (the balkar and many newer acts) use chapter-and-paragraf — '3 kap. 12 §'. The gateway's get_provision tool takes the jurisdiction (SE), the law, and the article reference and returns the exact section text plus a citation block carrying the SFS number, the Riksdagen source URL, and the public-domain licence tag. Every result is built from that structured reference, not a model's recollection.
Is the Swedish corpus free to query?
Yes, on the free tier — 100 searches a day, single-jurisdiction, no card. Connect any OAuth 2.1 MCP client to gateway.ansvar.eu and scope your search to jurisdictions=['SE']. The free tier covers the full 6,041-statute consolidated corpus and section-level lookups. Premium (€249/month/seat) adds multi-jurisdiction fan-out and the Swedish premium corpora — 12,767 court-decision summaries and 6,735 preparatory-works documents for Sweden alone.
Why an MCP instead of just scraping Riksdagen myself?
Riksdagen's API gives you raw documents with line-break artifacts, table-of-contents fragments, and inconsistent chapter markers. Turning that into a corpus you can query by section means parsing the chapter and paragraf structure, stripping amendment notes, and validating that section numbers stay monotonic so a table-of-contents line does not get mislabelled as a provision. We did that segmentation once, validated it against the source, and exposed it as a tool that returns clean section text with a citation. The point of the MCP is that your AI client gets a queryable, cited corpus instead of a scraping project.