The complete MCP tools reference for your CRM

Tools, resources and prompts: three different things

An MCP tool is a function an AI assistant calls to do something in your CRM: it takes arguments, performs an action, and returns a result. An MCP resource is a read-only feed addressed by a URI that the assistant loads into its context without choosing any arguments at all. An MCP prompt is a parameterized template the server hands the client, so a person can pick a named workflow from a menu instead of describing it from scratch every time. Those three sentences are the whole mental model, and almost every confusion about the Model Context Protocol dissolves once they are separated.

The practical difference is who decides. A tool call is the assistant deciding: it looked at your request, picked crm_search_contacts, invented a query string, and now owns the consequences of that choice. A resource read is the server deciding: crm://tasks/today means one specific thing and returns the same shape every time, so there is no argument for the model to get wrong. A prompt is you deciding: you clicked daily-briefing in your client and the server supplied the wording.

That distinction has real consequences for cost and reliability. Tools are expressive and therefore risky, because an assistant that misunderstands the question makes a wrong call rather than no call. Resources are narrow and therefore safe, and they are the cheapest way to give an assistant a great deal of accurate context in a single request. Prompts are how you stop re-typing the same three paragraphs every Monday morning.

CRM Solid publishes 62 tools, 21 resources and 15 prompts on one endpoint. Of the tools, 37 are annotated read-only and 25 are annotated as writes. Everything below is the complete catalogue, grouped so that the groups match the way you would actually hand out access. If you want the protocol-level picture of how the server itself works, that lives on the MCP server overview; if you want the setup steps for a specific client, those live on connect Claude to your CRM.

How to read this reference

Every tool in this reference carries four things: the exact name your assistant will call, one plain sentence on what it does, the single scope the call requires, and whether it reads or writes. Those four columns are the entire contract. There is no hidden fifth condition, no per-tool pricing tier and no separate permission model layered on top of scopes.

Names are exact and case-sensitive. Every tool is prefixed crm_, and the rest of the name reads as a verb plus a noun: crm_list_deals, crm_send_social_message, crm_set_lead_score. If a name in your client does not appear on this page, it is not part of this server. The server itself is always the final authority: a tools/list call returns the live catalogue with the input schema for each tool, which is what your client reads at connection time.

curl -sS https://api.crmsolid.com/mcp \
  -H "Authorization: Bearer csk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Scopes are the second column that matters. Each tool declares exactly one required scope, written as an area and a verb joined by a colon: contacts:read, deals:write, telegram:send. The ordering is deliberate and worth memorizing, because writing it the other way round is the single most common mistake people make when configuring a key. There is no read:contacts; there is only contacts:read.

Scopes are attached to the API key, not to the assistant, not to the session and not to the individual call. You mint a key in the panel, tick the scopes that key is allowed to use, and hand the key to one client. Two assistants with different jobs should hold two different keys, because that is the only way their permissions can differ.

When a call needs a scope the key does not hold, the server answers with JSON-RPC error code -32002 and names the missing scope in the error data. It does not fail generically and it does not silently return an empty result, both of which are far worse failure modes for an AI agent that will otherwise conclude you have no deals.

{
  "jsonrpc": "2.0",
  "id": 7,
  "error": {
    "code": -32002,
    "message": "...",
    "data": {
      "requiredScope": "deals:write",
      "granted": ["contacts:read", "deals:read"]
    }
  }
}

That shape makes the fix mechanical. Read requiredScope from the error, compare it to granted, and decide whether the assistant should have it. Frequently the answer is no, and the right response is to rephrase the request rather than widen the key. An assistant that keeps asking for webhooks:write is telling you something about how it interpreted your instruction.

The third column is the read or write annotation. It comes from the tool definition itself, so any MCP client that shows a confirmation dialog before write operations gets that signal from the server rather than from a guess about the name. One tool is annotated destructive on top of being a write: crm_delete_webhook. One tool is annotated as a write even though it changes nothing in your CRM: crm_run_agent, because each run spends AI credits.

