MCP guide
iMessage MCP server for Claude, Cursor and ChatGPT (hosted, no Mac)
Comms by Osis runs a hosted MCP server at https://comms.osis.co/api/v1/comms/mcp that lets Claude, Cursor, ChatGPT and other MCP clients send and read iMessage and SMS from a real phone number, with no Mac or local bridge.
Connect Claude, Cursor or ChatGPT
Comms by Osis runs a hosted MCP server at https://comms.osis.co/api/v1/comms/mcp.
Point any MCP client that supports remote HTTP servers at it, sign in with OAuth or send a scoped osis_ API key, and the assistant can send and read iMessage and SMS from your Comms line. There is no Mac to run.
In Claude (claude.ai or Claude Desktop), add it as a custom connector under Settings › Connectors. In Claude Code, Cursor and VS Code, use the configuration below. ChatGPT supports remote MCP servers in developer mode.
# Claude Code
claude mcp add --transport http comms https://comms.osis.co/api/v1/comms/mcp
# Cursor (~/.cursor/mcp.json)
{ "mcpServers": { "comms": { "url": "https://comms.osis.co/api/v1/comms/mcp" } } }
# Server-side, with a scoped key instead of OAuth
Authorization: Bearer osis_<your-scoped-key>What tools does the Comms MCP server have?
The server exposes messaging, conversation, contact, line and agent operations: send a message, reply in a conversation, react, send a poll or contact card, list conversations and messages, mark read, and manage agents and webhooks.
Run tools/list after you connect to see exactly what your granted scopes allow.
The published API documents osis_comms_react_to_message and osis_comms_send_contact_card. Obtain other exact names from the live inventory rather than guessing. Give read-only clients comms_read; grant comms_send only to clients allowed to send.
Receiving is different from waking an assistant
An assistant can inspect conversations when it calls a read tool. A production responder should receive signed webhooks, persist the event, and invoke a narrowly scoped worker. MCP by itself is not a durable inbound inbox or a background scheduler.
Do not use customer messages to steer an assistant that also has broad coding or administrative tools. Keep send permissions, recipients and human takeover under your application’s control.
Compare hosted actions, docs and local bridges
Before evaluating any MCP provider, ask whether its server performs messaging actions, merely searches documentation, or depends on a local device. Check inbound retrieval, number provisioning, hosting, authentication and supported regions separately.
| MCP type | What it gives you | What still needs work |
|---|---|---|
| Hosted messaging actions | Remote tools calling a messaging service | Number eligibility, scoped permissions, event processing and application state. |
| Documentation MCP | Reference search for API instructions | A separate API integration that sends and receives messages. |
| Local device bridge | Access through hardware or an account you operate | Host availability, identity continuity, maintenance and suitability for customer workflows. |
Confirm line and channel availability
API line claiming requires workspace approval and available inventory. A denied claim returns line_claim_not_allowed; unavailable inventory returns no_available_line.
RCS requires a supported dedicated line, carrier enablement, and a compatible recipient. Sending currently supports one plain-text message to an E.164 phone number.
Use a consenting test recipient and verify both outbound and inbound behavior. A successful tool call is not necessarily a delivery receipt.