codex-intercom-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_INTERCOM_NAME | No | Optional intercom display name for this Codex session. Set at MCP registration time with --env CODEX_INTERCOM_NAME=planner. | |
| PI_CODING_AGENT_DIR | No | Overrides the base directory for intercom runtime files, including the broker Unix domain socket. The socket path becomes $PI_CODING_AGENT_DIR/intercom/broker.sock. Defaults to ~/.pi/agent. | |
| CODEX_INTERCOM_MODEL | No | Optional model label for the session. Set at MCP registration time with --env CODEX_INTERCOM_MODEL=codex. | |
| AGENT_INTERCOM_SCOPE_ID | No | Broker-enforced scope routing via protocol v4. Defines the logical scope for session discovery and messaging. Same-scope sessions see each other; cross-scope messaging requires explicit full session ID. Not a security boundary. Defaults to no scope (global). | |
| CODEX_INTERCOM_SESSION_ID | No | Optional stable session ID for this Codex session. Set at MCP registration time with --env CODEX_INTERCOM_SESSION_ID=codex-planner. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| intercom_whoamiA | Return this Codex session's intercom identity for reliable targeting. |
| intercom_teamB | Show all your named task teams, or inspect one by name. Falls back to managed-team discovery. |
| intercom_joinA | After user approval, create or join a task team. Membership is additive; members lets the manager add connected peers in one call. Omit name to list teams. |
| intercom_statusA | Show intercom connection status, active sessions, unread messages, and pending asks. |
| intercom_listB | List intercom-connected Pi or Codex sessions on this machine. |
| intercom_set_summaryB | Publish a short status summary so other sessions can discover what this Codex session is doing. |
| intercom_sendB | Send a non-blocking direct message to another intercom session by name, full ID, or unique ID prefix. |
| intercom_askA | Ask another intercom session a question only when the next step depends on its reply. Use intercom_send for assignments, progress/status checkpoints, and notifications. |
| intercom_pendingB | Read unread inbound messages and unresolved asks. When awaiting delegated results without coi or native thread queue wake, use wait_ms: 60000 and mark_read: true to wait for incoming completion reports without ending the Codex turn. |
| intercom_replyA | Reply to an inbound ask or ordinary message using askId or contextId from intercom_pending. Inherits the original team; team cannot override it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct purposes: join/team for team management, send/ask/reply for messaging, list/whoami for discovery, and set_summary for status publishing. There is some overlap between intercom_status (shows unread messages/pending asks) and intercom_pending (reads unread inbound messages/asks), and intercom_list vs intercom_team could be momentarily confused, though descriptions clarify the boundaries.
All tools share a consistent `intercom_` prefix and lowercase snake_case, making them recognizable as a family. However, styles vary between bare verbs/nouns (`send`, `ask`, `team`, `status`, `pending`, `whoami`) and a verb_noun form (`set_summary`), so it is not a perfectly uniform pattern.
Ten tools is well within the ideal 3–15 range for a session-messaging and team-coordination server. Each tool maps to a meaningful operation (join, list, send, ask, reply, pending, status, team, summary, whoami) with no obvious padding.
The surface covers the core lifecycle: identity, session discovery, team creation/inspection, direct messaging, ask/reply, reading pending items, and publishing summaries. Minor gaps exist—no explicit leave-team/unregister operation and no way to retrieve historical messages beyond unread/pending, but agents can work around these.