Two practical notes before the catalogue. First, MCP responses are camelCase, which differs from the REST v1 API where fields are PascalCase, so code that consumes both needs to know which surface it is talking to. Second, the MCP server is a Business plan feature: a valid key on a lower plan is refused with HTTP 402 rather than a scope error, which is a different problem with a different fix. Pricing details are on the pricing page.

Contacts and CRM depth (11 tools)

Eleven tools cover the contact record itself and the four things layered on top of it: tags, lead score, ownership and the activity timeline. Four of them read and seven of them write, which makes this the single largest write surface in the catalogue and the group most worth thinking about before you hand out a key.

The split matters because the read half is harmless and the write half is not. An assistant holding only contacts:read can answer any question about who a person is and what was said to them. Add contacts:write and the same assistant can retag your database, reassign owners and overwrite lead scores. Those are recoverable actions, but recovering them by hand across a few hundred contacts is a bad afternoon.

What you would actually ask for

The natural-language shape here is a question about a person, not a question about a table. You name somebody and the assistant works out that it needs to search first, open the record second and read the timeline third. Tagging requests are the other common shape, and they are the reason the tag dictionary is a separate read tool: an assistant that cannot list your tags will invent one, and an invented tag name gets rejected rather than created.

• "Who is Selin Kaya, what have we talked about, and has anyone on the team been assigned to her?"
• "Tag every contact I spoke to this week about the enterprise plan with the enterprise-interest tag, and tell me first which tags already exist."

Two rules save you from surprises. First, crm_tag_contact never creates a tag, so a workflow that invents tag names has to call crm_create_tag before it. Second, the notes field is a fixed 500 characters and older text falls off the front, so treat notes as a rolling scratchpad and put durable facts in tags, score or a deal.

Conversations and messaging (5 tools)

Five tools cover the one-to-one messaging history stored in the CRM and the two direct sends that reach a person on Telegram or X. Three read, two write, and the two writes are the ones that put words in front of a human being, so they sit behind their own scopes rather than sharing a general write scope.

The separation is deliberate. Reading conversation history needs contacts:read, the same scope that reads the contact record, because a message thread is part of the contact. Sending needs telegram:send or twitter:send, one scope per channel, so you can build an assistant that reads everything and sends on exactly one network.

What you would actually ask for

Almost every messaging request starts as a triage question and ends as a drafting question. You want to know who is waiting, then you want the reply written, and only sometimes do you want it sent. Because the two send tools are separately scoped, you can leave the last step to yourself for weeks and still get the value: the assistant reads, ranks and drafts, and you paste. When you are ready to close the loop, add one send scope, not both.

• "Show me everyone who messaged in the last two days without a reply from us, ranked by how long they have been waiting."
• "Read my whole thread with this contact and draft a short Telegram follow-up that answers the pricing question they asked in March."

Telegram sends are asynchronous. crm_send_telegram_message returns once the job is queued, and the jobs tools further down this page are how you confirm the message actually left. X direct messages go out synchronously, so a failure surfaces in the tool result itself.

Email inbox (4 tools)

Four tools cover the shared email inbox, and none of them sends mail. Two read threads, two set workflow state, and every one of them is explicitly non-sending. That is the whole design: an assistant can read the mailbox, summarize a thread, close it, hand it to a colleague, and still be structurally incapable of emailing a customer.

The read tools also carry work that has already been done for you. A thread returned by crm_get_email_thread includes any AI summary and lead score computed when the mail arrived, so an assistant asking for context does not have to re-read forty messages to rank a lead.

What you would actually ask for

Email requests are usually about the queue rather than a single message. People ask what is still open, who has been ignored longest, and which threads can be closed because the customer already got an answer somewhere else. The assignment tool turns that into something useful for a team: a morning pass that reads every open thread, decides who owns it and files it, without ever writing a word to a customer.

• "Summarize every open email thread from the last week, say what the customer is actually asking for, and flag the three that look most likely to churn."
• "Close the threads where the customer already replied thank you, and assign anything mentioning invoices to the finance owner."

