# MCP > Connect an MCP client, such as Claude or another agent, to your organization's records and operations. A connected client can find, describe, and run the same Queries and Actions as the [REST API](/docs/developers/api). Every tool call runs as the client's credential, through the same permissions, policies, and rules as a person in the web app. ## Endpoint | Setting | Value | | --------- | ------------------------------------------ | | URL | `https:///api/mcp` | | Transport | Streamable HTTP | | Auth | `Authorization: Bearer cos_…` | In the web app, **Settings › MCP** shows your exact endpoint. ## Connect a client Connect with a service account's API key, sent in the `Authorization` header. An administrator creates the service account and issues its key in **Settings › Service accounts**. See [Authentication](/docs/developers/api#authentication) for the steps. For example, with Claude Code: ```bash claude mcp add --transport http continual "$CONTINUAL_URL/api/mcp" \ --header "Authorization: Bearer $CONTINUAL_API_KEY" ``` The key decides everything the client can do. It works only in its own organization, and its account's roles decide what the client can read and change. Give each agent its own service account, so its changes are attributed to it and you can revoke its key on its own. Continual does not run an OAuth flow for MCP. Use a client that lets you set the `Authorization` header on a remote MCP server. ## Your organization's API The tools come from your organization's model: the operations of the apps it has installed, including any apps of its own. Operations outside any organization, such as creating one, are left out. When the organization installs or changes an app, a client that listens for changes is told to list the tools again. To browse the same model yourself, open **Settings › Domain model** in the web app. ## Tools Every Query and Action is a typed tool, named by its operation ID with `_` for `.`, such as `sales_deals_list` or `finance_invoices_issue`. Each carries its input and output schemas. A client with tool search loads a tool's schema only when its agent needs it. To serve only some apps' operations, name them: ```text https:///api/mcp?apps=sales,finance ``` The cross-type operations, such as `records_search`, stay. ### The discovery set A client that loads every tool into each request can connect for six tools instead. The agent finds the operation it needs and loads only that operation's schema: ```text https:///api/mcp?tools=discovery ``` | Tool | What it does | | ----------------------- | -------------------------------------------------------------------------------------- | | `model_operations_list` | Finds up to ten operations by keywords, such as "list deals" | | `model_operations_get` | Returns one operation's input schema, and for an Action its consequence and transition | | `run_operation` | Runs one operation with its input, and returns its output or the error to fix | | `model_objects_get` | Returns an Object's fields, relations, and operations, such as `sales.deal` | | `records_search` | Finds records by text across types | | `records_batchGet` | Reads records by ID | Each but `run_operation` is the same tool as the typed one of that name. A `run_operation` call names an operation ID and its input: ```json { "name": "run_operation", "arguments": { "operation": "sales.deals.list", "input": { "pageSize": 20 } } } ``` When a result names records, the tool also returns links that open them in the web app, so the agent can hand a person a link. ### Tool annotations Tools carry MCP annotations, so a client can tell what each one does: - Queries are read-only. An Action whose consequence is a delete or a commit, such as issuing an invoice, is marked destructive. - `run_operation` is marked destructive, because it can run any Action. Finding an operation does not grant it. Every call checks the caller's permissions and the organization's policies when it runs. ## Policies and approvals A service account of kind `agent` counts as an agent for policies. The default policy, `agentsAsk`, makes an agent's commits and deletions wait for a person's yes. When a policy holds a call, the tool returns an error with the reason `APPROVAL_REQUIRED`. The agent can then run `approvals.request` to ask a person, and approving runs the call. A service account of kind `integration` is not an agent, so that policy does not hold its calls. See [Approvals](/docs/concepts/approvals). An MCP connection runs only the calls its client makes. It does not schedule an agent or run work in the background. Your agent runtime owns execution and retries. Authentication, routes, paging, and errors. How a person approves an agent's held call.