Skip to main content
Glama
RetiredOnMyTerms

rcw-mcp

by RetiredOnMyTerms
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

chaimp-mcp-rcw

A small Model Context Protocol (MCP) server for the Revised Code of Washington (RCW) — Washington State statutes. Built as a learning project: a stdio MCP server in TypeScript that Claude Code (or any MCP client) can call.

Tools

Tool

What it does

Source

get_section

Full text of an RCW section by cite (e.g. 9A.36.021) — caption, statutory text, history/notes

scrapes app.leg.wa.gov/RCW HTML

search

Find RCW citations matching a partial cite (e.g. 9A.36 → 9A.36.011, 9A.36.021, …)

lawdoccitelookup.leg.wa.gov JSON API

cite_affected

Bills in a biennium that amend/affect a cite

wslwebservices.leg.wa.gov SOAP service

Note on search

Washington exposes no public full-text RCW search API. search matches citations, not keywords — "assault" returns nothing, "9A.36" returns the sections in that chapter. Use it to discover cites, then pass them to get_section.

Related MCP server: cpl-mcp

Data sources (all public, read-only, no keys)

  • Section text: https://app.leg.wa.gov/RCW/default.aspx?cite=<CITE> (HTML, parsed with cheerio)

  • Cite lookup: https://lawdoccitelookup.leg.wa.gov/v1/rcw/<query>/<limit> (JSON)

  • Affecting bills: https://wslwebservices.leg.wa.gov/rcwciteaffectedservice.asmx operation GetLegislationAffectingRcwCite (SOAP 1.1)

Setup

git clone https://github.com/RetiredOnMyTerms/rcw-mcp.git
cd rcw-mcp
npm install
npm run typecheck     # tsc --noEmit
npm run smoke         # hit all three data sources, print results

Add to Claude Code

Run these from the repo root — $(pwd) / $(Get-Location) fills in the absolute path, so nothing is machine-specific.

Run source directly with tsx (no build step):

# macOS / Linux / Git Bash
claude mcp add rcw --scope user -- npx tsx "$(pwd)/src/index.ts"
# Windows PowerShell
claude mcp add rcw --scope user -- npx tsx "$(Get-Location)\src\index.ts"

Or build and point at the compiled output:

npm run build
claude mcp add rcw --scope user -- node "$(pwd)/dist/index.js"

See INSTALL.md for full details and other MCP clients.

Then in a Claude Code session:

  • "Get RCW 9A.36.021" → get_section

  • "What RCW sections are in chapter 42.56?" → search

  • "What bills in 2007-08 affected RCW 9A.36.021?" → cite_affected

Inspect standalone

npm run inspector     # opens the MCP Inspector against the server

Layout

src/
  index.ts            MCP bootstrap: registers the 3 tools, stdio transport
  http.ts             fetch wrapper (User-Agent, timeout, normalized errors, SOAP POST)
  cache.ts            in-memory TTL cache
  tools/
    getSection.ts     scrape + parse a section page (cheerio)
    search.ts         cite-lookup JSON client
    citeAffected.ts   SOAP call + XML parse (fast-xml-parser)
scripts/
  smoke.ts            direct end-to-end test of all three tools

Notes / limitations

  • Scraper selectors track the current app.leg.wa.gov markup; if the site changes, get_section returns an honest error rather than garbage.

  • get_section caches parsed sections in memory for 1 hour (process lifetime).

  • All statute content is © the State of Washington; this tool only fetches and formats public pages.

License

MIT © James Whelan. Covers this tool's code only — RCW statutory text is a work of the State of Washington.

Available Tools

3 tools
cite_affectedBills affecting an RCW citeA

List bills in a biennium that amend or affect a given RCW citation, via the Washington State Legislature SOAP web service. Biennium format is "2025-26" (defaults to the current biennium, 2025-26).