email:write governs status and assignment only. The advanced email:send scope exists and is left unchecked by default when you mint a key, so a routine inbox assistant never gets accidental sending rights.

Deals (4 tools)

Four tools cover the sales pipeline: two read the deal list and one deal in detail, two create a deal and move it between stages. This is the clearest example of the safe-write boundary on the whole surface, because one specific transition is missing on purpose.

crm_update_deal_stage accepts lead, qualified, proposal, negotiation and lost. It does not accept won. Marking a deal won books an income entry in the ledger, and booking revenue is a decision a person makes in the panel, not something an assistant does because a conversation sounded positive. Creating a deal already closed is refused for the same reason.

What you would actually ask for

Pipeline questions are forecasting questions. You want the shape of the funnel, the deals that have gone quiet, and the one action that would move the biggest number. Because deal reads are cheap and deal writes are narrow, this is a good group to grant in full: an assistant with deals:read and deals:write can keep the board honest all week and still cannot invent revenue.

• "What is in my pipeline right now, grouped by stage, and which three deals have had no activity in two weeks?"
• "Create a deal for the agency I spoke to yesterday at fifteen thousand in the qualified stage, and move the stalled one to lost with a note explaining why."

Tasks (3 tools)

Three tools cover to-dos and reminders: one lists them, one creates them, one changes their status. Tasks are the cheapest place in the CRM for an assistant to write, because a wrong task costs you five seconds to delete and a wrong message costs you a customer.

That makes tasks:write the first write scope worth granting when you are still nervous about giving an assistant any write access at all. It gives you a real feedback loop: you can watch what the assistant decided to create, judge whether its reasoning was sound, and decide from evidence whether to widen the key.

What you would actually ask for

The useful pattern is turning a conversation into commitments. An assistant that has just read a thread knows what you promised, and creating three tasks with due dates is a far better record of that than a note nobody reads. The reverse works too: an end-of-day pass that closes everything already done keeps the list credible enough that you keep looking at it.

• "Read yesterday’s conversations and create a task for every promise I made, with a due date matching what I said."
• "What is overdue, what is due today, and in what order should I work through it?"

Pipelines (2 tools)

Two read-only tools describe the shape of your CRM rather than its contents: which boards exist, what stages they have, in what order, and how many contacts are sitting in each stage. There is no write tool here at all, because board structure is a configuration decision rather than a daily operation.

These are orientation tools. An assistant that calls crm_list_pipelines before it moves anybody gets stage names from your workspace instead of guessing generic ones, which is the difference between a stage move that lands and a stage move that gets rejected.

What you would actually ask for

You rarely ask for a pipeline directly. You ask a question about your funnel and the assistant reaches for these first to find out how your funnel is actually named. The one time you do ask directly is when you are diagnosing a bottleneck, because per-stage counts across every board is a picture you cannot get from a single deal list.

• "How are my boards set up, and which stage has the most contacts stuck in it?"
• "Before you move anyone, list my pipeline stages so we agree on what qualified actually means here."

pipelines:read is a small, safe scope worth granting to almost any assistant. Without it, an assistant guesses stage names, and guessed stage names produce rejected write calls that look like bugs.

Finance (4 tools)

Four tools, all read-only, all under finance:read. This group is reporting and nothing else. It reads the ledger, invoices and revenue-source configuration, and it cannot move, charge, settle or refund a single unit of currency.

That constraint is worth stating plainly because finance is where people are rightly most nervous about AI access. crm_list_invoices returns no payment link. crm_list_transactions cannot create, edit, refund or settle an entry. crm_revenue_sources_summary never returns a key or credential. Nothing in this group can be chained into a payment.

What you would actually ask for

Finance questions over MCP are the ones that would otherwise mean exporting a spreadsheet on a Friday afternoon. Because the entire group is read-only, you can grant finance:read to an analysis assistant without the usual argument about blast radius. The worst case for a leaked finance:read key is that somebody sees numbers, which is a real risk but a bounded one, and it is not the same category as a key that can spend.

