South Dakota Code

@pipeworx/south-dakota-code

South Dakota Codified Laws (South Dakota state statutes) — full section text by citation, and topic/keyword search over official catchlines.

Part of Pipeworx — an MCP gateway connecting AI agents to 1721+ live data sources. This is an independent, unofficial integration — not affiliated with, endorsed by, or published by the upstream provider.

Tools

• sd_statute(citation) — full current text of one SDCL section (e.g. "22-16-4", murder in the first degree), with the official catchline, chapter/title context, and — when the section carries one — the "Source:" line listing every session law that enacted or amended it, split out into history.
• sd_search(query, limit?) — topic/keyword search over the Legislature's own official section and chapter catchlines across all 71 titles (e.g. "landlord", "concealed pistol permit"). Not full-text search — South Dakota does not publish one.

Auth

Keyless.

Data sources

• https://sdlegislature.gov/api/Statutes/Statute/{citation} — one section's (or chapter's, or title's) current text, as JSON with an Html field. sd_statute calls this live, per request, for a section-shaped citation.
• https://sdlegislature.gov/api/Statutes/Title — the list of all 71 titles. Used only by scripts/bake-index.mjs to drive the per-title fetch below.

Capabilities — three available, one is not

South Dakota's own publication covers:

• Citation lookup — sd_statute.
• Topic/keyword search — sd_search, over catchlines only (see below).
• Amendments/enactment history — PARTIALLY AVAILABLE. An in-force section's text ends with a "Source: SDC 1939, § 13.2007 (1); SL 1979, ch 160, § 2; ..." line listing every session law that created or amended it (verified live on 22-16-4). sd_statute splits this into history rather than leaving it only embedded in text. A repealed/transferred section's one-line disposition (e.g. "22-16-9. Repealed by SL 2005, ch 120, § 158, eff. July 1, 2006.") comes back as disposition_text, with repealed: true read from the API's own flag.
• Historical version (the text as it read before an amendment) — NOT AVAILABLE. sdlegislature.gov publishes only the CURRENT online edition: no per-year archive, no "view as of" date picker, and no endpoint returning a prior version's text (checked the site's own JS bundle for one — none exists). The Source: line says WHEN and by WHICH session law a section was amended; it does not return what the text read before that.

Source and shape — read this before touching the parser

