Skip to content
intentdocs/ docs
Docs menu
CLI Reference · 4.8

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>]
OptionDefaultMeaning
-m, --mode <mode>allWhich tools to expose: core, standard or all
intentdocs mcp
intentdocs mcp --mode core

You 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:

ModeAdds
corelist_stories, mark_done, report_criteria, raise_blocker, mark_in_progress, get_status, add_note
standardcreate_story, get_context, log_decision, amend_decision, retract_decision
allanalyze_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-register

No 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]
OptionDefaultMeaning
--statusoffShow how the last CI run's results matched your saved tests, and change nothing
--newoffCreate a new CI key even if one exists
intentdocs ci
intentdocs ci --status
intentdocs ci --new

Needs 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:

  1. 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 --new to create one.

  2. The workflow. It detects your test runner: vitest or jest from package.json, pytest from pyproject.toml, pytest.ini or requirements.txt, and go from go.mod. When the repository is on GitHub (it has .github/workflows/, or its origin remote 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 to test-results.xml, and posts that file to intentdocs, even when tests fail.
    • If .github/workflows/intentdocs.yml already 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 curl command to run after your tests write JUnit XML.

  3. The secret. When it created a key and the GitHub CLI gh is installed and signed in, it runs gh secret set INTENTDOCS_CI_KEY. Otherwise it prints the key once, with instructions to add it as the INTENTDOCS_CI_KEY repository secret. Store it then; it is not shown again.

The test commands it uses:

RunnerCommand in the workflow
vitestnpx vitest run --reporter=junit --outputFile=test-results.xml
jestJEST_JUNIT_OUTPUT_NAME=test-results.xml npx jest --ci --reporters=default --reporters=jest-junit
pytestpytest --junitxml=test-results.xml
gogo 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, passing file and full_name exactly 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 --status prints a line per key that has received a report, for example Last report 2h ago: 41 of 44 results matched a saved test, 3 did not. Unmatched results are tests CI ran that no story records.