# MCP setup

Section: Agent access
Source: https://platform.metix.ai/docs/mcp
Every page in one file: https://platform.metix.ai/llms-full.txt

Point an MCP-compatible client at the same three datasets, under the same key, the same limits, and the same Credit rules as REST.

## Transports

| Transport | URL | Protocol |
| --- | --- | --- |
| Streamable HTTP | https://mira-api.metix.ai/mcp | MCP 2025-03-26 |
| SSE (legacy) | https://mira-api.metix.ai/sse | MCP 2024-11-05 |

> **Schema verification boundary**
>
> Capability-specific MCP tool names are intentionally not listed here. Verify the running schema before documenting or calling a tool name; use the REST reference when the exact name is not verified.

## What an agent can reach

The MCP surface is the public REST surface and nothing more. An agent can search people, jobs, and companies, and read the records behind the IDs it gets back.

| Dataset | Search | Detail |
| --- | --- | --- |
| People | POST /v1/people/query, POST /v1/people-search | POST /entity/v1/profiles/detail-by-id |
| Jobs | POST /v1/jobs/query | POST /entity/v1/jobs/detail-by-id |
| Companies | POST /v1/companies/query | POST /entity/v1/companies/detail-by-id |

The two-step flow does not go away under MCP. A search still returns encrypted string IDs, so an agent that stops after the search has ID strings and no facts. Tell it to fetch details, in batches of up to 100, before it tries to reason about a result set. The [Query Spec](https://platform.metix.ai/docs/api/query-spec.md) is worth putting in the agent's context: an agent that knows `all`, `any`, `not` and one operator per leaf writes far better queries than one guessing at filter names.

## Claude Code

```bash
claude mcp add --scope user --transport http \
  metix \
  https://mira-api.metix.ai/mcp \
  --header "Authorization: Bearer $METIX_KEY"
```

After the client reads the live schema, use the relevant capability. For deterministic integration work, follow the exact endpoint pages in the [REST API reference](https://platform.metix.ai/docs/api.md).

## Codex

The same server, registered with Codex. The key is read from your environment at call time rather than written into the config file.

```bash
codex mcp add metix \
  --url https://mira-api.metix.ai/mcp \
  --bearer-token-env-var METIX_KEY
```

`codex mcp get metix` should report `transport: streamable_http`. Registering here as well as in Claude Code is a second client against one server, not a second subscription.

MCP is not the only way in on Codex. The four [skills](https://platform.metix.ai/docs/skills.md) install for Codex through the shared `.agents/skills` directory, and the two work well together: the skills carry the field vocabulary and the two-step shape, and MCP carries the calls. Registering the server also sidesteps Codex’s command sandbox, which has no network access by default and so blocks a raw `curl` until you approve it.

## Any other client

Both commands above are wrappers over one JSON-RPC handshake. A client with no `mcp add` of its own needs the same three facts: this URL, the streamable HTTP transport, and an `Authorization: Bearer` header.

```bash
curl -X POST "https://mira-api.metix.ai/mcp" \
  -H "Authorization: Bearer $METIX_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-03-26",
      "capabilities": {},
      "clientInfo": { "name": "my-agent", "version": "1.0" }
    }
  }'
```

## Shared behavior

- Authentication uses the same API key and the same server-side policy.
- Credit settlement follows the same returned-result rules as REST.
- Search size and detail batch limits are the same: up to 10,000 IDs per page (100 if you omit size), 100 IDs per detail call.
- Agent responses should not expose secrets or raw provider payloads.