Let a coding agent work with {{brand}}: kamocore mcp

kamocore mcp gives a coding agent on your machine {{brand}}'s tools: read projects, runs and failures, run a suite you named, and - only when you allow writes - file a bug with its evidence.

In short

kamocore mcp is a command of the {{brand}} CLI that serves {{brand}} to a coding agent as tools, over the Model Context Protocol. The agent can read projects, runs and failures, run a suite you named and - only if you allow writes - file a bug. It starts read-only, and only you widen it, on the command line.

Before you start

• Who: you make the access token with only the scopes the agent needs. Writes also need your own right to change the project and the board.
• Plan: every plan. The agent can do nothing the token cannot.
• First: install the CLI as in /help/api-testing/run-in-a-pipeline.

Steps

1. Install the CLI as in /help/api-testing/run-in-a-pipeline.
2. Create an access token in "Settings", under "Access tokens", with only the scopes the agent needs - ApiTester:read to read; ApiTester:write and Boards:write only if it may change something.
3. Add {{brand}} to the agent host's list of tool servers. Use the command kamocore with the arguments mcp and the switches you choose, and set KAMOCORE_TOKEN in the environment the host starts it with.
4. Keep the token in the host's secret store or its environment - never among the arguments, and never in a file you commit.

Result: the agent's host starts the command and talks to it; you never type into it. kamocore mcp --help lists every switch.

What you allow

--writes-per-hour caps the changes an hour (60 unless you say otherwise), and --run-timeout caps how long a run may take.

Good to know

• No argument the agent sends can change what the command allows.
• The agent can do nothing the token cannot: no AI, no Jobs, no members, no billing and no sharing.
• Text in your workspace - a card title, a step's name, an answer from your API - could try to steer the agent. That is why it reads only unless you allow writes, runs nothing unless you name hosts, and stays within the token's scopes.
• A local run never prints a step or a secret, and a check cannot read a secret back out of an answer.
• A recorded run turns the suite and its requests red or green on boards, Home and Can we ship?, as any run does.
• A coding agent building one card uses the credential that card gives it instead of an access token, and then sees only that card's tools. See /help/boards/coding-agent-on-a-card.
• To test an MCP server you build yourself - its tools, their safety and what changed - see /help/api-testing/mcp-servers.

If something goes wrong

• The agent cannot see a write tool: start the command with --allow-writes.
• A run does not start: name the hosts with --allow-hosts and the suite or project; give secrets with --secret-host.
• The token is refused: check its scopes in Settings, under Access tokens.
• "These checks were written from a design and are locked for agents and tokens. A person can change them in {{brand}}.": ask a person to change them.

Related

• /help/api-testing/run-in-a-pipeline
• /help/settings/access-tokens
• /help/api-testing/mcp-servers