1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cc-tap What is my Claude Code session working on?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cc-tap

by es617

Overview Schema Related Servers Score Discussions

Python

Local

cc-tap

MCP License: MIT Python 3.11+

Experimental MCP server that lets Claude Desktop see into and interact with Claude Code Remote Control sessions.

Example: Ask Claude Desktop "what's my Code session working on?" and get a real answer.

cc-tap demo

Why this exists

Claude Desktop and Claude Code are separate worlds. Both build up rich context on your project, but neither can see what the other is doing. A design idea on Desktop that should drive an implementation in Code, or an implementation detail in Code that the Desktop conversation needs; both require you to copy-paste between windows and re-explain context that already exists.

Claude Code's Remote Control lets you drive a session from another device, but that's still you driving the same session. cc-tap is for the other axis: letting a different agent (Claude Desktop, or another Claude Code instance) read and interact with a running CC session through MCP.

Related MCP server: Claude Code MCP Server

Who is this for

Developers who use both Claude Desktop and Claude Code
Anyone who wants to monitor or interact with CC sessions programmatically
Multi-agent workflows where one Claude instance needs to coordinate with another

Quickstart

pip install cc-tap

Requires an active Claude Code login (claude /login) and Remote Control enabled.

Claude Code

claude mcp add cc-tap -- cc_tap

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "cc-tap": {
      "command": "cc_tap",
      "args": []
    }
  }
}

Tools

Tool	Description
`list_sessions`	List all CC sessions (optionally filter by status)
`get_session_info`	Get details about a specific session
`read_session`	Read recent conversation from a session
`get_session_events`	Get raw events, optionally filtered by type
`send_message`	Send a message to a CC session (fire and forget)
`send_and_wait`	Send a message and wait for the full response

How it works

cc-tap reads your Claude Code OAuth credentials (from macOS Keychain or ~/.claude/.credentials.json) and talks to the same API that Claude Code's Remote Control web UI uses. No additional authentication needed.

Sessions are accessed via HTTP polling (~1.5s latency). Messages you send appear in the target CC session as if typed by the user.

Limitations

Tool approval — the session runtime only picks up approvals via WebSocket (behind Cloudflare bot protection). You can see pending tool requests via send_and_wait, but must approve them in the CC terminal or claude.ai/code web UI.
Not real-time — uses HTTP polling, not WebSocket streaming. ~1.5s latency.
Undocumented API — uses internal Anthropic endpoints that may change without notice.
Local only — reads credentials from the local machine. Can't be deployed as a remote service.

Protocol

See PROTOCOL.md for the reverse-engineered Claude Code Remote session API documentation.

Development

git clone https://github.com/es617/cc-tap.git
cd cc-tap
pip install -e ".[dev,test]"
pre-commit install
pytest

Disclaimer

This project is an experimental research tool for personal and educational use. It interacts with undocumented, internal Anthropic APIs that are not part of any public or supported API surface. These endpoints may change, break, or be removed at any time without notice.

This project is not affiliated with, endorsed by, or supported by Anthropic. Use it at your own risk. The authors assume no responsibility for any consequences of using this tool, including but not limited to account restrictions, data loss, or service disruption.

By using this tool you acknowledge that you are responsible for compliance with Anthropic's Terms of Service and Acceptable Use Policy.

License

MIT

Available Tools

6 tools

get_session_eventsA

Get raw events from a session, optionally filtered by type.

Args: session_id: The session ID. event_types: Comma-separated types to filter (e.g. 'user,assistant'). Empty for all. last_n: Number of recent events to return (default 50).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`event_types`	No
`last_n`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description must convey all behavioral traits. It implies a read-only operation ('Get'), but does not disclose important details such as pagination, rate limits, or authentication requirements. The description is adequate but not fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using three sentences to convey essential information. It follows a clear structure with an Args section, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately covers the tool's purpose and parameters. However, it could be improved by noting the typical use case (e.g., debugging or session analysis) and clarifying what 'raw events' entails. Overall, it is sufficiently complete for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% coverage, meaning no parameter descriptions. The description adds meaning for all three parameters: session_id as required, event_types as comma-separated filter with an example, and last_n with default 50. This significantly enhances understanding beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get raw events from a session, optionally filtered by type', which includes a specific verb, resource, and filtering scope. This distinguishes it from siblings like get_session_info and send_message.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like list_sessions or read_session. The description includes parameter details but lacks context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_session_infoA

Get details about a specific Claude Code session.

Args: session_id: The session ID (with or without 'session_' prefix).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Get details' implies a read-only operation, but the description does not explicitly confirm it is non-destructive or state any behavioral traits beyond the basic action. Acceptable for a simple read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences and an Args section with no fluff. Every word is necessary and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (so return values are documented separately) and the tool has only one well-described parameter, the description provides all necessary context for correct invocation. Could mention that the session must exist, but completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds value by clarifying that the 'session_id' parameter accepts both with and without the 'session_' prefix, which is not obvious from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets details about a specific Claude Code session, using a specific verb ('Get') and resource ('session details'). It distinguishes from siblings like 'list_sessions' (listing) and 'get_session_events' (events).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving details of a session by ID, but does not explicitly state when to use this over alternatives like 'read_session' or 'get_session_events'. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sessionsA

List all Claude Code sessions.

Args: status_filter: Optional filter — 'active' (non-archived), 'running', 'idle', or '' for all.

ParametersJSON Schema