• "How did we do last month by currency, what is still outstanding, and which expense category grew fastest?"
• "Which invoices are overdue, how much is owed in total, and which customers do they belong to?"

A finance:write scope exists on the key form and is left unchecked by default. Nothing in the MCP catalogue on this page requires it, which is the clearest possible signal that finance over MCP is a reporting surface.

Sequences (4 tools)

Four tools cover outbound sequences: two report on them and two control whether they are running. Notice what is not here. There is no tool to create a sequence, edit its steps, change its message copy or enroll a contact into it. The MCP surface can start and stop the machine, and it cannot rebuild it.

That is the right boundary for automated outreach. Pausing a live campaign because the AI noticed an error spike is exactly the kind of judgement you want an assistant making at three in the morning. Rewriting the copy that goes to two thousand people is not.

What you would actually ask for

The high-value request is a safety net rather than a campaign builder. You ask the assistant to watch failure rates and pull the handbrake, and because pause is idempotent it can do that without worrying about double-firing. The reporting half answers the weekly question of which campaign is worth its slot.

• "Check every running sequence and pause anything whose failure rate went above one in five, then tell me what you paused and why."
• "Which of my sequences is converting worst, and what does its step list look like compared to the best one?"

Pause is not a cancel. In-flight jobs still run, so the correct verification after a pause is to watch the outbound jobs list until it drains rather than assuming the queue emptied instantly.

Social inbox (7 tools)

Seven tools cover direct messages across every connected network: Instagram, Facebook, X, LinkedIn, TikTok, YouTube, Threads, Pinterest, Reddit, Bluesky, Telegram and WhatsApp. Five read and two write. This is the largest read group after contacts, and for a very practical reason: an assistant answering a stranger on Instagram needs far more context than one replying to a known contact.

The one to reach for first is crm_social_inbox_summary. A single call returns conversation and unread totals overall and per network, plus the threads still waiting on a reply, oldest first. That is a whole triage pass in one request instead of a dozen, which matters when your budget is 60 requests a minute.

What you would actually ask for

The request people actually make is some version of who is waiting and what should I say. That resolves into a summary call, a thread read for the two or three that matter, and a draft. Whether the draft goes out is a separate decision governed by a separate scope, and plenty of teams run this loop for months with social:read only, using the assistant as a very fast reader and writer while a human presses send.

• "Which social conversations are still waiting on us, across every network, and who has been waiting longest?"
• "Read this Instagram thread and draft a reply in the same language the customer used, matching how long their messages are."

crm_send_social_message is the tool that most obviously touches the outside world, and it carries platform rules with it. WhatsApp only allows a free-form reply within 24 hours of the customer’s last message, so a thread that has gone quiet for two days will refuse a casual follow-up no matter how the request was phrased.

Social posts (6 tools)

Six tools cover scheduled and published content: three read the calendar and its results, three schedule, edit and cancel. Publishing is the other place besides direct messaging where a tool call becomes visible to the public, so the read and write halves sit under separate scopes, posts:read and posts:write.

One detail changes how you phrase requests. crm_schedule_social_post creates one post per target account, so asking for the same thing on Instagram and LinkedIn produces two posts, not one post with two destinations. Per-platform rules are enforced at schedule time: TikTok and YouTube need a video, Instagram needs media, and X caps the text at 280 characters.

What you would actually ask for

Content requests come in two flavors. The planning flavor asks what is already queued and where the gaps are, which is pure posts:read. The production flavor asks for a week of posts to be written and scheduled, which needs posts:write plus social:read for the account list, because the account roster lives with the social inbox rather than with posts.

• "What is going out this week, on which networks, and where are the empty days?"
• "Draft five posts about the new pricing page and schedule them across LinkedIn and X for weekday mornings next week."

Watch publishNow. Everything else in this group is reversible up to the moment of publication, and publishNow removes exactly that window. A safe house rule is that an assistant may schedule but only a person may publish immediately.

