talk-to-claude-code
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_REMOTE_MCP_DENY | No | Comma-separated list of session names that never accept writes. | |
| CLAUDE_REMOTE_MCP_HOST | No | Host interface for HTTP mode. Defaults to 127.0.0.1. | 127.0.0.1 |
| CLAUDE_REMOTE_MCP_PATH | No | Path for HTTP mode. Defaults to /mcp. | /mcp |
| CLAUDE_REMOTE_MCP_PORT | No | Port for HTTP mode. Defaults to 8787. | 8787 |
| CLAUDE_REMOTE_MCP_ALLOW | No | Comma-separated list of session names that are allowed to accept writes. If not set, writes are allowed to all sessions (unless denied). | |
| CLAUDE_REMOTE_MCP_TOKEN | No | Secret token required for HTTP mode. Used as Authorization: Bearer <token> or as a path segment. Required unless CLAUDE_REMOTE_MCP_NO_AUTH=1 is set. | |
| CLAUDE_REMOTE_MCP_NO_AUTH | No | Set to 1 to disable authentication in HTTP mode. If set, no token is required. | |
| CLAUDE_REMOTE_MCP_READONLY | No | Set to 1 to disable all write tools. | |
| CLAUDE_REMOTE_MCP_ALLOW_SELF | No | Set to 1 to permit writing to the session that hosts this server (disabled by default). |
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 | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_sessionsA | Name the sessions you can drive. Returns one short line by default, because a voice client reads the whole result aloud. Ask for details only when the user wants them. |
| session_statusA | Report the current state of one session, resolved by name, session id, or pid. |
| read_transcriptA | Read recent conversation turns from a session, including work it did while driven from a phone or from claude.ai. Subagent sidechains and tool plumbing are omitted. |
| send_messageA | WHEN TO USE THIS: any question or instruction about the user's own projects, code, repositories, machine, builds, deployments or work in progress belongs to a session — relay it. You do not know what is on their disk, and neither does a web search. Do not answer from your own knowledge, do not search the web, and do not ask clarifying questions the session could answer better: pass it through and let the session look. Answer in your own voice only when the user asks about you, or about how this connector itself works. Queue a prompt in a running session and return immediately with a cursor. The message enters that session as if typed, so it is also visible to any Remote Control client watching it. Follow up with get_reply, passing the cursor as |
| get_replyA | Watch a session and return whatever it produced since the given cursor, along with a fresh cursor. Blocks for at most wait_seconds, then returns what it has — so call it repeatedly to follow a long task. The result says whether the session finished or is still working. If it is still working, call this again with the returned cursor. Assistant turns list the tools the session used, which is the progress signal while a task is underway. |
| askA | WHEN TO USE THIS: any question or instruction about the user's own projects, code, repositories, machine, builds, deployments or work in progress belongs to a session — relay it. You do not know what is on their disk, and neither does a web search. Do not answer from your own knowledge, do not search the web, and do not ask clarifying questions the session could answer better: pass it through and let the session look. Answer in your own voice only when the user asks about you, or about how this connector itself works. Send a prompt and wait for the answer in one call. Best for short questions. If the session is still working when the wait runs out, this returns the output so far plus a cursor — continue with get_reply rather than calling ask again, which would send the prompt a second time. |
| rename_sessionA | Change a session's display name, as shown in its prompt box and session pickers. |
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 7 tools
send_message and ask both relay prompts to a session, differentiated mainly by async-vs-sync behavior; the descriptions document this distinction but the overlapping purpose creates selection risk. read_transcript and get_reply also both retrieve conversation output, though they differ in full-history vs. incremental-polling. The remaining tools (list_sessions, session_status, rename_session) are clearly distinct.
Most tools follow a clean verb_noun pattern (list_sessions, read_transcript, send_message, get_reply, rename_session), but session_status breaks the pattern by omitting a verb, and ask is a bare verb with no noun. These are minor deviations that don't cause real confusion.
Seven tools is well within the ideal range for a session-driving server. Each tool has a clear job: list, status, transcript, async send, reply polling, sync ask, and rename — nothing feels redundant or missing at the count level.
The core drive-a-session workflow is fully covered: discover sessions, check status, send prompts (both sync and async), follow progress, and read history. The main gap is the lack of a stop/cancel operation for long-running work, and session creation appears out of scope since sessions come from phone or claude.ai clients.