Name	Required	Description	Default
`status_filter`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. It only mentions listing sessions with an optional filter; no details on pagination, rate limits, read-only nature, or output size. This is insufficient for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, then parameter details. Every word earns its place; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional param and an output schema, the description is largely complete. Minor gaps: doesn't mention ordering, pagination, or that the filter accepts only the listed strings (but these are somewhat covered by the param description).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It does so by defining valid values for status_filter ('active', 'running', 'idle', ''), adding meaning beyond the schema's bare title and default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'list' and resource 'Claude Code sessions', immediately conveying its function. Distinguishes from siblings like 'get_session_info' and 'read_session' which target individual sessions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage from the description and sibling tools, but lacks explicit guidance on when to use this tool versus alternatives like 'get_session_info' or 'send_message'. No when-not-to-use conditions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_sessionA

Read recent conversation from a Claude Code session.

Args: session_id: The session ID. last_n: Number of recent events to return (default 20).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`last_n`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully convey behavioral traits. It states 'Read' (implying non-destructive) but does not disclose permission requirements, error handling for invalid session IDs, or details about the output format, despite an output schema existing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences with parameter details in a clean arglist format. Every word serves a purpose, and the main action is stated first. No redundancy exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description doesn't need to detail return values. However, it lacks important context like how many events constitute 'recent', the effect of no session ID, or how this tool relates to get_session_events. It is adequate for a simple tool but leaves gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It explains that session_id is 'The session ID' and last_n is 'Number of recent events to return (default 20).' This adds value beyond the schema's type/title, but the explanations are minimal and do not provide richer context like valid ranges or format constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Read recent conversation from a Claude Code session.' It uses a specific verb ('Read') and a distinct resource ('recent conversation') that differentiates it from sibling tools like get_session_events and get_session_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes parameter details but provides no explicit guidance on when to use this tool versus its siblings. There is no mention of prerequisites, limitations, or scenarios where an alternative would be preferred, leaving the agent to infer usage from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_and_waitA

Send a message to a Claude Code session and wait for the full response.

Polls until the session produces a result event (turn complete), then returns the assistant's response. Use this when you need the other session's answer.

Args: session_id: The session ID to send to. message: The message text to send. timeout: Max seconds to wait for a response (default 120). poll_interval: Seconds between polls (default 1.5).

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`message`	Yes
`timeout`	No
`poll_interval`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description explains the polling mechanism, waiting for turn complete, and the timeout/poll_interval parameters. It discloses synchronous behavior but doesn't detail timeout handling or potential errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the main purpose, and the Args block is clearly structured. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the tool's behavior and parameters for a synchronous send-and-wait operation. The presence of an output schema reduces the need to describe return values. Minor omission: no mention of error handling on timeout.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description includes an 'Args' section that explains each parameter's purpose (session_id, message, timeout, poll_interval), fully compensating for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (send and wait) and the resource (Claude Code session). It distinguishes itself from siblings like 'send_message' by emphasizing the waiting behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Use this when you need the other session's answer,' providing explicit usage context. It doesn't explicitly mention when not to use, but the contrast with 'send_message' is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_messageC

Send a message to a Claude Code session.

Args: session_id: The session ID to send to. message: The message text to send.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`message`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states 'Send a message,' implying a write operation, but lacks details on side effects, idempotency, or session state requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short but includes a redundant 'Args' block that mirrors the schema. It could be more concise by omitting explicit parameter listing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description need not detail return values. However, for a write tool, it lacks sufficient behavioral context for correct agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description repeats parameter names without adding any semantic meaning, formats, or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Send a message to a Claude Code session,' using a specific verb and resource. It distinguishes from siblings like 'send_and_wait' and read-only tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus 'send_and_wait' or other alternatives. No prerequisites or context for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 31, 2026
- First observedget_session_events
- First observedget_session_info
- First observedlist_sessions
- First observedread_session
- First observedsend_and_wait
- First observedsend_message

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Tools are generally distinct: get_session_info, list_sessions, and send_message/send_and_wait have clear purposes. However, get_session_events and read_session both retrieve session content, with descriptions that partially overlap (events vs conversation), which could cause minor confusion.

Naming Consistency5/5

All tools use a consistent verb_noun pattern in snake_case, such as get_session_info, list_sessions, send_message. The naming is predictable and follows a clear convention.

Tool Count4/5

With 6 tools, the server is well-scoped for managing Claude Code sessions. The count covers essential operations without being excessive, though a tool for archiving or deleting sessions might be expected.

Completeness3/5

The tool set covers listing, reading, and sending to sessions, but lacks tools for lifecycle management like creating, archiving, or closing sessions. This leaves some gaps for full session management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181

Related MCP Servers

device-controller-mcp
OS Automation Command Line
geojakes
A
license
Not graded
quality
B
maintenance
An MCP server that lets Claude Desktop and Claude Code control your PC — take screenshots, click, type, manage windows, and more.
Updated 3 months ago (2026-06-08 01:16 UTC)
MIT
Claude Code MCP Server
Code Execution File Systems Command Line
trickv
A
license
Not graded
quality
D
maintenance
An MCP server that allows Claude Desktop to remotely control Claude Code instances for executing commands and managing files.
Updated a year ago (2025-10-21 01:40 UTC)
30
GPL 3.0
agent-network
Agent Orchestration Communication Coding Agents
sharifli4
A
license
Not graded
quality
D
maintenance
MCP server that enables Claude Code to communicate with other Claude Code agents over HTTP, allowing users to ask questions about remote codebases or delegate coding tasks.
Updated 6 months ago (2026-03-13 07:21 UTC)
MIT
claude-tmux-bridge
Coding Agents Shell Access
PiMPStudios
A
license
A
quality
D
maintenance
An MCP server that connects Claude Desktop to an interactive Claude Code session running in a tmux terminal.
Updated 4 months ago (2026-05-03 20:21 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/es617/cc-tap'

If you have feedback or need assistance with the MCP directory API, please join our Discord server