Integrations
Run the local MCP server, register it with OpenClaw, and report test results from CI to each story.
These commands connect intentdocs to the tools around your code: your coding agent through MCP, OpenClaw, and your CI pipeline. All of them need a connected checkout.
intentdocs mcp
Runs the local MCP server over stdio, so an MCP client can read and update your story map.
intentdocs mcp [--mode <mode>]| Option | Default | Meaning |
|---|---|---|
-m, --mode <mode> | all | Which tools to expose: core, standard or all |
intentdocs mcp
intentdocs mcp --mode coreYou do not usually run this by hand. Your MCP client starts it. The server finds .intent/config.json from the directory it starts in, so the client must start it inside the connected repository, and it calls the story map as the user logged in on that machine.
Each mode includes the tools of the one before it:
| Mode | Adds |
|---|---|
core | list_stories, mark_done, report_criteria, raise_blocker, mark_in_progress, get_status, add_note |
standard | create_story, get_context, log_decision, amend_decision, retract_decision |
all | analyze_complexity, research, import_prd |
Resources are available in every mode. A smaller mode keeps the tool list in your agent's context short. A call to a tool outside the current mode returns a message naming the mode that has it. An unknown --mode value runs as all.
To register the server with a client, start it with npx intentdocs mcp. intentdocs setup adds it to Claude Code for you, in the project's .mcp.json, and prints this block for Cursor:
{
"mcpServers": {
"intentdocs": {
"command": "npx",
"args": ["intentdocs", "mcp"],
"cwd": "/path/to/your/repo"
}
}
}Note: This local server is separate from the hosted MCP server at intentdocs.com, and their tool sets differ. For every tool and resource, see Tools and resources.
intentdocs openclaw-register
Registers the local MCP server with OpenClaw, so coding agents it spawns from this project can use your story map.
intentdocs openclaw-registerNo arguments or options. It runs:
openclaw mcp set intentdocs '{"command":"npx","args":["intentdocs","mcp"],"cwd":"/path/to/your/repo"}'with the current directory as cwd. Run it again from each project you want registered.
It exits 1 when the directory is not connected, or when the openclaw command fails. In that case it prints the command so you can run it yourself.
intentdocs ci
Sets up CI to report each test's result to its story: it creates a CI key, adds a workflow, and stores the key as a repository secret.
intentdocs ci [options]| Option | Default | Meaning |
|---|---|---|
--status | off | Show how the last CI run's results matched your saved tests, and change nothing |
--new | off | Create a new CI key even if one exists |
intentdocs ci
intentdocs ci --status
intentdocs ci --newNeeds a valid login. Creating a CI key is a project owner action; for anyone else, key creation fails with a message and the rest of the setup continues.
What it does:
-
The key. If the project has no active CI key, it creates one. If it has one, the existing key's value cannot be shown again, so it asks whether to create a new one. Without a terminal to answer, it keeps the existing key and continues; pass
--newto create one. -
The workflow. It detects your test runner:
vitestorjestfrompackage.json,pytestfrompyproject.toml,pytest.iniorrequirements.txt, andgofromgo.mod. When the repository is on GitHub (it has.github/workflows/, or itsoriginremote is on github.com):- With a known runner, it writes
.github/workflows/intentdocs.yml. The workflow runs on push and pull request, runs your tests with JUnit output totest-results.xml, and posts that file to intentdocs, even when tests fail. - If
.github/workflows/intentdocs.ymlalready exists, it leaves it alone. - With an unknown runner, it prints the report step to add after your own test step.
For other CI systems, it prints the
curlcommand to run after your tests write JUnit XML. - With a known runner, it writes
-
The secret. When it created a key and the GitHub CLI
ghis installed and signed in, it runsgh secret set INTENTDOCS_CI_KEY. Otherwise it prints the key once, with instructions to add it as theINTENTDOCS_CI_KEYrepository secret. Store it then; it is not shown again.
The test commands it uses:
| Runner | Command in the workflow |
|---|---|
vitest | npx vitest run --reporter=junit --outputFile=test-results.xml |
jest | JEST_JUNIT_OUTPUT_NAME=test-results.xml npx jest --ci --reporters=default --reporters=jest-junit |
pytest | pytest --junitxml=test-results.xml |
go | go test ./... -v 2>&1 | go-junit-report > test-results.xml |
Read the generated workflow before you commit it. It installs dependencies with npm ci, pip install -r requirements.txt or the Go toolchain; the jest command needs jest-junit in your dev dependencies.
Behaviour to know:
- A result reaches a story only when it matches a saved test by file and full test name. Have your agent save each test with
save_tests, passingfileandfull_nameexactly as your test runner reports them. - Results from the project's default branch are applied. Results from other branches are accepted and ignored.
intentdocs ci --statusprints a line per key that has received a report, for exampleLast report 2h ago: 41 of 44 results matched a saved test, 3 did not.Unmatched results are tests CI ran that no story records.