Execution MCP

Connect the execution MCP to your coding assistant to work with your Millwork organization from the conversation. The assistant can connect a provider account, save a model, submit a run (one task you send to Millwork; the API calls it an execution), and read its result and receipt. It uses your organization API key. Configure your assistant to ask before each change or paid request; the stop happens in your assistant, not in Millwork. For questions about using Millwork, connect the documentation MCP, which searches and reads these docs.

Connect your assistant

Requires Node.js 20 or later and an organization API key. Add a local server to your assistant’s MCP settings:

{
  "mcpServers": {
    "millwork": {
      "command": "npx",
      "args": ["--yes", "@millwork/solver-mcp@0.2.16"],
      "env": {
        "SOLVERAPI_API_KEY": "<organization API key>",
        "SOLVERAPI_BASE_URL": "https://api.getmillwork.dev/v1"
      }
    }
  }
}

Enter your key in the assistant’s local settings, outside the conversation. Enable confirmation for write tools, then restart the MCP connection. If you do not have a key yet, create or save one first with Configure your API key, then paste it into these settings. Letting the CLI insert the key for you starts the CLI setup instead, and you continue in the terminal from there. The server runs locally over standard input and output. Its package is @millwork/solver-mcp on npm.

Check the connection

Ask your assistant:

Use Millwork to list my saved models.

The assistant lists your saved models or tells you that none are saved yet. This check reads your saved models without starting a run.

What it can do

The released 0.2.16 package exposes 28 tools, including eight for output checks. The installed tools/list is the exact inventory. Most tools call a REST endpoint; lifecycle tools also return a safe next action after inspecting the recorded operation. Tools that list your organization’s own items, such as saved models, output checks, and provider connections, return the newest first, as their REST endpoints do. A saved model is an option Millwork may run your task on; the API calls it an arm, which is why several tool names carry that word.

Tool	What it does	Read, or a write your host must confirm	REST endpoint
`solver_list_sources`	Lists the providers your organization can connect	Read only	`GET /v1/model-source-profiles`
`solver_start_source_handoff`	Starts the provider’s browser setup: approval or private key entry, according to its enabled method; credentials stay out of the conversation	Write; host must confirm	`POST /v1/source-credential-handoffs`
`solver_poll_source_handoff`	Checks whether that browser step is finished	Read only	`GET /v1/source-credential-handoffs/{id}`
`solver_create_source_connection`	Saves a provider connection from a finished secure setup; it starts disabled until tested	Write; host must confirm	`POST /v1/source-connections`
`solver_test_source_connection`	Tests a provider connection against the provider; a pass enables it	Write; host must confirm	`POST /v1/source-connections/{id}/test`
`solver_list_source_connections`	Lists your provider connections and their test state	Read only	`GET /v1/source-connections`
`solver_disconnect_source_connection` (from `0.2.2`)	Disconnects one provider connection and disables its saved models; requires the exact `connection_id` and a caller-owned `idempotency_key`	Destructive write; host must confirm the connection and affected saved models	`DELETE /v1/source-connections/{id}`
`solver_sync_source_deployments`	Refreshes the models a tested connection can reach	Write; host must confirm	`POST /v1/source-connections/{id}/deployments/sync`
`solver_list_model_deployments`	Lists the catalog models loaded from your connections	Read only	`GET /v1/model-deployments`
`solver_list_model_catalog` (from `0.2.3`)	Lists the models your organization can use, each with the exact registration settings to save it as a saved model	Read only	`GET /v1/model-catalog`
`solver_enable_model_arm`	Saves a catalog model as a saved model	Write; host must confirm	`POST /v1/arms`
`solver_register_arm`	Saves a model, an agent endpoint, or a skill as a saved model	Write; host must confirm	`POST /v1/arms`
`solver_list_arms`	Lists your saved models	Read only	`GET /v1/arms`
`solver_submit`	Submits a run; a live run has a platform fee, charged when Millwork accepts it	Write; host must confirm	`POST /v1/executions`
`solver_status`	Reads a run’s status	Read only	`GET /v1/executions/{id}`
`solver_cancel`	Cancels a run that has not finished; this cannot be undone	Write; host must confirm	`POST /v1/executions/{id}/cancel`
`solver_result`	Reads the result of a completed live run	Read only	`GET /v1/executions/{id}/result`
`solver_receipt`	Reads a run’s receipt, with model usage and the platform fee on separate lines; it never contains the prompt or the output	Read only	`GET /v1/receipts/{id}`
`solver_proposals`	Lists proposed changes to a saved skill (the API calls them repair proposals), or reads one	Read only	`GET /v1/proposals`, `GET /v1/proposals/{id}`
`solver_review_proposal`	Approves or rejects a proposed change; the decision is final	Write; host must confirm	`POST /v1/proposals/{id}/approve` or `/reject`
`solver_list_verifiers`	Lists saved output checks	Read only	`GET /v1/verifiers`
`solver_show_verifier`	Reads one output check	Read only	`GET /v1/verifiers/{id}`
`solver_connect_verifier`	Registers a public check or a protected endpoint shell; accepts no endpoint key	Write; host must confirm	`POST /v1/verifiers`
`solver_test_verifier`	Retests one saved check without starting a model run	Write; host must confirm	`POST /v1/verifiers/{id}/test`
`solver_start_verifier_connection`	Starts private key entry and returns an intended-person link	Write; host must confirm	`POST /v1/verifiers/{id}/connection-intents`
`solver_inspect_verifier_connection`	Reads the connection or an exact lifecycle operation	Read only	`GET /v1/verifiers/{id}/connection`
`solver_continue_verifier_connection`	Continues the saved private operation after key entry; accepts no key	Write; host must confirm	Protected lifecycle operation
`solver_disconnect_verifier_connection`	Stops Millwork using the connection; does not revoke the endpoint key	Destructive write; host must confirm separately	`POST /v1/verifiers/{id}/connection/revoke`

