How Claude discovers and calls Reeve's tools over the unified /mcp surface, and how gating works.

The tools

You don't call these directly — you talk to Claude naturally and it calls them on your behalf. This page explains what's available and how Claude finds and uses it, so you know what to expect.

This describes the unified /mcp surface (recommended for new connections). If you're still on the legacy /mcp/claude connector, see the note in Connect Reeve to Claude — it exposes only chat, get_context, and resolve_gate, documented in the MCP Tools reference.

Two kinds of tools

chat is the brain — send it a natural-language request and Reeve's agent figures out what to do, drawing on your brand's voice, catalog, and connected platforms. Good for anything orchestrated or creative: drafting copy, generating ad concepts, multi-step campaign work.

Direct tools are fast, deterministic reads — list your CRM contacts, check an ad campaign's performance, look up your credit balance. Claude calls these directly instead of routing through chat when a request is a straightforward lookup.

How Claude discovers what's available

Because Reeve's tool catalog is large, Claude doesn't see every tool up front. It discovers what it needs in three steps:

get_context()                        → your orgs, brands, host_apps, and available `departments`
list_tools(department?)              → tool names + one-line descriptions, optionally narrowed to one department
describe_tools(names)                → full input schemas for up to 10 tools, right before calling them

Then it calls a tool one of two ways:

By name directly, for a curated set of high-traffic reads that are "promoted" to first-class tools (see below) — e.g. crm_list_contacts(...).
Through use(tool, args), for everything else in the catalog — Claude passes the tool name and a JSON args object matching the schema describe_tools returned.

You'll typically never see this happen — Claude runs get_context at the start of a session and calls list_tools/describe_tools on demand as your requests need tools it hasn't used yet.

Promoted tools: called by name

A curated subset of high-traffic read-only tools are promoted to first-class named tools, so you (or an MCP client's "always allow" setting) can scope trust to individual tools instead of one blanket grant on use. These are visible only for departments your connection has been granted:

Department	Promoted tools
`crm`	`crm_list_contacts`, `crm_list_stats`
`credits`	`credits_get_balance`, `credits_get_ledger`
`commerce`	`commerce_get_rate_card`
`connects`	`connects_list_connections`, `connects_list_capabilities`
`adbuyer`	`ads_list_providers`, `ads_list_campaigns`, `ads_list_insights`
`studio`	`video_list_presets`, `video_list_projects`, `video_get_renders`
`knowledge`	`knowledge_list_corpora`, `knowledge_list_ask`

Everything else Reeve exposes (CRM writes, comms, enrichment, database, maps, booking, and more) is still reachable through list_tools → describe_tools → use — it's just not promoted to a named tool yet. See the full schemas in the MCP Tools reference.

The brain tools

Four tools are always available, regardless of which departments your connection is granted:

chat

chat(message, thread_id?, host_app?, brand_id?)

Talk to your Reeve workspace. Pass the returned thread_id on follow-ups to keep one conversation going. brand_id (from get_context) scopes the conversation to a specific brand.

get_context

get_context()

Returns your org(s), user info, brand list, and the departments of tools available to this connection. Claude calls this first, every session.

reeve_howto

reeve_howto(task, host_app?)

Semantic help: describe a goal in plain language and get back guidance on which Reeve tools accomplish it, drawn from Reeve's own knowledge base. Returns an honest empty result (never a fabricated answer) when nothing matches.

resolve_gate

resolve_gate(gate_id, decision, thread_id?)

Approve or cancel a pending gated action — see Gating, below. decision is "approve" or "cancel". thread_id is only needed to resolve a gate that came back inside a chat reply; a gate returned directly by a tool call resolves without one.

Gating: writes require your approval

Reeve draws a hard line between reads and writes:

Reads — looking things up (contacts, campaigns, balances, renders, and so on) — dispatch immediately. No approval needed.
Writes and credit-spending actions — publishing, launching spend, creating records — never execute inline. The tool call instead returns:
```
{ "status": "pending_approval", "gate_id": "..." }
```
Claude surfaces the pending action and waits for you to explicitly confirm, then calls resolve_gate(gate_id, "approve") to actually run it — or resolve_gate(gate_id, "cancel") to drop it.

Approving a gate commits the action — for example, it may launch ad spend or publish content. Review the details Claude surfaces before confirming.

Credit-spending tools (renders, AI completions, and similar) currently gate the same way writes do, pending a finer-grained cost-threshold policy — so today, every non-read action asks for your approval rather than only the more expensive ones.

How it works together

You ask Claude something naturally
Claude calls get_context (once per session) to see what's available
For a read, Claude calls the tool directly (by name if promoted, or via list_tools/describe_tools/use otherwise) and returns the result
For a write, Reeve returns pending_approval — Claude explains what it's about to do and waits for you to say yes
You confirm → Claude calls resolve_gate(gate_id, "approve") → Reeve completes the action
For orchestrated or creative work, Claude uses chat instead of a direct tool, reusing thread_id across a conversation

The tools

On this page