Specline · MCP

MCP server

You shouldn't have to paste the methodology into a chat, and the agent shouldn't have to shell out to a CLI to check itself. The MCP server makes Specline tools the agent calls natively — so a planning agent pulls the canon and checks its own work mid-session, in the flow. Same engine, same output contract. Only the transport changes.

Register it once, at user scope

With Claude Code, register it at user scope so it's there in every repo you open:

shell

claude mcp add --scope user specline -- \
  node /abs/path/to/cli/src/mcp/index.ts

Use your actual absolute path to cli/src/mcp/index.ts. Verify with claude mcp get specline — it should report ✔ Connected. The server is dependency-free stdio JSON-RPC; nothing to install.

The three tools

Tool	Does	Arguments
specline_check	Validate a repo; returns the JSON report.	`path` (req), `mode`, `changed[]`, `now`, `tier`
specline_spec	Return the pinned canon — inject to make the agent aware of Specline.	—
specline_rules	Return the rule catalog the agent will be checked against.	—

How an agent uses it

On opening a Specline repo, the agent calls specline_spec to load the methodology and specline_rules to learn what it'll be graded on.
While shaping a spec with you, it calls specline_check in author mode, naming the files it touched — and self-corrects from each finding's rule_id + fix_hint.
Before handoff, one specline_check in gate mode confirms zero errors.

↩

It's the same canon, reached two ways. /spec.md serves it over HTTP for you; specline_spec hands it to the agent inside the repo.

You don't need MCP for this

An agent with shell access — Claude Code, say — can already run the CLI straight: specline check --mode author --format json, then parse the result. MCP earns its keep by making Specline a first-class tool the agent discovers on its own, in any client. That's the whole difference.