Webhooks (4 tools)

Four tools cover outbound webhook endpoints: two read the registry and its delivery history, two register and remove endpoints. This group contains the only hard delete in the entire catalogue, and it is annotated as destructive so a well-behaved client can warn before it runs.

The delivery-history tool is the quietly useful one. crm_list_webhook_deliveries returns status, attempt count, last response code and last error for one endpoint, newest first, which turns the worst question in integration work into a single tool call.

What you would actually ask for

This group answers debugging questions, and it answers them fastest when the assistant can see both halves: what is registered and what happened to the last deliveries. Ninety percent of webhook problems are one of three things, an endpoint that was never subscribed to the event, a receiver returning a non-2xx status, or an endpoint that was deleted and forgotten. All three are visible from webhooks:read alone.

• "My webhook stopped firing. Which endpoints do I have, what events are they subscribed to, and what did the last twenty deliveries return?"
• "Register an endpoint on my staging server for message events only, and show me the signing secret so I can store it."

Two things to remember. The signing secret from crm_create_webhook appears once in that response and is never retrievable afterwards, so an assistant that creates an endpoint has to hand you the secret in the same turn. And crm_delete_webhook is genuinely permanent, which is why webhooks:write is the scope least suited to a general-purpose chat assistant.

AI agents and outbound jobs (4 tools)

Four tools sit at the boundary between your own automation and the assistant looking at it. Two describe the AI auto-reply agents already running in your workspace, and two follow outbound message jobs through the send queue. This is how an assistant answers the question that follows every send: did it actually leave.

crm_run_agent deserves its own paragraph. It runs one of your agents against a sample inbound message and returns the reply it would have sent. Nothing is delivered, no contact hears from you and no CRM record is created, changed or deleted. It is annotated as a non-read-only tool for one reason only: each run calls an external model provider and spends AI credits.

What you would actually ask for

The agent tools turn prompt tuning into something you can iterate on in a chat window: feed a real awkward customer message, read what the agent would say, adjust, run again. The job tools turn delivery from a hope into a fact. Together they cover the two things people worry about most when they automate replies, which is whether the wording is right and whether the message left the building.

• "Run my support agent against this angry message about a late refund and show me what it would send, without sending it."
• "Did everything I queued this morning go out? List anything that failed and show me the actual error."

agents:run is the one scope whose real cost is money rather than risk. It cannot damage your data, but a loop that runs an agent a hundred times spends a hundred model calls, so it belongs on assistants you supervise rather than on unattended schedules.

Analytics and connected accounts (4 tools)

Four read-only tools give an assistant the numbers and the account roster it needs to orient itself. Three sit under analytics:read and one, the account list, sits under contacts:read. That last placement surprises people, so it is worth saying out loud: crm_list_accounts is a contacts:read tool.

It matters because crm_list_accounts is the prerequisite for sending anything. Every send tool needs an account id, and this is where account ids come from. A key that has telegram:send but not contacts:read can send only to an account id you hardcode, which is occasionally what you want and usually a bug in your scope plan.

What you would actually ask for

These are the tools an assistant reaches for when you open a chat and say good morning. One dashboard call plus one stats call is enough for a useful standup, and the account list tells it which identities it is allowed to speak as. The trend question is the more valuable one, because a raw count today means nothing without the seven days behind it.

• "Give me a two-line standup: what happened yesterday, what is queued today, and is anything failing more than usual?"
• "How does this week compare with last week, and is one of my connected accounts responsible for most of the failures?"

The 21 resources, and when to read one instead of calling a tool

A resource is a fixed, read-only view of your workspace addressed by a crm:// URI, and it takes no arguments. That single property is what makes resources valuable. A tool call requires the assistant to decide what to pass, and every decision is a chance to be wrong. A resource read requires no decision at all: the URI is the whole request, and the server returns the same well-shaped answer every time.

