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_listA | List intercom-connected Pi or Codex sessions on this machine. |
| intercom_set_summaryA | 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_pendingA | Read unread inbound messages and unresolved asks. When awaiting delegated results, use wait_ms: 60000 and mark_read: true to wait for incoming completion reports without ending the Codex turn. Repeat after a timeout while results are still required. Plain MCP cannot wake an idle Codex turn; use coi for automatic wake-on-message. |
| 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, but intercom_join's 'omit name to list teams' behavior overlaps with intercom_team, and intercom_status vs intercom_pending both report unread messages/pending asks. Descriptions do clarify the primary intent, so only minor confusion is likely.
All tools use a uniform intercom_<action> snake_case pattern, making the set highly predictable. The only slight deviation is noun-like action names (intercom_status, intercom_pending), but the convention remains consistent.
Ten tools is well-scoped for an inter-session messaging and team management server. Each tool maps to a distinct capability (identity, discovery, messaging, status) without obvious filler.
Core workflows are covered: identity, discovery, team join/inspect, send/ask/reply, pending reads, and status summaries. Minor gaps exist, such as no leave/disband team operation or team-wide broadcast, but agents can work around these by sending to individual members.