> ## Documentation Index > Fetch the complete documentation index at: https://docs.getmillwork.dev/llms.txt > Use this file to discover all available pages before exploring further. # Execution MCP > Connect a coding assistant to your Millwork organization to manage models, submit runs, and read results. 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](/mcp/documentation), 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: ```json theme={null} { "mcpServers": { "millwork": { "command": "npx", "args": ["--yes", "@millwork/solver-mcp@0.1.1"], "env": { "SOLVERAPI_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. Ask the assistant to list the models you have saved to check the connection without starting a run. The server runs locally over standard input and output. Its package is [@millwork/solver-mcp on npm](https://www.npmjs.com/package/@millwork/solver-mcp). ## What it can do Each tool maps to one REST endpoint (two for the proposal tools), so the assistant sees exactly what a direct API caller sees. 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 a secure setup, a one-time browser step where you enter a provider key yourself; the assistant gets a link, never the key | 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_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_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; 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` | **Reads need no confirmation.** The nine 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. The server retries a write on its own only for `solver_submit`, and only with the same request key and the same request, so a retry cannot start a second run. Any other write that loses its response is a failure, and the next call is a new decision for you, not an automatic replay. 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. ## Run submission through the assistant `solver_submit` is the one tool that can cost money, so your assistant must ask first every time. In 0.1.0 and 0.1.1, 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 * an **output check**, a check applied to the run's output, as `verifier_id`. Both published versions require this field. If you have not created an output check, create one with `POST /v1/verifiers` before the first submission. 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** (a run the API calls Echo, which calls no model and has no platform fee and no model cost) takes no output check, and 0.1.0 and 0.1.1 both require `verifier_id` on every submission, so neither can submit a test run. Make your first test run with curl ([Make your first API call](/get-started/first-api-call)), then let the assistant follow it with the read-only tools. A live run submitted through a published version needs an output check and is charged the platform fee when Millwork accepts it. Read [Model access and billing](/concepts/access) before approving a live run, and [Errors and retries](/guides/errors-and-retries) for what each error means. Give an assistant one page and a short set of rules so it works with you and never sees a secret. The live, read-only server that searches and reads these docs.