cc-in-codex

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but the SDK vs TUI variants (e.g., companion_open vs companion_tui_open, companion_send vs companion_start vs companion_tui_send) could be confused by an agent despite descriptions clarifying the differences. Overall, the boundaries are mostly clear.
Naming Consistency5/5
All tools follow a consistent 'companion_<verb>[_noun]' pattern using snake_case, with optional 'tui' prefixes for TUI-specific actions. This makes the tool set highly predictable and easy to navigate.
Tool Count3/5
With 18 tools, the set is in the 16-25 range that feels heavy. Many tools exist in both SDK and TUI variants, inflating the count, though each serves a genuine purpose for the dual interfaces.
Completeness4/5
The tool set covers the full lifecycle of a companion: create/restore, send/start tasks, monitor via status/recent/result, manage with cancel/reset/resume, and TUI-specific compact/raw operations. Minor gaps include no explicit listing of all companions for a cwd, but that's not essential.
Average 3.6/5 across 18 of 18 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Inspect' implies a read-only operation, but it does not disclose what information is returned, whether any side effects occur, or the format of the session details.
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 a single short sentence with no redundant words, which is concise. However, it is under-specified, and the lack of detail makes it less useful; conciseness alone does not compensate for missing critical information.
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?
The tool is simple with one parameter and no output schema, but the description still fails to mention what the inspection returns. For a status tool, agents need to know the result format and behavior, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only names 'cwd' in passing ('for a cwd'). It adds little meaning beyond the variable name itself, failing to explain the parameter's format, optionality, or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Inspect' and identifies the resource 'current companion session' with a scope 'for a cwd', making the core action clear. It differs from sibling tools like companion_send or companion_reset by indicating a read-only action, though it does not explicitly distinguish all siblings.
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?
There is no guidance on when to use this tool versus alternatives, no mention of exclusions or prerequisites. With 17 sibling tools all prefixed 'companion_', the description provides no contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose side effects. It mentions tmux and the attach command, but does not state whether it spawns persistent sessions, requires tmux to be installed, has permission implications, or what happens if a session already exists.
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 deliver the core action and the return value without any filler. The content is front-loaded and every word contributes useful information.
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?
For a complex tool with 15 parameters, no annotations, and no output schema, the description is too thin. It gives only a minimal return-value note and omits operational context, error handling, prerequisites, and relationships to sibling tools.
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?
Schema description coverage is 100%, and the individual parameter descriptions (mode, backend, permissionPolicy, etc.) are detailed, so the schema carries most semantic weight. The tool description adds no parameter-level meaning, which is acceptable under the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb phrases like 'Create or restore' and names the resource 'native Claude Code CLI in tmux', clearly identifying the tool's function. It still doesn't explicitly distinguish from companion_tui_resume, which likely also restores sessions.
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?
There is no guidance on when to use this tool versus siblings like companion_tui_resume, companion_open, or companion_tui_send. The description states what it does but not when it should be preferred or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states one behavioral aspect ('does not send work to Claude') and the adjective 'persistent.' It fails to disclose side effects like creating background processes or state persistence details, which are important for an open/create operation.
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 two short sentences. The first states the core purpose, the second clarifies a critical behavioral distinction. No filler or redundancy; every sentence earns its place.
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?
The tool has 15 parameters, no output schema, and no annotations, so the description must be richer to be complete. It does not explain what the result of a successful call looks like, when to use this over companion_start, or any prerequisites. For a complex stateful op, two sentences are insufficient.
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?
Schema coverage is 100% and the tool description adds no direct parameter info, but it does provide a helpful semantic clarification ('does not send work to Claude') that indirectly informs parameter intent (e.g., maxTurns, maxBudgetUsd are for later sends). Baseline of 3 is appropriate when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource combination ('Create or restore the persistent Claude Code companion') and adds a scope ('for a project cwd'). It also clarifies that it does not send work, distinguishing it from companion_send, but does not explicitly differentiate from companion_start or companion_tui_open.
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 use when you need to create or restore a companion for a project. The phrase 'This does not send work to Claude' gives a negative guideline (don't use to send work), but there are no explicit alternatives or exclusion criteria relative to sibling tools like companion_start or companion_resume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly states this is a 'Read' operation, implying non-destructive behavior, and lists the data fields it returns. However, it does not disclose whether reading consumes the result, what happens when no result exists, or any other side effects.
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 a single, front-loaded sentence with no redundant words. It packs the action, the three types of data returned, and the scoping context into exactly 12 words, making it highly concise and well-structured.
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?
For a one-parameter read tool, the description lists the return fields (result, resume command, session metadata) but omits edge cases like empty results or default cwd behavior. No output schema or annotations exist to provide additional context, so the description is only minimally complete.
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 only parameter, cwd, is given semantic meaning through 'for a cwd', indicating it is the working directory context. However, the description does not clarify whether cwd is optional, what default is applied, or the expected path format, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and identifies the exact resources: 'latest companion result, resume command, and session metadata' scoped to 'a cwd'. It is clear and likely distinguishes from sibling tools, though it does not explicitly name alternatives.
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 companion_recent, companion_status, or companion_resume. There is no mention of preconditions, such as having run a companion command first, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only behavior through 'capture' and 'monitor', but doesn't explicitly state that it doesn't modify the TUI or describe what happens if the TUI isn't running. It adds some context about persistence and tmux-hosting, but lacks deeper behavioral detail.
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 a single, well-structured sentence that efficiently conveys the tool's action, target, and purpose. It is front-loaded with the key verb 'capture' and includes essential context without unnecessary words.
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?
The tool has no annotations and no output schema, so the description must explain parameters, return format, and edge cases. It explains the core purpose but omits what cwd and lines mean, what the returned text looks like, and any failure behavior. This is insufficient for reliable invocation in the given sibling context.
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?
The input schema provides no descriptions for cwd or lines, and the tool description does not mention either parameter. With 0% schema coverage, the description fails to explain what these parameters control, leaving the agent to guess their meaning and 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 captures recent text from a persistent tmux-hosted Claude Code TUI, with a specific purpose of monitoring what the user sees. This distinctly separates it from sibling tools that send commands or manage the TUI, so the verb and resource are specific and unambiguous.
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 when to use it (for monitoring what the user sees), which gives some context. However, it doesn't explicitly exclude alternatives like companion_tui_raw or companion_recent, nor does it provide explicit when-not-to-use guidance. The use case is clear but not fully differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the primary behavior (launching a visible tmux CLI) but does not mention side effects such as replacing existing panes, permission implications, or how the binding behaves. It is not misleading, but it is minimal.
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 a single, well-structured sentence with no redundant words. It front-loads the key action (launching the CLI) and clearly communicates the resume/continue options. Every word earns its place.
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?
For a tool with 18 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the tool's role in the companion workflow, what happens after launch (e.g., does it block, return a session ID?), or how it relates to the many sibling tools. The schema is rich, but the description alone is insufficient for an agent to fully understand the tool.
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 input schema provides 100% description coverage for all 18 parameters, so the description need not add parameter details. It does not, but the high schema coverage establishes a baseline of 3. The description adds no additional parameter semantics 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 the tool launches a visible tmux-hosted Claude Code CLI with `--resume <sessionId>` or `--continue` and binds it to the project companion. This uses a specific verb+resource and distinguishes it from siblings like companion_tui_open (new session) and companion_resume (non-TUI).
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?
The description does not provide any guidance on when to use this tool versus alternatives. It simply states what it does, without indicating context, prerequisites, or exclusions. Sibling names suggest related tools but are not referenced, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals the blocking behavior (waits for events, finish, or timeout) but omits return value, error handling, or side effects on the companion process. This is partial transparency.
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 the main action and a practical usage hint. No redundant content; every word earns its place.
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?
The tool has no output schema, yet the description does not explain what the caller receives (e.g., events, status). It also omits timeout behavior (return vs. throw) and the purpose of cwd. These gaps are significant for a wait operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents timeoutMs and sinceCursor, but cwd has no description anywhere. The tool description adds no parameter meaning beyond referencing sinceCursor. With 67% schema coverage and no compensatory detail, parameter semantics are underdeveloped.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for companion events, finish, or timeout, and references sinceCursor, making the action specific. It does not explicitly differentiate from sibling tools like companion_status or companion_recent, but the core purpose is unambiguous.
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 phrase 'Use after companion_start' provides a clear usage context, indicating when in the workflow this tool applies. It lacks explicit exclusions or alternative tool comparisons, so it does not fully meet the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing side effects, prerequisites, and lifecycle behavior. It only states the binding action and one parameter requirement, omitting whether resuming modifies the current companion state, launches tmux, or has destructive implications. This is a significant gap for a tool with 18 parameters.
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 two sentences, front-loaded with the action and followed by a key usage pattern. No wasted words; it is appropriately compact for the purpose it serves.
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?
With 18 parameters, no output schema, and no annotations, the description is far too thin. It does not explain what happens on resume, what the tool returns, potential side effects, or how it differs from sibling resume tools. The agent is left to infer these from parameter names and schema descriptions, which is risky for such a complex 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?
Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter value by explicitly tying sessionId and continueLatest to specific backends, which is not immediately obvious from scanning the schema descriptions independently. This helps the agent select the right parameter combination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Bind cc-in-codex to an existing Claude Code conversation,' which clearly states the verb and resource. The second sentence adds backend-specific nuance (SDK vs TUI), but it does not explicitly differentiate from the sibling tool companion_tui_resume, which may cover a TUI-only resume path.
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 gives explicit usage guidance by backend: 'SDK needs sessionId; TUI can use sessionId or continueLatest:true.' This tells the agent what parameter is required in each mode. However, it does not explicitly state exclusions or when to use a different companion tool (e.g., companion_start for new sessions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the action ('run /compact') and mentions 'preservation instructions,' but does not explain potential consequences, side effects, or whether the operation is reversible. This is similar to a mutation tool lacking safety context.
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 short sentences, front-loaded with the action and ending with a practical directive. Every word earns its place with no redundant detail.
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?
No output schema or annotations, and the tool invokes a compaction action. The description lacks prerequisites, what the user should expect, and how the instruction parameter affects behavior, leaving significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% of parameters (instructions) have schema descriptions; cwd is undocumented. The description mentions 'preservation instructions' but does not clarify parameter roles or how cwd is used, failing to compensate for the low schema coverage.
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 uses a specific verb phrase 'Ask the visible Claude Code TUI to run /compact' and clearly identifies the resource and action. It distinguishes itself from sibling tools by naming the exact /compact operation and explicitly preferring companion_tui_compact_check first.
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?
It explicitly states 'Prefer companion_tui_compact_check first,' providing an alternative tool and a when-not-to-use signal. However, it does not fully explain prerequisites like whether a TUI must be visible or when compaction is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden. It discloses that the tool pastes the prompt and returns immediately with an attach command, which is key non-obvious behavior. However, it does not disclose potential side effects such as file modifications or tool execution by Claude Code, nor does it mention permission policies or stop-losses.
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 two concise sentences, front-loaded with the action and followed by the key return behavior. Every word earns its place.
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 tool has 16 parameters and no output schema, the description is minimal but does explain the return value (tmux attach command). However, it lacks prerequisite context (e.g., existing TUI session) and doesn't mention the backend flexible options or interplay with sibling tools, which is a gap for a complex tool.
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?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter-level information, but the schema already documents all 16 parameters with clear descriptions, including enums and defaults. No additional clarification is needed.
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 uses a specific verb ('Paste') and resource ('persistent native Claude Code TUI'), and explicitly notes the immediate return of the tmux attach command. This clearly distinguishes it from sibling tools like companion_tui_open or companion_send.
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 alternatives. It does not mention that an existing TUI session is needed or that companion_tui_open should be used to create one. The only implied context is 'persistent,' but there are no explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the operation is conditional ('if any') and scoped to a cwd, but it does not describe side effects, whether it is asynchronous, what happens to the turn after cancellation, or error/return behavior. This is a minimum viable disclosure with clear gaps.
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 a single concise sentence that front-loads the action and target. Every word contributes meaning: 'currently running' and 'if any' are valuable qualifiers. There is no waste.
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?
The tool is simple with one optional string parameter and no output schema, and the description covers the core action. However, it lacks context about what happens after cancellation, how the cwd parameter is used, and any relation to sibling tools. It is adequate but leaves important operational details implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter, and the description only mentions 'cwd' without explaining its meaning, format, or optionality. Since required parameters are 0, it is ambiguous whether omitting cwd applies globally or would fail. The description does not sufficiently compensate for the missing 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 identifies the action (cancel) and the target resource (currently running companion turn for a cwd). The phrase 'if any' adds a conditional that clarifies behavior. It is easily distinguishable from sibling tools like companion_send, companion_wait, and companion_reset.
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 when to use it (when a companion turn is running for a cwd) but does not explicitly mention alternatives or when not to use it. There is no guidance around prerequisites or differences from sibling tools like companion_reset or companion_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. 'Read' implies a non-destructive operation, and the analogy suggests a historical view, but the description does not mention any prerequisites (e.g., initialized companion), what exactly constitutes 'recent events', or any potential side effects. This leaves moderate gaps in transparency.
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 a single, well-structured sentence that is front-loaded with the action and resource, and it ends with a helpful analogy. Every word contributes value, with no redundancy or filler.
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 lack of annotations and no output schema, the description is relatively minimal. It conveys the core purpose but omits parameter semantics and any mention of the return format or behavior when no events are available. It is adequate for a basic understanding but not fully complete for a tool with optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation for the parameters 'cwd' and 'limit'. While 'limit' might be inferred as a count limiter, its exact scope and the role of 'cwd' (whether it scopes the companion context or file system) remain ambiguous. The description fails to compensate for the schema's lack of documentation.
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 uses the explicit verb 'Read' and a specific resource ('recent events from the persistent companion'), making the tool's primary function clear. The analogy 'similar to scrolling the Claude Code window' further clarifies the nature of the operation and distinguishes it from sibling tools like companion_send or companion_reset.
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 analogy provides clear contextual guidance on when to use this tool (to review recent context like scrolling a window), but it stops short of explicitly stating when not to use it or naming alternative tools. This is clear context without exclusions, fitting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It adds a key caveat ('heuristic, not a true token-limit reading') which prevents over-reliance. However, it doesn't explicitly state whether the tool is read-only or has side effects, nor describe the output format.
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 the action and purpose. The second sentence adds a necessary caveat. No wasted words, well-structured.
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?
The tool is relatively simple with optional parameters, but there is no output schema. The description doesn't explain the return value (e.g., boolean, score, message), which an agent would need to act on the result. It also doesn't mention prerequisites like whether the TUI must be open. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'lines' well with default and constraints, but 'cwd' has no description. The description text doesn't add meaning for either parameter, and with 50% schema coverage it doesn't compensate for the undocumented 'cwd' parameter.
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 function: inspecting the TUI and metadata to decide checkpoint readiness for /compact. It uses a specific verb ('inspect') and resource, and distinguishes itself from sibling tools like companion_tui_compact (which actually runs compact) and companion_tui_screen (which views the screen).
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 implies usage as a pre-check before running /compact, and warns that it is heuristic rather than a true token-limit reading. It doesn't explicitly name alternatives or exclusions, but the purpose is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core action (forgetting the binding) but does not specify whether the active companion process is terminated, whether the action is reversible, or any side effects on existing sessions. This leaves ambiguity for a destructive-sounding reset operation.
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 short sentences, front-loading the action, then providing a usage condition. There is no filler or redundancy; every word earns its place.
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?
For a simple tool with one optional parameter and no output schema, the description covers purpose and usage, but it leaves unanswered questions about side effects, return value, and cwd default behavior. The lack of annotations makes these gaps more significant.
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 input schema has no property descriptions (0% coverage) and the cwd is optional (0 required). The description mentions cwd as the target of the operation, which adds some meaning, but it does not explain the value format, what it represents beyond the abbreviation, or the behavior when omitted.
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 uses the specific verb 'Forget' and clearly names the resource ('project-to-Claude-session binding') scoped to a cwd. This distinguishes it from sibling tools like companion_init_project or companion_resume, and the added phrase 'fresh Claude Code companion' clarifies its unique role.
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?
It provides an explicit when-to-use: 'Use only when the user wants a fresh Claude Code companion.' However, it does not name alternative tools or describe when-not-to-use, so it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the behavioral disclosure burden. It reveals that the run is background, returns quickly with a runId, and should be monitored via other tools. This conveys asynchronous behavior and the need for polling. However, it does not mention potential side effects like process spawning, resource consumption, or backend-specific behaviors (e.g., tmux sessions for TUI backend), which are covered in the schema but not flagged as important behavioral traits.
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 only two sentences and front-loads the primary action. The first sentence states what the tool does; the second explains the return value and directs to monitoring tools. No wasted words. It is ideal in length and structure for a tool with a rich schema.
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 tool has 16 parameters and a rich schema, the description is concise but sufficient: it covers the core flow (start, get runId, monitor). It does not explicitly mention the distinction between new runs vs resuming/sending, but sibling names and schema cover that. It also doesn't highlight backend/security considerations, but those are in the schema. The description is complete enough for an AI agent to understand the tool's role without being verbose.
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?
Schema description coverage is 100%, so the schema already documents all 16 parameters with detailed descriptions. The tool description itself adds no parameter-related information, but the baseline of 3 applies because the schema does the heavy lifting. The description does not need to repeat parameter details, but it also doesn't add any extra semantic context (e.g., which parameters are most commonly used together).
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 states a specific action: 'Start a background Claude Code companion run for this cwd.' This clearly identifies the verb (start), resource (companion run), and scope (current working directory). It also distinguishes itself from sibling tools by mentioning the returned runId and directing to companion_status/recent/result for monitoring, which differentiates it from companion_send or companion_resume.
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 explicitly says to use companion_status/recent/result to monitor after starting, which is clear post-use guidance. However, it does not explicitly state when not to use this tool (e.g., preferring companion_send for follow-ups or companion_resume for existing runs), so it lacks explicit exclusions. Still, the context of 'background run' and 'returns quickly' implies asynchronous starting, which is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: sending literal text/tmux keys, not using the wrapper, and requiring an open session. It lacks details on failure modes or side effects like focus changes, making it adequate but not rich.
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?
Three short sentences cover purpose, examples, and prerequisite with no unnecessary wording. Information is front-loaded in the first sentence.
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 raw-input tool with no required params or output schema, the description provides purpose, usage examples, and a prerequisite. It doesn't address behavior when no TUI session exists, but given the low complexity, it's mostly complete.
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 already covers 75% of parameters with descriptions (keys, text, enter). The description adds context by mentioning slash commands and control keys, but does not clarify the 'cwd' parameter, which lacks a schema description. Thus it is baseline adequate but not compensating for gaps.
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 verb ('Send') and resource ('existing Claude Code TUI pane') and differentiates from siblings by noting 'without the cc-in-codex wrapper.' Examples of use cases further clarify its purpose.
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?
It specifies when to use it ('Use for slash commands (e.g. /clear), control keys (C-c), or Escape') and states the prerequisite ('Requires an open tui session'). However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It transparently states that files are created, existing files are skipped, and the 'force' flag changes this behavior. This is sufficient for a file-initialization tool, though it could mention whether force overwrites rather than merges.
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 a single, focused sentence that front-loads the primary action and integrates the key conditional behavior. No unnecessary words or filler.
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 tool is relatively simple with two parameters and no output schema. The description covers purpose, file behavior, and the force parameter, making it complete enough for an agent to invoke correctly. Minor gaps around cwd defaults do not significantly reduce completeness.
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?
Schema coverage is 0%, so the description must compensate for missing property descriptions. It effectively explains 'force' ('Existing files are skipped unless force=true') and implies 'cwd' as the project directory. However, it does not explain cwd's default value or whether it is required, leaving some ambiguity.
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 uses a specific verb ('Create') and names the exact resources ('AGENTS.md and CLAUDE.md') and location ('project cwd'). It clearly distinguishes this tool from siblings like companion_reset or companion_open, which serve different functions.
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 states why to use the tool ('so Codex and Claude Code share the same project instructions') and the condition for existing files, implying it is meant for project initialization. It does not explicitly name alternatives or when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the blocking behavior ('wait for completion') and scopes the task as 'short,' providing some behavioral context. However, with no annotations, it does not mention potential side effects, permission requirements, prerequisites (e.g., an already-running companion), or what happens on failure. This leaves a notable transparency gap.
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 exactly two sentences: the first states the core purpose and behavior, the second provides the key usage alternative. Every word earns its place, with no redundant or tangential information. It is front-loaded and easily scannable.
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 tool with 16 parameters and no output schema, the description explains the high-level usage and when to prefer an alternative. It doesn't explicitly describe the return value after 'wait for completion' (whether it returns the final result or just status), but the sibling tools like companion_result and companion_status partially fill that context. The description is sufficient for selecting the tool, though not exhaustive.
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?
Schema description coverage is 100% (16/16 parameters documented), so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but it does reinforce the 'short task' intent that aligns with the prompt parameter. This is adequate given the schema already carries full parameter documentation.
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 opens with a specific verb and resource: 'Send a short task or follow-up to the persistent Claude Code companion and wait for completion.' It clearly distinguishes from sibling tools by stating, 'For long coding work, prefer companion_start plus polling.' This unequivocally identifies the tool's scope and differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('short task or follow-up') and when not to ('long coding work'), naming the alternative (companion_start plus polling). This gives clear, actionable guidance on tool selection with a direct contrast against a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cc-in-codex MCP server](https://glama.ai/mcp/servers/Terry-Wang-Lynx/cc-in-codex/badges/card.svg)](https://glama.ai/mcp/servers/Terry-Wang-Lynx/cc-in-codex)

Score Badge

Copy to your README.md:

[![cc-in-codex MCP server](https://glama.ai/mcp/servers/Terry-Wang-Lynx/cc-in-codex/badges/score.svg)](https://glama.ai/mcp/servers/Terry-Wang-Lynx/cc-in-codex)

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/Terry-Wang-Lynx/cc-in-codex'

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