Connect an MCP client

Connect your MCP client to /mcp, authenticate the intended Compute account, and verify the five customer work tools before using one. Your agent keeps its model, goal and final decisions; MCP exposes the current operations and the server checks every call against the authenticated account's scopes.

Connect and negotiate the protocol

The customer MCP endpoint is /mcp on the base server declared in the API description. It uses Streamable HTTP and accepts protocol revisions 2026-07-28 and 2025-06-18. The OpenAPI header schema specifies 2025-06-18; use that revision when following its request schema.

A 2025-06-18 connection follows initialize → response → notifications/initialized → tools/list. Keep the selected protocol revision with this remote connection; a different revision does not make the local stdio input schema part of the remote endpoint. A POST request uses JSON-RPC 2.0. The transport expects Content-Type: application/json and an Accept header that includes both application/json and text/event-stream. After initialization, carry the negotiated MCP-Protocol-Version on subsequent POST requests. GET and DELETE session operations are not supported on this endpoint. Browser origins are validated when present.

The local stdio client is a separate surface with a different input schema and lifecycle. Do not send its path-oriented local arguments to the remote /mcp endpoint.

Don't copy an MCP URL, account, or secret from an example. Use the base URL and credential issued for your account.

Authenticate the intended account

MCP authenticates through the same Compute bearer-key boundary as the REST work surface. The selected tool's scope is checked after its arguments are parsed. Any account_id nested in the arguments must remain pinned to the authenticated account.

Tool descriptions never grant authority. A model can't change its key scopes, choose another account, add an unregistered tool, or turn result text into an administrative action.

Verify exactly five customer work tools

There is no sixth customer work tool. CLI commands, local planning helpers, provider administration, account management, and finance operations are separate surfaces.

tools/list publishes strict input schemas. Bad arguments return bounded tool-execution feedback containing field paths and expected shapes, not the submitted values. An unknown tool is a protocol error.

The agent maps its task brief to one of these schemas and supplies the prepared source or evidence that the selected operation requires. MCP does not paste a natural-language brief into an arbitrary tool or turn a raw local path into an admitted input.

Quote, run, and read the result

The tools on this page describe the remote Compute contract. lithi.quote is a remote assessment or quote: it prices work and spends nothing by itself, but it still leaves your machine and needs your account. lithi.run and lithi.batch request approved execution: a real workflow against a real data scope, gated on the explicit approval your account policy requires. This guide does not enable execution by itself, and none of these tools is a local fixture. For local or synthetic checks, use one of the language-client examples instead.

Tool results contain structured content with a handle, digest, state, and an optional p_next_action. A refusal is also structured content and sets isError, so transport success isn't the same as work success.

The remote lithi.quote result is this projection only: use its handle, digest and state to track the quote. When an application needs the full signed terms, use the existing Core REST requestQuote path or the local Kit. If that authority is unavailable, stop; do not invent a quote-read endpoint or issue another quote merely to recover terms.

The remote lithi.batch result is also a batch handle, digest and state. Use the supported batch read to resolve its item jobs before calling lithi.status or lithi.result for those jobs. There is no additional MCP batch-status or batch-result tool.

A monthly impact report is separate from this work surface. It requires separate reporting permission and an approved reporting API or file path; it does not add a sixth MCP work tool. Use the monthly Compute impact report or the Impact Reports API when that access is granted.

For an end-user agent setup, continue with Use Compute with your AI. For raw tool schemas, use the Work API reference.

SDK helpers remain local application code

The five MCP work tools are the complete remote work surface. TypeScript and Python SDK helpers can prepare records, inspect result files or coordinate local steps around those calls, but they do not become additional MCP tools. A local helper cannot widen the authenticated account, approve a quote or turn a result projection into artifact bytes.

For a support-ticket preparation flow, read What leaves your machine before calling lithi.run or lithi.batch, then follow result verification and result delivery. The Kit helper reference separates MCP tools from SDK methods, local helpers and agent guidance.

See Kit contents for the supplied local modules and workflow guides.