Reads need no confirmation. The 13 read-only tools change nothing, and the server may retry one when the network or Millwork fails. Writes need your confirmation. The server itself sends no confirmation flag; your assistant or its host enforces the stop, so configure it to confirm every tool that is not a read. Writes with a caller-owned request key can retry only that same request; other writes get one attempt. If a response is lost, have your assistant inspect the current state before you approve another attempt. The server reads your organization API key from its own environment, sends it only to Millwork as the bearer token, and never returns it in a tool result. Confirmation is a stop in the assistant, not a narrower key: your API key keeps its full permissions, so give the assistant only a key whose permissions you are willing to let it use.

Connect a provider with your assistant

Have the assistant list available providers before asking you to obtain a key. OpenRouter asks you to approve access in the browser; key-entry providers use Millwork’s private setup page. Keep provider credentials out of the conversation. The assistant may hand you the setup link or open it in your normal system browser; keep that link out of shared logs, evidence and support material. For the guided CLI handoff, follow Finish browser approval yourself. A REST handoff ID and a CLI application ID name different resources; use the continuation for the flow you started. After the browser step, the assistant checks its state, tests the connection and refreshes its models with your approval. You approve any paid run separately. If a run fails, inspect that run before repeating setup. From version 0.2.2, ask your assistant to disconnect a saved provider connection only after it names the exact connection and affected saved models. A disconnect requires the same request key (idempotency_key) and connection_id if its response is uncertain and you approve retrying it. It disables the Millwork connection and saved models; the provider key stays active, and calls already sent can still be billed. For 0.2.0, or to replace a key, follow the REST connection steps.

Connect an output check with your assistant

Inspect the installed MCP tools/list before choosing a connection path. The pinned 0.2.16 release includes solver_list_verifiers, solver_show_verifier, solver_connect_verifier, and solver_test_verifier. They can register and test a credential-less HTTPS endpoint without handwritten HTTP. For an older installation missing these tools, use the CLI continuation below, then pass its returned verifier_id into solver_submit. For a credential-less HTTPS endpoint:

millwork verifier connect --endpoint <https-url> --access public --name <name> --version <version> --connect-only --json

The generated REST reference owns operation fields. The verifier-dock contract owns the endpoint request and response. To scaffold and test the endpoint locally, use the installed CLI’s offline millwork verifier capabilities --json, then follow Recipe 0.

Connect, replace, or restore a protected output check

For a protected endpoint, first inspect whether the installed server exposes the four solver_*_verifier_connection lifecycle tools. When present, they start, inspect, continue, and disconnect the protected connection while key entry stays on Millwork’s private page. Otherwise use the private CLI flow in Connect an output check. Keep the key out of the conversation and every MCP input. To connect a protected check, or replace or restore its key, use this order with the same registered verifier_id:

