9 · Agents and MCP

Time: 20 minutes · You need: chapter 8 finished, and one of: a model API key, a logged-in claude/codex CLI, or Ollama.

The roles

Every one of them writes to the proposal store, never to your working tree:

sdods agent review -p rwa-bank
sdods proposals list
sdods proposals show <id>
sdods proposals accept <id> --branch sdods/<id>
sdods proposals reject <id>

Try it without a key first

sdods agent generate -p rwa-bank --goal "cover the contacts page" --dry-run

--dry-run uses the fake adapter and prints the system prompt, the tool list and the budget. It is the cheapest way to see exactly what a model would be told about your project.

Run it on your own machine

ollama serve &
ollama pull qwen2.5-coder:7b

sdods doctor                     # the "local models (ollama)" row turns green
sdods agent review -p rwa-bank --adapter ollama --model qwen2.5-coder:7b --context-tokens 16384

No key, no per-token cost, and the project never leaves the laptop. Two things make it work:

• Context. Ollama loads a model with a 4096-token context by default and truncates anything longer without saying so. SDODS refuses to start a job that would be truncated rather than letting you read a confident answer to half a question.
• The small profile. A local model is given five tools instead of thirty-five, one call per turn, and sixty of your project's real step patterns in the prompt. The run says which profile it chose: profile small (a local model) · 5 tool(s).

Expect a proposal worth editing rather than one worth merging — steps close to the real patterns, tags right, a scenario title you would keep. Read the diff before accepting it. Local models has the measurements behind each of those choices.

Budgets and roles

agents:
  provider: ollama
  models:
    default: qwen2.5-coder:14b
    reviewer: llama3.1:8b
  maxTurns: { healer: 20 }
  budgetUsd: { default: 2 }
  local:
    contextTokens: 16384

Models are per role, so planning can use a hosted model while generation stays local. Cost budgets apply to hosted providers; on a local model the turn budget is what bounds a job.

MCP: the other direction

The commands above put a model inside SDODS. The MCP server does the opposite — it puts SDODS inside your coding agent, so Claude Code or Codex can list features, read runs, analyse coverage and write proposals while you work.

sdods mcp install claude          # or: codex, all
sdods mcp --caps read             # stdio server, read-only tools
sdods mcp --http --port 4319      # over HTTP, for a remote agent

Then ask the agent, in its own words: "use sdods to list the failing scenarios of the last rwa-bank run and propose a fix." Tools are scoped by capability, write tools always produce proposals, and a token issued with sdods tokens create limits what a remote agent may reach.

Checkpoint

sdods agent review -p rwa-bank --dry-run && sdods proposals list

The dry run prints a prompt and tool list; with a real adapter, proposals list has an entry you can read. Next: CI and scheduling.