Read a resource instead of calling a tool whenever three conditions hold. The question is general rather than about one specific record. The default window or default ordering is what you wanted anyway. And you are at the start of a session, where the goal is to give the assistant enough context to reason well rather than to answer one narrow question. Priming a conversation with two or three resources is the highest-value request-per-token move available on this server.

Reach for a tool instead when you need a specific record by id, a non-default time window, a filter, or pagination. crm://deals/open gives you the ranked opportunity list; crm_get_deal gives you one deal with its tasks. crm://jobs/recent tells you whether sends are failing; crm_get_job tells you why one specific send failed. The resource answers the question you asked out loud, and the tool answers the follow-up.

{"jsonrpc":"2.0","id":2,"method":"resources/list"}

{"jsonrpc":"2.0","id":3,"method":"resources/read",
 "params":{"uri":"crm://social/inbox"}}

A pattern worth copying: pick the three resources that match the assistant you are building and load them at the start of every session. A sales assistant wants crm://deals/open, crm://tasks/today and crm://recent-conversations. A social manager wants crm://social/inbox, crm://social/accounts and crm://social/posts/scheduled. An operator on call wants crm://jobs/recent, crm://webhooks and crm://agents. Three reads, and the assistant is oriented.

Notice which resources are narrower than their tool equivalents rather than wider. crm://tasks/overdue is strictly past due; crm://tasks/today also includes what is due later today. Reading both is redundant, and asking for the wrong one produces an answer that is technically correct and practically useless. Pick by the question: what has slipped, or what is on the plate.

The 15 prompts, and what each one is for

A prompt is a named, parameterized template that the server publishes and the client presents to a person, usually as a slash command or a menu item. The server supplies the wording and pulls the relevant CRM data into it; you supply whichever argument the template needs, if it needs one at all. Most of the fifteen take no argument, because they operate over the whole workspace; the rest need you to name one contact, one deal, one email thread, one conversation or one connected account.

Prompts are worth more than they look. The wording of a recurring analysis request is the part people get wrong and then never revisit, so a prompt that already asks for a weighted forecast and the three deals most at risk produces better output than the version you would type at nine on a Monday. It is also consistent week to week, which is the only way a recurring report becomes comparable.

The argument column below describes what each prompt needs rather than the literal field name, because the exact argument names come back from a prompts/list call and any client that supports prompts will show them when you pick one. Two prompts are explicit about their own limits: summarize-email-thread does not draft or send a reply at all, and dm-reply-draft drafts but never sends.

{"jsonrpc":"2.0","id":4,"method":"prompts/list"}

{"jsonrpc":"2.0","id":5,"method":"prompts/get",
 "params":{"name":"daily-briefing"}}

Four of the fifteen are worth setting up as recurring habits rather than occasional requests: daily-briefing every morning, task-prioritize right after it, pipeline-review before your weekly sales meeting, and weekly-finance-report on Friday. Those four alone cover most of what people build custom dashboards for, and unlike a dashboard they explain the numbers.

The remaining eleven are situational, and the situations are specific. You reach for audit-account-health when sends start failing, for lost-deal-postmortem during a quarterly review, for summarize-contact two minutes before a call. That is the mark of a well-scoped prompt library: each entry has an obvious moment rather than being a general-purpose ask with a different name.

Read, write, and where the write tools stop

Of the 62 tools, 37 are annotated read-only and 25 are annotated as writes, and the write set deliberately stops short of irreversible money and identity actions. That boundary is a design decision rather than an implementation gap, and it is the part of this server most worth understanding before you decide how much access to grant.

Here is what the write tools will not do, stated as flatly as possible. They will not create a ledger transaction. They will not pay, send, void or create an invoice, and no tool returns a payment link. They will not move a deal to won, because winning a deal books revenue. They will not create a deal that is already closed. They will not send email, even from the two tools that manage email threads. And crm_run_agent drafts a reply and never delivers it, no matter how the request was phrased.