With host confirmation, call solver_start_verifier_connection with the verifier_id, a supported stop_choice, and a request key (idempotency_key). Keep its intent_id and expires_at.
Give its continue_url only to the intended person. They enter the key on the private page. Do not ask them to paste the key into a conversation.
After private entry, with host confirmation, call solver_continue_verifier_connection with that verifier_id, operation_key: intent_id, intent_expires_at: expires_at, and a request key for this attempt. If the result is uncertain, inspect that same operation_key with solver_inspect_verifier_connection, then continue that operation until its read-backed state is done. An expired intent needs a new start; a failed test needs a corrected key or endpoint.

Disconnect a protected output check

Disconnect is a separate action. Name the affected check and obtain separate host confirmation before calling solver_disconnect_verifier_connection with a new operation_key, its request key, and confirm_disconnect: true. If its result is uncertain, inspect the same operation key before retrying. Disconnect stops Millwork using the key; removing it at your endpoint is a separate action. The tool table above identifies each tool’s authority. Connecting, replacing, or restoring never approves a paid run.

Use an output check on a run

To use a connected check, pass its verifier_id to solver_submit, as Run submission through the assistant describes. Connecting a check is not approval to run a task. If you omit verifier_id on solver_submit, Millwork uses the built-in output-presence baseline, which is not a check of whether the answer is correct.

Run submission through the assistant

A run needs a saved model, not only a catalog entry. If solver_list_arms returns none that match your choice, have the assistant save that model with solver_enable_model_arm first, copying the catalog entry’s registration settings unchanged; a submission with no eligible saved model fails. To keep the run on the model you chose, the assistant sets routing.required_arm_id to that saved model’s arm_id. solver_submit is the one tool that can cost money. Before a live call, have the assistant prepare the exact task, saved model, data classes, model budget, runtime limit, output check, available charge information, and request key. Approval in chat is not paid-run authority. If solver_submit returns host_approval_required, give the returned approval document only to the host administrator. Retry the unchanged request and request key only after the host approves it. Never create a new key to hide an unknown result. If the installed server does not support this flow, stop and report its installed version. Echo mode remains free and does not need this approval. With the installed schema, a call must carry:

a request key, supplied by the assistant as idempotency_key and sent in the Idempotency-Key header, so a retry does not start the work twice; the server rejects a call without one before it reaches Millwork;
the task and policy, the same shape as POST /v1/executions; Millwork keeps the saved models that fit your policy limits and picks one; and
the saved model as routing.required_arm_id when you chose one explicitly; and
optionally an output check, a check applied to the run’s output, as verifier_id. From version 0.2.2 this field is optional: leave it out and Millwork checks only that the run produced an output, which is not a check of whether the answer is correct. For a real check of the output, connect one with the installed @millwork/solver CLI (millwork verifier connect --endpoint <https-url> --access public --name <name> --version <version> --connect-only --json) and pass its id. Versions before 0.2.2 require the field.

What comes back is the run record: its execution_id and status. The assistant then follows it with solver_status, reads the output with solver_result when the run completes, and reads the receipt with solver_receipt. Every one of those is read only. A test run (the API calls it Echo) makes no model call and has no platform fee or model cost. When the installed solver_submit schema offers mode: "echo", use it for that free platform check. Otherwise use Make your first API call, then let the assistant follow it with the read-only tools. A live run is charged the platform fee when Millwork accepts it. If you omit verifier_id, the basic check confirms only that output exists; include your saved check when you need your own correctness rules. Read Model access and billing before approving a live run, and Errors and retries for what each error means.

Use a coding assistant

Give an assistant one page and a short set of rules so it works with you and never sees a secret.

Documentation MCP

Search and read these docs, or send documentation feedback you approve.

Get started

Provide models

Build

Build safely

SDK and MCP

Connect your assistant

Check the connection

What it can do

Connect a provider with your assistant

Connect an output check with your assistant

Connect, replace, or restore a protected output check

Disconnect a protected output check

Use an output check on a run

Run submission through the assistant

Use a coding assistant

Documentation MCP

​Connect your assistant

​Check the connection

​What it can do

​Connect a provider with your assistant

​Connect an output check with your assistant

​Connect, replace, or restore a protected output check

​Disconnect a protected output check

​Use an output check on a run

​Run submission through the assistant

Use a coding assistant

Documentation MCP

Connect your assistant

Check the connection

What it can do

Connect a provider with your assistant

Connect an output check with your assistant

Connect, replace, or restore a protected output check

Disconnect a protected output check

Use an output check on a run

Run submission through the assistant