sdlegislature.gov is a Vue single-page app. The August state-law survey (docs/state-law-probe.md) correctly flagged the HTML shell as carrying no statute — it just stopped one layer too early. The SPA itself is fed by a keyless, public JSON API under /api/Statutes/ (found by grepping the site's own JS bundle for /api/Statutes — no documentation page exists for it): GET /api/Statutes/Statute/{citation} accepts a section citation ("22-16-4"), a chapter citation ("22-16") or a title number ("22"), and returns one JSON envelope whose Html field is that level's content — full section text for a section, or a plain table-of-contents listing (chapter header + every section's citation and catchline, with NO body text) for a chapter or title. No auth, no key, no rate limit observed.

sd_statute only ever calls the section-shaped form, live, per request — never baked.

sd_search needs a structural index (every citation + its official catchline) to search over, and there is no search endpoint and no single "whole code" listing page the way North Dakota publishes one. The only way to assemble one is to call the TITLE-level form for each of the 71 titles and parse its table-of-contents Html blob. scripts/bake-index.mjs does this once, offline, into src/sd-index-data.ts — never at request time.

Why the parser works off flattened TEXT, not HTML anchors. Each title's Html blob is a concatenation of chapters that were authored and HTML-exported independently over decades, so anchor markup is NOT uniform: some chapters link a citation as a modern anchor (sdlegislature.gov/Statutes?Statute=X), others use a legacy DisplayStatute.aspx?Type=Statute&Statute=X anchor form, and repealed-section entries repeat their own citation as a text label immediately before the real catchline. Rather than chase every anchor shape, the bake script strips ALL tags (dropping style/script element CONTENTS too — the first cut of this script leaked raw CSS text into a catchline because that content sits between tags, not inside one) and then scans the flattened text for citation-SHAPED TOKENS beginning with the known title number. This is markup-agnostic: it only depends on the citation strings the site already prints as plain text, uniform across every era of document. See the script's own header comment for the full detail, including how duplicate-token artifacts and the rare genuinely-duplicated citation (observed on <5% of sections) are handled — never silently, always resolved toward the longer catchline, since this index drives search RANKING only and sd_statute always re-fetches the real text live.

Refresh path: node scripts/bake-index.mjs > src/sd-index-data.ts whenever South Dakota recodifies (new session laws are folded in after each legislative session). Nothing else in the pack needs to change.

Known gaps

• sd_search matches official catchlines (section and chapter names), not full statutory prose — South Dakota does not publish full-text search, and this pack does not claim to either. It says so in both the tool description and every "no match" response.
• A citation present in the baked index that the LIVE API 404s on (e.g. a section renumbered or repealed since the index was last baked) returns a loud reason: "index_live_mismatch", never a plain found: false with no explanation.

Quick Start

Add to your MCP client (Claude Desktop, Cursor, Windsurf, etc.):

{  "mcpServers": {    "south-dakota-code": {      "url": "https://gateway.pipeworx.io/south-dakota-code/mcp"    }  }}

What this endpoint actually serves

tools/list at https://gateway.pipeworx.io/south-dakota-code/mcp returns the tools in the table above plus the shared Pipeworx meta-tools — ask_pipeworx, discover_tools, search_within, remember/recall and the rest of the gateway-wide set. So the tool count you see is larger than this table: a single-pack endpoint currently lists roughly 30 shared tools alongside the pack's own. The connection's initialize response states its exact scope, and is the authoritative answer for a given day.

This is deliberate, not multiplexing by accident. The meta-tools are what let a scoped connection answer a question this pack does not cover — via ask_pipeworx, which routes across the whole catalog — without you adding a second MCP server. There is currently no way to mount a pack endpoint without them; if the extra schemas cost you more context than the routing is worth, connect to the full gateway once rather than to several pack endpoints.

Or connect to the full Pipeworx gateway to get every pack's tools listed directly, instead of just this one's:

{  "mcpServers": {    "pipeworx": {      "url": "https://gateway.pipeworx.io/mcp"    }  }}

Both URLs reach the same gateway and the same 1721+ data sources. The only difference is which pack's tools are listed directly; ask_pipeworx reaches all of them from either one.

No MCP client? Call it over HTTP

curl -X POST https://gateway.pipeworx.io/v1/tools/sd_statute \  -H 'Content-Type: application/json' \  -d '{"citation":"22-16-4"}'

No account needed for the first calls. Inspect any tool: GET https://gateway.pipeworx.io/v1/tools/sd_statute. Find one: POST https://gateway.pipeworx.io/v1/tools/search_packs with {"query":"..."}.

Standalone (no gateway account)

This package also runs as a local stdio MCP server — no Pipeworx account, no gateway round-trip:

{  "mcpServers": {    "south-dakota-code": {      "command": "npx",      "args": ["-y", "@pipeworx/mcp-south-dakota-code"]    }  }}

Or run it directly to confirm it starts:

npx -y @pipeworx/mcp-south-dakota-code

It speaks MCP over stdin/stdout and answers initialize/tools/list/tools/call for only this pack's tools — none of the shared meta-tools the gateway connection above adds. Same source, same tools, no ask_pipeworx routing.

Using with ask_pipeworx

Instead of calling tools directly, you can ask questions in plain English — this works on the pack endpoint above as well as on the full gateway:

ask_pipeworx({ question: "your question about South Dakota Code data" })

The gateway picks the right tool and fills the arguments automatically.

More

• Docs and guides
• pipeworx.io

License

MIT