ParametersJSON Schema
NameRequiredDescriptionDefault
citeYesRCW cite, e.g. 9A.36.021 (or a chapter 9A.36)
bienniumNoBiennium like "2025-26"; defaults to current

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden for behavioral disclosure. It adds context about the SOAP web service and the biennium default, but doesn't describe output format, error behavior, or any side effects. The read-only nature is implied by 'List,' so a score of 3 reflects the partial but not comprehensive disclosure.

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 two sentences, front-loaded with the primary function, and adds only the essential detail about the biennium format and default. Every sentence is purposeful with no redundancy.

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?

For a tool with only 2 parameters and no output schema, the description adequately covers its purpose, the default biennium, and the external service. It lacks explicit detail on return values, but the tool's simplicity and the absence of an output schema keep the score at 4 rather than lower.

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 schema already provides descriptions for both parameters (cite and biennium) with examples and default behavior. The description's mention of biennium format and default adds nothing beyond the schema, so with 100% schema coverage, the baseline score of 3 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 uses the specific verb 'List' and identifies the target resource as 'bills in a biennium that amend or affect a given RCW citation,' clearly distinguishing this from sibling tools like get_section and search. The purpose is immediately evident.

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 explains the tool's context (RCW citation, biennium) and provides the default biennium behavior, but it doesn't explicitly state when to use this tool over siblings or mention exclusions. This is clear context without explicit alternatives, matching a score of 4.

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

get_sectionGet RCW sectionA

Return the full text of a Revised Code of Washington (RCW) section by its citation, e.g. 9A.36.021. Includes the caption, statutory text, and history/notes. Source: app.leg.wa.gov.

ParametersJSON Schema
NameRequiredDescriptionDefault
citeYesSection-level RCW cite, e.g. 9A.36.021 or 42.56.070

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It discloses that the tool returns full text, includes caption and history/notes, and indicates the data source (app.leg.wa.gov). It does not describe error handling or latency, but for a simple read operation, this is sufficient transparency.

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 two sentences, front-loaded with the primary action ('Return the full text...'), followed by specifics on included content and the source. There is no redundant or filler information; every sentence contributes meaning.

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?

For a simple one-parameter tool with no output schema, the description covers the essential information: what it does, what the return contains, and the data source. It does not specify the exact return format (e.g., plain text vs HTML) or error behavior, but for the tool's simplicity, this is adequate.

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 schema describes the 'cite' parameter with examples, and the description also includes an example citation. Since schema description coverage is 100%, the parameter meaning is fully documented. The description adds marginal value by integrating the cite format into the context, but does not go beyond the schema's detail.

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 returns the full text of an RCW section by citation, with specific examples like 9A.36.021. It explicitly lists included components (caption, statutory text, history/notes), distinguishing it from sibling tools such as search and cite_affected by focusing on retrieving a known section's full text.

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 clear context: use this when you have a section citation and need the full text. It does not explicitly mention alternatives, but the sibling tool names imply search is for finding sections and cite_affected for affected citations. No exclusions are stated, but the purpose is unambiguous enough for an agent to decide.

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.

  1. 3 tool updatesv0.1.1
    • First observedcite_affected
    • First observedget_section
    • First observedsearch
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: get_section retrieves full text, search finds citations by partial citation string, and cite_affected lists bills affecting a citation. There is no overlap between these functions, and the descriptions explicitly warn about search's limitation to citations, reducing ambiguity.

Naming Consistency2/5

The naming conventions are inconsistent: 'get_section' follows a verb_noun pattern, 'search' is a bare verb, and 'cite_affected' uses an awkward compound that doesn't clearly convey its purpose. This mixed style makes the tool set feel less predictable and cohesive.

Tool Count4/5

With only 3 tools, the server is on the thin side, but for a niche domain like RCW legal references, this count is reasonable. The tools cover the core workflows of finding a section, retrieving its text, and checking related bills, so the count feels appropriate for the scope.

Completeness3/5

The set provides essential retrieval and citation lookup, but notable gaps exist: there is no keyword search, no browsing of titles or chapters, and legislative history is limited to bills affecting a specific citation. While the description notes an API constraint, the surface is still somewhat incomplete for broad legal research.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers