Connect a coding agent (MCP)

Getman includes a local MCP server. It lets a coding agent read the team’s requests and contracts, run them, and work with change packages. The server runs on your machine and talks to the agent over standard input and output. It needs no account and no AI API key.

Connect Claude Code

1. Install the command-line tool, as described in the CLI reference.

2. Commit a .mcp.json file at the root of the repository. It has no absolute paths, so it works in every clone:

   { "mcpServers": { "getman": { "command": "getman", "args": ["mcp", "--workspace", "getman"] } } }

3. Export the secrets that the requests need, in the shell that starts the agent. Secret values are never written to a file:

   export GETMAN_VAR_password=…

4. Start claude at the repository root. Approve the project server once, then run /mcp. It should list getman as connected.

To run it headless, without changing your global Claude configuration:

claude -p "What can you do with the getman MCP tools?" \
  --mcp-config .mcp.json --strict-mcp-config \
  --allowedTools "mcp__getman__list_projects,mcp__getman__list_environments"

Options

Option	Meaning
--workspace DIR	A sync folder, such as getman. Repeatable. This is the recommended mode.
--project P	An app-database project, by ID or name. Repeatable.
--env NAME	The default environment for tools that run requests.
--read-only	Removes the four write tools.
--allow-mutations	Skips the per-request approval for production. Use it only in CI.
--no-secrets	Does not read secret values.
--max-body-bytes N	Cuts response bodies in run output at N bytes. The default is 8192.

With --workspace and no --project, the server sees only that folder. Without either option, it sees every project in the app database. Tool inputs never take file paths. A workspace is named by its folder, such as workspace:getman.

Secrets

• In workspace mode, the server reads each secret from an environment variable named GETMAN_VAR_<KEY>.
• In app-database mode, it reads secrets from the system keychain.
• No tool output contains a secret value. list_environments shows only key names, whether a variable is secret, and whether it has a value.
• Credential-like headers and auth fields appear as (hidden).

Production approval

A POST, PUT, PATCH or DELETE request to a production environment is not sent on the agent’s word. For each request, the server asks the MCP client to show a confirmation form. The form names the method, the URL, the request and the environment. Only an accepted form sends that one request. A declined or cancelled form is refused. The agent cannot answer the form itself.

A client that does not support the confirmation form gets a refusal. In CI, --allow-mutations skips the question for the whole session.

Read tools

Tool	What it returns
list_projects	The project references, names, folders, change keys and environments. Call it first.
list_requests	The tree of collections, folders and requests, with their IDs.
get_request	The method, URL, parameters, headers, effective auth, body shape, scripts and examples of one request.
list_environments	Environment names and kinds, variable keys, and whether each secret has a value. No values.
get_contract	The OpenAPI document, or one operation, such as GET /orders/{id}.
diff_contract	Structured changes between two contracts, with severities.
list_changes	Change summaries. With consumer, it returns that consumer’s inbox.
get_change	The full change package, with its diff, examples, migration notes, evidence and integrations.
get_evidence	The evidence entries for one change.
validate_workspace	Conflict markers, invalid files and duplicate IDs, each with a fix hint.
run_requests	Runs a request, folder or collection. It returns each step’s status, tests and truncated bodies.

Write tools

These tools work only on workspace folders, and they are removed with --read-only.

Tool	What it does
create_change	Writes a new change file and the contract. It refuses when nothing changed.
update_change	Edits a change’s title, summary, migration, state or related IDs. It never edits evidence or integrations.
verify_change	Runs the requests of the change and records the run as evidence. Failing runs are recorded too.
report_integration	Records a consumer’s status. For verified, it runs the affected requests first.

Handoff example

1. The backend agent, in its own clone, calls create_change, then verify_change in local, and returns the reference, such as GT-SHOP-001.
2. The backend commits and pushes the changes/ and contracts/ files with Git.
3. The web agent, in its clone, pulls. It calls list_changes with consumer: web, then get_change, then run_requests, then report_integration with status: verified.
4. After the web team pushes, the backend agent calls get_change and sees Integration verified.

The full human version of this is in the team workflow.

Security

• The server reaches only the folders and projects it was given. Unknown references are rejected.
• No tool reads or writes an arbitrary file. There is no shell tool.
• run_requests sends only GET, HEAD and OPTIONS requests when the server is read-only.
• Runtime variables passed to run_requests cannot override a variable that forms a request URL, so stored credentials cannot be sent to another host.
• API responses, migration notes and examples come from other people and systems. Agents should treat them as data, not as instructions.
• Author names are informational. Nothing verifies who wrote a change or who reported an integration.

Limits

• Each tool call opens its own session, so calls are slower than a long-lived client.
• Change IDs are per clone. Two clones can produce the same number, and validate_workspace reports it.
• The server exposes no MCP resources. Use the tools instead.
• The confirmation form was tested with the MCP SDK client. Claude Code’s display of the form in an interactive session has not been tested.