HTTP or MCP — same catalog, pick your transport

Reeve exposes one underlying catalog of operations — CRM, credits, commerce, connects, ads, video, knowledge, and more — over two transports. They aren't two separate integrations to choose between once and commit to; pick whichever fits the calling context, per call if you like.

One catalog, two transports

The API reference (REST/OpenAPI) and the /mcp MCP server are generated from the same source: the public, host-key-consumable catalog defined in the Reeve backend (api/openapi_public.py's per-product prefixes). Reeve's MCP tool manifest is built directly from that catalog's OpenAPI operations, curated per-substrate (renamed, described, gate-classified) rather than hand-duplicated — so a tool you can call over MCP and the REST endpoint it wraps never drift into two different shapes.

                    ┌────────────────────────┐
                    │   public catalog        │
                    │ (per-product prefixes)  │
                    └───────────┬─────────────┘
                                │ generated from
              ┌─────────────────┴─────────────────┐
              ▼                                     ▼
   REST: https://api.meetreeve.com          MCP: https://api.meetreeve.com/mcp/
   /api/crm/v1, /api/ads/v1, ...             list_tools → describe_tools → use
                                              (+ promoted first-class tools)

Two auth lanes, two shapes

Both transports authenticate the same two ways Reeve authenticates everywhere — a host-app key or a user's OAuth session — but the two lanes render the catalog differently on MCP:

See Authentication for the host-key model, and Use Reeve in Claude for the OAuth connect flow.

When to pick which

Call the REST API directly when:

• You're writing a backend integration, script, or scheduled job — no LLM in the loop.
• You want the smallest possible request/response overhead for a known, fixed set of calls.
• You need an operation that hasn't been promoted to a named MCP tool yet — every catalog operation is reachable over REST immediately.

Connect over MCP when:

• An LLM agent (Claude or another MCP client) needs to decide which Reeve operation to call based on a natural-language request.
• You want Reeve's built-in gating — writes and credit-spending calls return pending_approval instead of executing inline, so a human confirms before anything commits. REST callers must implement their own approval step; MCP callers get it from the platform.
• You're a per-user connector (claude.ai, Claude Desktop, Claude Code) where the OAuth progressive surface keeps the advertised tool list small regardless of how large the catalog grows.

Gating is an MCP-native concept

The REST API has no separate "propose, then approve" step — a request that's allowed either executes or is rejected. MCP's gating (pending_approval + gate_id, resolved via resolve_gate) exists because an MCP client is often acting on a human's behalf without the human directly typing the request — so Reeve inserts an explicit confirmation point for writes and credit-spending actions. See Gating: writes require your approval for the full mechanics.

Machine-readable references

• REST: the full OpenAPI spec at https://api.meetreeve.com/openapi/public/v1.json (or per-product, e.g. crm-v1.json)
• MCP: the live tools/list response from https://api.meetreeve.com/mcp/, documented in MCP Tools