A support lead runs a shared inbox in Missive. Email, SMS and chat land in one place, and the team works them with labels, comments and tasks. The agents want Claude next to it: summarize this thread, list the open conversations labeled Billing, pull up this customer, draft a reply. The lead wants one thing kept with a person. Nothing goes out to a customer unless a human sends it.
Putting Missive in Claude through Elaichi gets most of that with one restriction on the support role. The catch is where the send path sits. In the missive connector, sending is not its own tool. It is an argument on the draft tool.
What does a support agent use Missive in Claude for?
Read, summarize, organize and leave notes. The missive connector carries 32 tools: 18 read, 8 create, 3 update and 3 delete. Almost everything a frontline agent asks for is a read.
| What the agent asks Claude for | Tool that runs |
|---|---|
| Summarize a thread | get_single_missive_conversation_by_id, list_all_missive_conversation_messages, list_all_missive_conversation_comments |
| The open conversations labeled Billing | list_all_missive_shared_labels, then list_all_missive_conversations with that label |
| Who this customer is | list_all_missive_contacts with a search, get_single_missive_contact_by_id |
| The saved reply for refunds | list_all_missive_responses, get_single_missive_response_by_id |
| A note the team sees in the thread | create_a_missive_post |
| A follow-up task | create_a_missive_task, update_a_missive_task_by_id |
Two limits matter before the pilot. The conversation list returns what the connected person can see, and it must be filtered by mailbox, shared label or team. So "this customer's history" means the contact record plus the threads in a label or team inbox, not a search by email address. And the connector has no tool that creates a comment. Missive's Endpoints reference lists comments but documents no endpoint to create one (checked October 2026). A post is the nearest thing: an entry in the conversation that team members see.
Which Missive tool actually sends a reply?
create_a_missive_draft. Its drafts object takes send, which the catalog describes as sending the draft immediately upon creation, and send_at, a scheduled send time. Missive's Endpoints reference says the same of its API: the drafts endpoint is the one to use for sending email (checked October 2026).
Sending through the API also runs the team's outgoing rules. Missive says a draft sent with send set to true triggers matching outgoing message rules, including scheduled follow-ups. One call can start a sequence.
The tool with "message" in its name does not send. create_a_missive_message creates an incoming message on a custom channel. Missive's reference describes it as simulating a message received from an external system. That makes it a way to put words in a customer's mouth, which is its own reason to keep it from agents.
So a rule meant to stop sending has to name the draft tool. A restriction in Elaichi decides which connectors and which individual tools a target may reach, not which arguments a call may carry. Drafting and sending arrive together, and a support role that must never send loses both.
How should each agent connect Missive?
With their own Missive token. Missive's REST API page says all API tokens are personal (checked October 2026). There is no organization token, and a token reaches every account its owner can access, shared accounts included. Generating one requires an organization on Missive's Productive plan.
That shapes the connection. Every call through an Elaichi connection uses that connection's token, whoever makes the call. If the lead connects once and shares it, every agent reaches the lead's Missive, private accounts too, and every post shows the lead as its author. When each agent connects their own token, Claude sees what that agent sees in Missive and acts as them.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves its 600+ connectors through one organization-wide endpoint, https://api.elaichi.ai/mcp. In a Claude Team or Enterprise organization, an Owner or Primary Owner adds it once under Organization settings, Connectors, Add, Custom, Web (Anthropic's custom connector guide, checked October 2026). Each agent then connects it under Customize, Connectors, with their own sign-in. The role each agent holds must carry tool:execute, the permission that gates the whole endpoint.
Which Missive tools should the support role lose?
Eight, in one block rule on the role the agents hold. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything, so the rule goes on the role, and it binds every call the agents make from Claude, ChatGPT, Cursor or any MCP client.
| Tool | Why the support role loses it |
|---|---|
create_a_missive_draft |
Sends with send, schedules with send_at |
create_a_missive_message |
Creates an incoming message on a custom channel |
create_a_missive_webhook |
Sends inbox events to any URL |
delete_a_missive_webhook_by_id |
Removes the team's existing hooks |
create_a_missive_shared_label, update_a_missive_shared_label_by_id |
Change labels the whole organization shares |
delete_a_missive_draft_by_id |
Deletes a draft a colleague is writing |
delete_a_missive_post_by_id |
Removes a note from a conversation |
The role keeps every read, plus posts, tasks, contacts and analytics reports. A post can also close, assign, label or move a conversation, per Missive's Endpoints reference (checked October 2026). That is triage, and it leaves a visible entry in the thread. Contact writes edit a shared contact book; add them to the rule if your team keeps contacts clean by hand.
Blocks suit a pilot, because the role's other apps stay open. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. The cost is that a tool the connector gains later is open until someone names it, so re-read the list when the tool count moves off 32. A block matches a tool's name or its pinned operation, so a renamed tool cannot slip past it. A restricted tool is withheld from the tool list, and search names it flagged restricted, with no schema. The rule takes effect within about two minutes.
Why do Missive webhooks stay off?
Because one call creates a standing copy of the inbox. Missive's Endpoints reference says its create-webhook endpoint creates a Missive rule with a webhook action (checked October 2026). The catalog's create_a_missive_webhook subscribes a callback URL to one event type: incoming email, SMS, Facebook, WhatsApp or Twilio chat messages, or new comments.
A support inbox reads mail from strangers all day. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. An email with instructions buried in it is ordinary text to the model, and it can steer Claude toward a tool. If that tool can point every incoming email at an outside URL, one bad message outlives the conversation. With the block rule, the webhook tools do not exist for agents, and new hooks stay a job for a person in Missive's Rules settings.
The delete tool goes in the same rule. Removing a webhook quietly breaks whatever automation the team built on it.
Where does Claude's suggested reply go?
Into a post on the conversation. With the draft tool gone, an agent asks Claude to write the reply and leave it in the thread. create_a_missive_post needs a notification title and body, and it appends to an existing conversation. The agent reads the suggestion beside the customer's message, edits it in Missive's composer and sends it. A person presses send every time.
Two details keep this honest. A post takes a username that replaces the token owner's name on the post. The audit trail still names the member who made the call. And Missive's REST API allows 5 concurrent requests and 300 a minute (rate limits, checked October 2026). A model looping over a label can hit that ceiling, so keep requests to one conversation at a time.
The support lead is different. The lead files an access request for create_a_missive_draft, and an admin with member:manage approves it in the console, under Governance, then Access requests. Approval needs step-up sign-in, nobody approves their own request, and no AI client can decide one. The grant lifts that one tool out of the lead's role rules, and every other block keeps applying. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. On Claude, a connector set to Needs approval also asks the member to confirm each call before it runs. Elaichi does not ask per call over MCP; that prompt is the client's.
How do you prove the send path is closed?
Wait about two minutes after saving, ask Claude to send, then read the audit log.
- Signed in as an agent, ask Claude to reply to a test conversation and send it. Claude should find
create_a_missive_draftonly as restricted. - Ask the same Claude to set up a webhook for new email. It should find the webhook tools only as restricted.
- Ask it to post a suggested reply to the thread. The post should appear in Missive under the agent's name.
- Filter the audit log by the agent as actor and the time of the test.
Elaichi keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none) (what each entry holds). The post has an entry with the tool, the outcome and the Missive connection, recorded with the MCP surface and the client's name. It records the one path argument that names the object, as the target id, and nothing else about the arguments, so no email body lands in the log. The refused send has no entry, because it never reached execution.
Why not use Missive's own MCP server?
For a team that connects only Missive, Missive's own server may be the better fit. Missive runs one at https://mcp.missiveapp.com (Missive's MCP server page, checked October 2026). It needs the Productive or Business plan, and an owner or admin has to turn it on first.
It does the one thing this playbook cannot. Missive's permissions page lists Create drafts and Send messages separately (checked October 2026). An app with drafts and without sending can write replies for review and cannot deliver them. Claude's draft would sit in the Missive composer, not in a post.
The trade is who holds that choice. Missive's admin controls page says an admin cannot limit which permissions members grant, restrict which AI apps they connect, or turn MCP on for some members and not others (checked October 2026). Each agent ticks their own boxes at sign-in. Missive also warns that writes over its server run immediately, without its in-app confirmation. Missive has a built-in assistant as well, which drafts replies inside the inbox.
Elaichi's case sits across apps. One address carries Missive next to the team's other apps. The support role's rules are written once by an admin, not chosen per person. One audit trail covers every app, and in Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. If none of that matters to a team of five, the case for holding off on a gateway lists the signals that change the answer.
What happens when a support agent leaves?
Their access through Claude ends on their next call, once they are removed or suspended in Elaichi. If your directory deprovisions through SCIM, the standard for syncing users from a directory, that suspends the member, which ends access the same way.
Removing the member runs a preflight first. It lists every Missive connection the agent owns. A private one that nothing else depends on is deleted with them. The agent's Missive account and its API tokens are a separate step in Missive. Offboarding a member who holds MCP connections walks the whole sequence.
The Zendesk playbook for support agents runs the same order for a ticket queue, with an access request for bulk updates instead of drafts. The helpdesk connectors and the team pages are where to plan the next rollout.