The reasoning behind each of those is the same: the action either moves money or reaches a person in a way that cannot be taken back, and the cost of an assistant getting it wrong is not proportionate to the convenience of it getting it right. Booking revenue from a chat window because a conversation sounded positive is a bad trade even when the assistant is right nine times out of ten.

There is exactly one hard delete in the catalogue. crm_delete_webhook permanently removes an endpoint, stops every future delivery to it, and cannot be undone. It is annotated destructive so a client that asks for confirmation before dangerous operations will ask before this one. Everything else in the write set is either additive or reversible from the panel.

Three write tools reach a human being directly: crm_send_telegram_message, crm_send_twitter_dm and crm_send_social_message. A fourth reaches an audience: crm_schedule_social_post publishes immediately when publishNow is set. Those four are the ones to think hardest about, and they are spread across four separate scopes precisely so you can grant one without granting the rest.

Several write tools are idempotent, which matters more for AI agents than for human-driven code because agents retry. Pausing a paused sequence is a no-op. Marking an already-read conversation read changes nothing. Cancelling an already-cancelled post is a no-op. Creating a tag that exists returns the existing tag rather than a duplicate. Tagging and untagging are both idempotent. That set of guarantees is what makes a retrying agent safe to run against them.

One write tool has a side effect worth knowing about in advance. crm_add_contact_note appends to a field that holds 500 characters, and when it fills up the oldest text is dropped from the front. It is a rolling scratchpad, not an archive. Durable facts belong in tags, lead score, a deal or a task, all of which have their own tools and none of which overwrite anything.

A useful way to think about the whole boundary: the MCP surface can do everything that a competent assistant could reasonably do on your behalf during a working day, and none of the things you would want a second person to confirm. If you disagree with where that line sits, the scopes are the adjustment mechanism, and the next section is how to plan them.

Rate limits, batching and getting a lot done in 60 requests

Rate limiting is per API key: 60 requests per minute by default, with a ceiling of 300 on the Business plan. Going over returns HTTP 429 with a Retry-After header saying how long to wait. Every tool call is one request, every resource read is one request, and the protocol handshake costs a request too, so the budget disappears faster than people expect once an assistant starts working through a list.

The failure mode is worth picturing. You ask an assistant to review fifty contacts. A naive plan is one search call, then fifty crm_get_contact calls, then fifty crm_get_contact_activity calls. That is 101 requests for one question, and the assistant will be sitting in a 429 backoff halfway through while you watch a spinner. The same answer is usually available in three or four requests if you ask for it differently.

Four habits keep you comfortably inside the budget:

1. Prefer a resource over repeated tool calls. One read of crm://recent-conversations replaces a listing call plus several detail calls when all you needed was who is waiting. One read of crm://social/inbox replaces a summary call plus a conversation listing.
2. Ask for one summary rather than fifty lookups. Requesting a ranked shortlist with reasons produces a plan that fits in a handful of calls. Requesting a per-record report invites the assistant to fetch every record. Phrase the request around the decision you want to make, not the data you think it needs.
3. Use the tools that already aggregate. crm_social_inbox_summary returns per-network totals plus the waiting threads in a single call. crm_dashboard_summary returns headline KPIs in one. crm_finance_summary returns net per currency plus top expense categories in one. These exist so an assistant does not have to reconstruct them from primitives.
4. Give long-running automation its own key. The limit is per key, so a scheduled nightly job and an interactive assistant on the same key compete for the same 60 requests. Two keys with different scopes and different limits is both safer and faster.

When you do hit a 429, honor Retry-After rather than retrying immediately. A retry loop that ignores it will keep failing and burn its budget on failures, which is how a one-minute pause turns into a five-minute one. Well-behaved MCP clients handle this for you, but an agent framework you wrote yourself probably does not unless you made it.

For genuinely high-volume work, MCP is the wrong tool and that is fine. A nightly export of every contact belongs on the REST API, where you control pagination and concurrency directly. MCP is optimized for an assistant asking a few well-chosen questions during a conversation, not for bulk extraction. The trade-offs are laid out in detail on MCP versus REST API versus Zapier.