Feature Requests

Please build an official MCP (Model Context Protocol) connector for Missive so that external AI agents and tools (Claude, ChatGPT, Cursor, etc.) can interact with Missive data in a secure, structured way. What we're asking for: An official, supported MCP server that exposes Missive resources — conversations, messages, contacts, labels, assignments, and drafts — to any MCP-compatible AI client. Why this matters: MCP is quickly becoming the standard protocol for connecting AI assistants to external tools and data sources. Without an official Missive MCP connector, users are forced to build their own unofficial integrations (some community members have already done this), which are unsupported, fragile, and lack proper auth scoping. With an official MCP connector, Missive users could: Ask an AI agent to summarize open conversations or flag urgent threads Create and send draft replies via an AI agent that has context from multiple tools (CRM, calendar, notes, etc.) Build automations that read Missive data alongside other MCP sources (e.g., Pipedrive, Notion, meeting transcripts) Use Missive as a full participant in multi-agent workflows Suggested capabilities (read + write): Read: list/search conversations, fetch message threads, get contact details, retrieve labels and assignments Write: create drafts, send messages, apply labels, assign conversations, update contact fields Why now: MCP adoption is accelerating rapidly across AI clients (Claude Desktop, Cursor, Windsurf, etc.). Teams that rely on Missive as their communication hub deserve a first-class integration, rather than having to work around the gap with screenshots or DIY solutions. This would be one of the highest-leverage integrations Missive could ship — it opens Missive up to the entire AI agent ecosystem at once.

When will we be able to use a tools from an MCP server as an action? An example use case: We have an AP inbox. And every email that comes into that inbox, we want the invoice in the email to be added in our accounting platform, Xero. Using the Xero_create_bill tool.

Coexistence enables people with the WhatsApp Business App (not API) to connect with WhatsApp Business Platform, so that messages sent to the app sync with the API (and hence can appear in Missive). This would be a massive unlock for us because it means our sales people can be supported on Missive by a team, whilst they could still directly message clients from their normal WhatsApp Business app. This also means we won't be forced to use templates.

We use Aircall + Missive at our business and want a simple workflow: if an inbound call isn't answered, the conversation gets flagged (task or label) for callback. We can't build this reliably today because the Aircall integration doesn't surface the call's disposition into the conversation in any way a rule can target. Right now an inbound missed call looks like this in Missive: New call coming from [Caller] on Office Number. Looking for someone available in the Office Number team… Call ended, duration: 3 seconds The "Call ended" line is identical for answered and missed calls, so Content conditions can't distinguish them. We've tried every workaround in the existing rule engine: Content rules can't tell answered from missed - the strings are nearly identical. Delay actions don't re-check Content after the wait, so we can't catch the later "answered the call" event when it eventually appears. "Unassigned/Unreplied and open after" assumes the team always assigns or replies on answered calls, which isn't reliable for teams using pooled ownership. We checked with Aircall support directly, and they confirmed the data exists in their webhook payload as a missed_call_reason field, with values like agents_did_not_answer, abandoned, abandoned_in_ivr, no_available_agent, out_of_opening_hours. Missive's integration just isn't mapping it into the conversation. What would solve it: expose Aircall's call disposition somewhere a rule can target. Either: A new rule condition (e.g., "Aircall call status is missed" / "Aircall call disposition is X"), or A standardized line in the call event message (e.g., "Call ended - missed (no agent available)") that Content conditions could match on. This is a near-universal need for teams on Aircall + Missive - flagging missed calls for callback is foundational in healthcare, services, sales, and anywhere a missed call has real cost. Thanks for considering!

It's great that you're offering Claude, Gemeni, and OpenAI, but with the nature of email, many organizations aren't comfortable, and have policies against sending that data out externally. It should be a nominal modification to support Ollama.

Please, dear god, have a way to create read-only API keys.

There is not currently a way to search for text in the subject or body of emails via the API. When using Missive from external LLMs (via customer MCPs or command-line tools), this severely limits their usefulness. Adding a way to search via the API is necessary for Missive to be competitive with other email tools.

We would like to request a native TikTok integration for Missive. Currently, we are able to receive and manage private messages from Meta platforms (Instagram, Facebook Messenger) directly in Missive. We would like to have similar functionality for TikTok private messages, specifically receiving TikTok DM conversations directly in Missive inboxes. This would allow our team to manage customer communication from TikTok alongside other social channels in a single unified inbox, improving response times and operational efficiency. TikTok is an increasingly important customer communication channel for us, and native support would be highly valuable.

Please add support for 5.4 as we're currently limited to max a 5.2 model for OpenAI

Currently, the Missive API does not expose the parent-child relationship between comments — there is no way to determine which comment a given comment is replying to. Additionally, the create post endpoint does not support creating a comment or post as a reply to an existing one. For our bot integration, these features would be extremely valuable for maintaining context and enabling threaded conversations. We’d greatly appreciate support for: 1- Including a parent_id or similar field in the comments API response. 2- Allowing create post to specify a parent_id to create replies programmatically.