Where Outreach MCP access for sales team work starts
The request usually arrives as three sentences. Read the sequences and their step stats. Look up a prospect or an account by name. Never enroll anyone, and never send mail from a connected mailbox. Outreach MCP access for sales team work is those three sentences turned into rules. Elaichi keeps them in three separate places: an allow rule, a block rule, and a locked argument on a toolbox entry.
Sales ops often works in Cursor already, beside the SQL they write against the warehouse. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Cursor signs into Elaichi at the same address as Claude and ChatGPT, https://api.elaichi.ai/mcp. That is one address for every organization. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the approval one person gives one named client on Elaichi's own consent screen.
If your sales ops team lives in ChatGPT instead, the ChatGPT sign-in steps differ but the Elaichi half of this playbook is identical.
Is Outreach in the connector catalog?
Check the console first, because the answer decides who does the setup. Elaichi's catalog holds 650+ connectors of two kinds. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit. Start at the Outreach connector page. Search in Elaichi forgives one typo, so a near miss still finds the row.
If Outreach is not listed, a team can bring its own. An Org Owner or Org Admin on Gold can add a remote MCP server as the organization's own connector. The server has to be reachable over public HTTPS. That is the same route bringing a vendor's own server in behind SSO takes. It needs connector:create, the only permission Elaichi flags as High trust. The reason for the flag applies here: a restriction binds a connector's identity, its slug and its declared fork lineage, never the host it calls. A block on one Outreach connector does not stop a second connector built against the same API.
How do you allow only sequence reads and prospect lookups?
Write allow rules on the role sales ops holds, naming the read tools you want. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A team shares rules only because its members share a role.
Two properties decide the shape of the rule set. First, an allow rule turns on the allowlist for its layer just by existing. Once the sales ops role carries one allow rule, every connector and tool its allow rules do not name is blocked for that role. That applies across the whole catalog. The role therefore needs whole-connector allow rules for each other app it uses, the CRM and the ticketing system included. Those can be separate rules, because a layer's allow rules merge into one allowlist. Second, an allow rule that names nothing blocks everything for its target. Its summary reads "Allows nothing. Every connector and tool is blocked."
Allow rules match the operation Elaichi stored when the rule was saved, not the label the tool is shown under. Blocks match either. Read the matching difference between blocks and allows once before you write a long rule set.
Among the system roles only Org Owner and Org Admin hold restriction:manage. A rule aimed at one member also needs restriction:override. Restrictions are included on Gold and Black. A rule change reaches every surface in about two minutes.
Blocking bulk enrollment and mailbox sends
Name those tools in block rules on the same role. A block always beats an allow inside a layer. The blocks keep holding if somebody later widens the allowlist. Find the exact names on the connector's page in the console. Tool lists there return every tool to anyone who can read the connector, flagged with whether it is restricted for you and why.
Do not rely on blocks alone to make Outreach read-only. A layer with only block rules has no allowlist. Every write tool the rules do not name stays reachable, including one the vendor adds next month. The allow rules close that gap; the blocks are the backstop.
One case deserves an admin's attention. From Cursor, a person who hits a block can file their own access request. Approving a request for the connector adds that connector whole to the requester's allowlist, sends included. The console dialog says what approving will change before anybody clicks. A request for a single tool on a connector blocked whole is refused instead, with a message naming the connector to ask for.
Freezing the sequence owner on a toolbox entry
Pin the tool into a toolbox entry and lock the owner argument there. A toolbox is a named list of tool entries, each pinned to one connected account. Frozen parameters are argument values written into the entry that a caller cannot override. The keys are removed from the schema the model sees, and the frozen value wins over both entry defaults and whatever the caller sends.
A freeze is a lock, not a secret. Elaichi tells the model which keys are frozen and often shows short values. Anyone who can open the toolbox reads every frozen value in full. The AI cannot change them. Why a locked argument behaves like a wire's payee field covers that distinction at length.
The freeze holds only on calls that run through the entry carrying it. Anyone who can use the connection has the same tool, unfrozen, in their All tools toolbox. So the connection's owner keeps it unshared and pins it into the entry with the frozen owner value. Then they share the toolbox at use rather than the connection. Do not try to close the unfrozen path with a restriction: restrictions match the catalog tool, so the rule would refuse the frozen entry too.
Whoever pinned the entry is its delegator and must hold use on that connection. If they are removed or suspended, the entry resolves as unmet for everyone who opens the toolbox, its owner included. It stays that way until somebody with edit on the toolbox and use on the connection re-pins it. Pick a delegator who will still be there next quarter.
What Cursor's own controls cover, and what they do not
Cursor's controls decide which servers reach developers and when a tool call prompts. They cannot tell one app behind Elaichi from another.
In Cursor's MCP documentation, Team admins can distribute shared MCP servers, configured under Dashboard > Plugins & MCPs. Enterprise admins configure MCP policy, and Cursor asks for approval before using MCP tools by default (checked October 2026). Cursor's model and integration management page says the MCP Allowlist is Enterprise-only. Adding a server to it approves a configuration rather than pushing the server to users' machines. Team members still configure it in their own settings, and the route for distributing an approved server is a team marketplace (checked October 2026).
Other clients draw the same line. Codex sets approval per server with default_tools_approval_mode, which takes auto, prompt, writes or approve, and prompts for any tool not marked read-only (OpenAI's Codex MCP page, checked October 2026). Claude applies connector tool permissions of Always allow, Needs approval or Blocked, to a whole connector, a category of its tools or a single tool (Anthropic's connectors article, checked October 2026).
On the Elaichi side, connected tools are never listed one by one, however few there are. The model finds a connected tool with search_tools and runs it with execute_tool, or with run_code where Code Mode is available. A per-tool permission inside a client therefore sees one execute_tool standing in for every connected app. Per-app and per-tool control belongs in Elaichi, as restrictions. None of the tools that run connected tools is marked read-only either. A client setting that lets read-only tools run unprompted still prompts for every Outreach call, reads included.
When this is more than your team needs
If one analyst asks these questions, skip most of the rule set. Give that person an Outreach login that cannot enroll or send, have them connect it, and stop. The rules above earn their keep when several roles share the same apps. They earn it again when you want the sends shut for a group rather than for one account, and when you want one audit trail across Outreach, the CRM and everything else the team reaches.
Keep one thing in mind whichever route you take. Every call through a connection uses the account it was connected with. A connection shared at use therefore acts in Outreach as its owner, not as the caller. Per-person reach in the app comes from per-person connections, the pattern each rep's own Salesforce access walks through.
What the audit log shows the week after
Every connected-tool call that reaches execution writes one row. The row names the person, the tool's advertised and catalog names, the connector, and the connection the call actually reached. It also carries the tool's classification, how approval was given, the surface, the MCP client, the outcome and what it touched. A call from Cursor carries the surface mcp and the client's id, and the console renders it as a sentence naming the client.
Two gaps sit in that record, and a reviewer should hear about them first. A call refused before execution writes no row at all. That covers a tool a restriction withholds, a missing OAuth scope and an unknown tool name. And Elaichi keeps 90 days of audit history; export to your own Datadog comes with the Black plan, which is launching soon.
For the model these rules sit inside, read who may do what, in which app. For the client half, setting Cursor up for a whole team covers the sign-in each person does once. To check what is already in the catalog before you build anything, start at the connector catalog.
