Enables orchestration of GitHub MCP tools for managing issues, repositories, and files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Conductor analyze my project's dependencies and check for updates"
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.
The canonical MCP hub for any agent platform. 99.7% fewer tokens. One npx command.
MCP Conductor is a single MCP server that orchestrates all your other MCP servers through a sandboxed Deno runtime. Works with Claude Code, Claude Desktop, Cursor, Gemini CLI, Codex CLI, Cline, Zed, Continue.dev, OpenCode, and Kimi Code. Instead of your AI client making direct tool calls (and dumping every intermediate result into your context window), it writes TypeScript code that runs in an isolated sandbox. Only the final result comes back.
Before: 153,900 tokens → AI client context window → 153,900 tokens billed
After: 153,900 tokens → Deno sandbox → 435 tokens → AI client context windowAverage measured reduction: 99.7%. Verified against Anthropic's published benchmarks.
Client | Config path (macOS) | Config path (Linux) | Config path (Windows) |
Claude Code |
|
|
|
Claude Desktop |
|
|
|
Cursor |
|
|
|
Gemini CLI |
|
|
|
Codex CLI |
|
|
|
Cline |
|
|
|
Zed |
|
|
|
Continue.dev |
|
|
|
OpenCode |
|
|
|
Kimi Code |
|
|
|
The setup wizard auto-detects every supported client on your machine and offers per-client consolidation:
npx -y @darkiceinteractive/mcp-conductor-cli@next setupSee What the wizard does below.
Paste the appropriate block into your client's config file. The wizard does this automatically.
Claude Code (~/.claude/settings.json):
{
"mcpServers": {
"mcp-conductor": {
"command": "npx",
"args": ["-y", "@darkiceinteractive/mcp-conductor"]
}
}
}Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"mcp-conductor": {
"command": "npx",
"args": ["-y", "@darkiceinteractive/mcp-conductor"]
}
}
}Cursor (~/.cursor/mcp.json):
{
"mcpServers": {
"mcp-conductor": {
"command": "npx",
"args": ["-y", "@darkiceinteractive/mcp-conductor"]
}
}
}For Codex CLI (TOML), Continue.dev (YAML), and other formats, use mcp-conductor-cli export --client <id> — see Multi-client export.
Restart your AI tool after editing the config. That's it.
Related MCP server: MCP of MCPs
Running npx -y @darkiceinteractive/mcp-conductor-cli@next setup steps through the following for each detected client:
Scan — discovers all 10 client config locations on your machine (global and project-local).
Diff — for each existing config, parses the current server list and shows what will move.
Confirm per-client — prompts once per client; you can skip any client individually.
Write conductor config — merges your existing servers into ~/.mcp-conductor.json and installs the conductor entry back into the client config.
Backup originals — creates a timestamped .bak.YYYYMMDDHHMMSS copy of every config file before modifying it.
In non-interactive environments (CI, piped stdin) the wizard proceeds automatically with safe defaults.
mcp-conductor-cli doctorThe doctor command runs a health check across all configured servers and prints an MCP CLIENT COVERAGE section showing every detected client config with an [OK] or [MISSING] status for the conductor entry.
MCP CLIENT COVERAGE
[OK] Claude Code ~/.claude/settings.json
[OK] Claude Desktop ~/Library/Application Support/Claude/claude_desktop_config.json
[OK] Cursor ~/.cursor/mcp.json
[MISSING] Zed ~/Library/Application Support/Zed/settings.jsonRun npx -y @darkiceinteractive/mcp-conductor-cli@next setup to install the conductor entry in any [MISSING] client.
Generate a ready-to-paste config snippet for any supported client:
# Codex CLI — writes TOML
mcp-conductor-cli export --client codex
# Continue.dev — writes YAML
mcp-conductor-cli export --client continue
# Claude Desktop — writes JSON (default)
mcp-conductor-cli export --client claude-desktopThe exported file is written to the current directory as <client>-config.<ext>. Pass --output <path> to override.
Full client setup documentation is at docs.darkice.co/setup/clients.
// Your AI client writes this code, which runs inside the Deno sandbox
const [issues, files] = await mcp.batch([
() => mcp.server('github').call('list_issues', { owner: 'myorg', repo: 'myrepo', state: 'open' }),
() => mcp.server('filesystem').call('list_directory', { path: '/src' })
]);
return {
openBugs: issues.filter(i => i.labels.some(l => l.name === 'bug')).length,
tsFiles: files.filter(f => f.name.endsWith('.ts')).length
};
// Returns: {"openBugs": 12, "tsFiles": 47} ← under 100 tokensWhen an AI client calls MCP tools directly, every response lands in the context window — raw JSON, file metadata, pagination objects, fields you never asked for. A single GitHub list_issues call can return 40,000+ tokens. If you're making 10 calls per task, that's 400,000 tokens before the model has written a single line of code.
MCP Conductor flips the model: the client writes TypeScript code that processes the tool responses inside a Deno sandbox. The sandbox can call any connected MCP server, filter and aggregate the results, and return only the compact summary. Your context window stays small. Your costs stay low.
Scenario | Without Conductor | With Conductor | Reduction |
300-document Drive pipeline | 153,900 tokens | 435 tokens | 99.72% |
GitHub issues triage (10 repos) | ~400,000 tokens | ~2,000 tokens | 99.5% |
Web research (5 searches) | ~50,000 tokens | ~800 tokens | 98.4% |
Feature | What it does | Docs |
Tool Registry | Schema validation, hot-reload, type generation | |
Response Cache | LRU + CBOR serialisation, TTL per tool | |
Reliability Gateway | Timeout, retry, circuit breaker | |
Connection Pool | Warm sandbox pool, persistent server connections | |
Sandbox API |
| |
Daemon Mode | Shared KV store, distributed lock | |
Observability | Cost predictor, hot-path profiler, session replay | |
Passthrough Adapter | Expose backend tools directly (X1) | |
Lifecycle Tools + CLI |
| |
PII Tokenisation | Built-in redaction matchers (X4) |
Feature | What it does |
Multi-client adapters | Read and write configs for all 10 supported clients |
Setup wizard (MC3) | Interactive per-client consolidation with backups |
Per-client export (MC4) |
|
Doctor client coverage (MC5) |
|
Migrating from v2? See the migration guide.
Pass show_token_savings: true on any execute_code call to see a breakdown:
{
"result": { "processed": 300, "with_dates": 287 },
"tokenSavings": {
"estimatedPassthroughTokens": 153900,
"actualExecutionTokens": 435,
"tokensSaved": 153465,
"savingsPercent": 99.72
}
}Or enable it globally in ~/.mcp-conductor.json:
{
"metrics": {
"alwaysShowTokenSavings": true
}
}Session totals are always available via get_metrics.
Full documentation at https://docs.darkice.co — deploys at D4. In the meantime, all reference material is in docs/v3/.
Guide | Description |
System design and data flow | |
All config options | |
The | |
Practical patterns and examples | |
Breaking changes and migration steps | |
Per-client config reference for all 10 supported clients |
# Guided multi-client setup — detects all supported client configs automatically
npx -y @darkiceinteractive/mcp-conductor-cli@next setup
# Health check with client coverage report
mcp-conductor-cli doctor
# Export config for a specific client (TOML for Codex, YAML for Continue, etc.)
mcp-conductor-cli export --client <client-id>
# Check system requirements (Node, Deno, conductor config)
mcp-conductor-cli check
# Show current configuration status
mcp-conductor-cli status
# Enable exclusive mode (routes all MCP calls through the sandbox)
mcp-conductor-cli enable-exclusive [--dry-run]
# Add a backend server
mcp-conductor-cli config add github npx -- -y @modelcontextprotocol/server-githubContributions welcome. Please read CONTRIBUTING.md for guidelines.
Bug reports: GitHub Issues
Discussions: GitHub Discussions
Security: See SECURITY.md
MIT — see LICENSE
Built by DarkIce Interactive · @darkiceinteractive/mcp-conductor on npm
Add a new MCP server to conductor config and connect immediately.
Saves the server configuration to ~/.mcp-conductor.json and triggers a reload. Use this to dynamically add servers without restarting Claude.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique server name (e.g., "github", "filesystem"). | |
| command | Yes | Command to run the server (e.g., "npx", "node", "python"). | |
| args | No | Command arguments (e.g., ["-y", "@modelcontextprotocol/server-github"]). | |
| env | No | Environment variables for the server (e.g., { "GITHUB_TOKEN": "..." }). |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| server_name | Yes | |
| config_path | Yes | |
| message | Yes | |
| servers_after | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false, etc. The description adds key behavioral details: 'Saves the server configuration to ~/.mcp-conductor.json and triggers a reload.' No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the action and efficient. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description does not need to explain return values. It covers purpose, side effects, and usage context sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema fully documents parameters. The description does not add parameter-level details beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('new MCP server to conductor config and connect immediately'), clearly distinguishing from siblings like remove_server, update_server, list_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use: 'Use this to dynamically add servers without restarting Claude.' It provides clear context but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search via Brave Search API. Uses 90% fewer tokens than native WebSearch.
Routes to brave-search MCP server internally. Requires brave-search server to be configured.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (max 400 chars, 50 words). | |
| count | No | Number of results (1-20, default 10). |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| results | No | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by noting token efficiency (90% fewer tokens) and configuration requirements. Annotations already provide readOnly and openWorld hints, so description complements without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: purpose with efficiency claim, internal routing, and configuration prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is sufficiently complete, covering purpose, efficiency, routing, and setup. Could mention result format but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description does not add new parameter information beyond what schema already provides. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Web search via Brave Search API' and distinguishes from 'native WebSearch', making the purpose specific and differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternatives are given. Mentions token efficiency but does not direct the agent on when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyse how a task would be handled in different modes. Returns estimated token usage and approach for each mode.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | Description of the task to analyse. | |
| estimated_tool_calls | No | Estimated number of tool calls needed. | |
| estimated_data_kb | No | Estimated data to process in KB. |
| Name | Required | Description |
|---|---|---|
| task | Yes | |
| modes | Yes | |
| recommendation | Yes | |
| token_savings_percent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds that the tool returns estimated token usage and approach, which aligns with these hints and provides additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no superfluous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety, an output schema available, and a clear description of what the tool returns, the description is complete for an analysis tool with few parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add significant meaning beyond the schema, meeting the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing how a task would be handled in different modes and returning estimated token usage and approach. This is a specific verb-resource combination that distinguishes it from siblings like 'predict_cost'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing mode behavior, but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnose a registered MCP server: process health, connection status, recent errors, reconnect attempts, last successful call, and registry state. Returns actionable information about why a server may be failing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name to diagnose (must be in conductor config). |
| Name | Required | Description |
|---|---|---|
| server_name | Yes | |
| status | Yes | |
| tool_count | Yes | |
| connected_at | No | |
| last_error | No | |
| reconnect_attempts | Yes | |
| is_connected | Yes | |
| registry_state | Yes | |
| suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent; description adds detail on what is diagnosed and that it returns actionable information, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, description covers purpose and key diagnostic areas, sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema coverage; description's mention of 'registered MCP server' aligns with schema's 'must be in conductor config', but adds little new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses a registered MCP server and lists specific aspects checked (health, connection, errors, etc.), distinguishing it from siblings like test_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for troubleshooting failing servers, but no explicit when-to-use or when-to-avoid compared to sibling tools like test_server or get_metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available tools across all connected MCP servers.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query. Matches against tool names and descriptions. | |
| server | No | Optional: limit search to a specific server. | |
| limit | No | Maximum results to return. Default: 20. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| total_matches | Yes | |
| servers_searched | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, read-only behavior. Description adds context that search is across all connected servers, which is beyond schema. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with key purpose. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has output schema, so explaining return values is less critical. Description is adequate for a search tool with well-documented parameters. Could mention search behavior (fuzzy, exact) but not necessary given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search for available tools across all connected MCP servers.' The verb 'Search' and resource 'tools across servers' are specific and differentiate from siblings like list_servers or get_capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_servers or get_capabilities. The description implies search usage but doesn't provide when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute TypeScript/JavaScript code to perform MCP operations efficiently.
Token Savings: 90-98% vs individual tool calls. Batch operations in a single execution.
API: mcp.server('name').call('tool', params) | mcp.searchTools('query') | mcp.log('msg')
Example: const files = await mcp.filesystem.call('list_directory', { path: '/src' }); return files;
Use passthrough_call only for debugging - it has HIGH token cost.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | TypeScript/JavaScript code to execute. Must include a return statement. | |
| servers | No | Optional: List of MCP server names to load. | |
| timeout_ms | No | Maximum execution time in milliseconds. Default: 30000. | |
| stream | No | If true, stream progress updates. Default: false. | |
| verbose | No | If true, include detailed metrics in response. Default: false. | |
| show_token_savings | No | If true, attach a tokenSavings block to the response estimating how many tokens execute_code saved versus calling the same tools in passthrough mode. The estimate uses the formula: passthrough = (toolCalls × 150) + (dataBytes / 1024 × 256); execution = ceil(codeChars / 3.5) + ceil(resultBytes / 3.8). Note: 256 tokens/KB is an observed average — actual savings vary by content. For passthrough-mode tools the block carries a "not applicable" note. Can also be enabled globally via metrics.alwaysShowTokenSavings in ~/.mcp-conductor.json. Default: false. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| result | No | |
| error | No | |
| metrics | No | |
| logs | No | |
| tokenSavings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not contradict. It adds value by explaining the execution environment, token savings, and API usage, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections for token savings, API, and example. It is front-loaded with the main purpose, but could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing code and the presence of an output schema, the description covers purpose, usage, API, token savings, and an example. It lacks explicit error handling instructions but is otherwise sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, baseline is 3. The description enhances understanding with an example and an explanation of the show_token_savings parameter's formula, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes TypeScript/JavaScript code for efficient MCP operations, with a specific verb and resource. It distinguishes itself from sibling tools like passthrough_call by highlighting token savings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: use for batch operations to save tokens, and use passthrough_call only for debugging due to high token cost. This helps the agent decide when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a mcpServers JSON block that points Claude back at mcp-conductor stdio. This is the rollback path: paste the output into your Claude Desktop or Claude Code config to restore direct connectivity. Formats: "claude-desktop" (full wrapper object), "claude-code" (flat mcpServers), "raw" (inner object only).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. | claude-desktop |
| conductor_path | No | Override the conductor binary path (default: npx @darkiceinteractive/mcp-conductor). |
| Name | Required | Description |
|---|---|---|
| json | Yes | |
| format | Yes | |
| server_count | Yes | |
| instructions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent; description adds that it generates a config block (non-destructive) and explains output format options, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff, front-loaded with main action, perfectly sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema handles return values; description covers generation purpose, formats, and usage context. Complete for a simple generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds clarity on format enum meanings and conductor_path purpose, surpassing baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an mcpServers JSON block to restore Claude connectivity, with specific verb 'Generate' and resource. It distinguishes from siblings by focusing on configuration export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the rollback context and use case ('paste the output into your Claude Desktop or Claude Code config'), providing clear when-to-use guidance without explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about MCP Executor capabilities and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| version | Yes | |
| current_mode | Yes | |
| features | Yes | |
| limits | Yes | |
| servers | Yes | |
| skills | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate those. The description adds that the tool returns 'detailed information,' which conveys a non-destructive, repeatable behavior. No further behavioral traits are necessary for this simple, parameterless tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose without extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, strong annotations (readOnly, idempotent), and an output schema, the description is largely complete. It could briefly note that capabilities are returned, but the output schema likely covers that detail, making the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (trivially). Per guidelines, baseline is 4 for no parameters. The description adds no parameter details, which is appropriate since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'detailed information about MCP Executor capabilities and configuration,' specifying both the action (get) and the resource (capabilities/configuration). This distinguishes it from sibling tools that add servers, execute code, or perform other distinct actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like list_servers or discover_tools. The description lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the top-K tool call paths by total latency or p99 within a rolling time window.
| Name | Required | Description | Default |
|---|---|---|---|
| sinceMs | No | Only include calls made in the last N milliseconds. | |
| topK | No | Maximum number of paths to return (default: 10). | |
| sortBy | No | Ranking dimension (default: totalLatency). |
| Name | Required | Description |
|---|---|---|
| paths | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds concrete behavioral details: it returns top-K paths sorted by latency/p99/callCount within a rolling window. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with no extraneous words. Information is front-loaded: verb, resource, key qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description need not detail return values. It covers the essential behavioral scope (time window, sorting). Could mention that sinceMs defines the rolling window, but not necessary for agent consumption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 3 parameters. Description adds minimal context ('top-K', 'rolling time window') but does not meaningfully enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Return', the resource 'top-K tool call paths', and the sorting criteria 'by total latency or p99'. It also specifies the time context 'within a rolling time window', distinguishing it from sibling tools like get_metrics or get_memory_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, exclusions, or when not to use it, leaving the agent without context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns live memory usage and resource counts for the conductor process. Use this to diagnose memory issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| heap_used_mb | Yes | |
| heap_total_mb | Yes | |
| rss_mb | Yes | |
| external_mb | Yes | |
| array_buffers_mb | Yes | |
| active_deno_processes | Yes | |
| connected_servers | Yes | |
| active_streams | Yes | |
| uptime_seconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns 'live' data and focuses on memory/resource counts, consistent with annotations. No contradictions or additional side effects noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core function and target (conductor process), second sentence adds practical use case. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters, strong annotations, and an output schema, the description fully covers purpose and usage context. No additional info needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters, so schema coverage is 100% by default. No parameter description needed; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'returns' and resource 'live memory usage and resource counts for the conductor process', clearly distinguishing from sibling tools like get_metrics or diagnose_server by focusing on memory diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to diagnose memory issues', providing clear context. Does not mention when not to use or alternatives, but the single-purpose nature makes this adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed aggregated metrics for the current session including token savings, performance, and usage patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| reset | No | Reset metrics after returning. | |
| include_details | No | Include detailed breakdowns (servers, tools, recent executions). |
| Name | Required | Description |
|---|---|---|
| session | Yes | |
| executions | Yes | |
| tokens | Yes | |
| performance | Yes | |
| data | Yes | |
| mode_breakdown | Yes | |
| current_mode | Yes | |
| tokenSavings | Yes | |
| details | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations claim readOnlyHint and idempotentHint are true, suggesting no state modification. However, the parameter 'reset' explicitly resets metrics, which is a destructive action. The description does not disclose this behavior, creating a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's purpose. It is concise but omits important details about parameters and side effects, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema exists and parameters are simple, the tool has a side-effect via the 'reset' parameter that is not described. This omission reduces completeness, especially given the annotations conflict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions (reset, include_details). The description adds some context about metric categories but does not significantly augment the schema's meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'detailed aggregated metrics for the current session' and specifies the types of metrics included (token savings, performance, usage patterns). This distinguishes it from sibling tools like get_memory_stats or get_hot_paths, which focus on different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for current session aggregated metrics. It does not explicitly mention when not to use it or suggest alternatives, but the context is clear enough for an agent to infer appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import MCP servers from Claude config files into ~/.mcp-conductor.json.
Reads ~/.claude/settings.json, ~/Library/Application Support/Claude/claude_desktop_config.json and other standard paths. Shows a diff of what will be imported. On confirm=true, copies entries into the conductor config and writes .bak backups of each source file. Optionally strips the imported servers from their source configs.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set true to actually perform the import. False (default) shows a dry-run diff. | |
| remove_originals | No | After import, remove the imported servers from their source Claude config files. |
| Name | Required | Description |
|---|---|---|
| dry_run | Yes | |
| sources_found | Yes | |
| total_imported | Yes | |
| total_skipped | Yes | |
| summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral context: it reads multiple paths, shows a diff, creates .bak backups, copies entries, and optionally removes originals. This fully discloses the side effects and safety measures, going well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: the first states the purpose, the second details sources, the third explains diff and confirm behavior, and the fourth covers optional stripping. There is no redundancy or fluff. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (not shown but confirmed), the description need not detail return values. It covers the entire workflow: source paths, dry-run vs actual import, backup creation, and optional removal. The tool is of moderate complexity, and the description is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: it explains that confirm=false shows a dry-run diff, while confirm=true performs the import with backups. It also clarifies the optional stripping behavior for remove_originals. This adds value beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Import MCP servers from Claude config files into ~/.mcp-conductor.json'. This immediately distinguishes it from siblings like add_server (individual addition) and export_to_claude (exporting to Claude), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit when-to-use or when-not-to-use guidance. It implies usage by describing what it does, but does not mention alternatives or conditions. For example, it could say 'Use this to bulk-import servers from Claude; for single server addition use add_server instead.' The current description leaves the decision to the agent based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all MCP servers connected through MCP Executor.
| Name | Required | Description | Default |
|---|---|---|---|
| include_tools | No | If true, include list of tool names. |
| Name | Required | Description |
|---|---|---|
| servers | Yes | |
| total_servers | Yes | |
| total_tools | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is clear. Description adds no extra behavior details but does not contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient and minimal; though some detail on parameters would improve without much verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with output schema; purpose is clear but misses explanation of the optional parameter and its effect on the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description; description does not add any additional meaning or context for the include_tools parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and resource 'all MCP servers connected through MCP Executor', distinguishing it from sibling tools like add_server, remove_server, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like add_server or diagnose_server; no context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
⚠️ DEBUGGING TOOL - Direct MCP tool call. HIGH TOKEN COST (10-100x vs execute_code).
Only use for debugging raw tool input/output. Use execute_code for all normal operations.
| Name | Required | Description | Default |
|---|---|---|---|
| server | Yes | Name of the MCP server to call. | |
| tool | Yes | Name of the tool to invoke. | |
| params | No | Parameters to pass to the tool. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| result | No | |
| error | No | |
| metrics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds critical behavioral traits: high token cost (10-100x vs execute_code) and its debugging-only nature, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 3 sentences, front-loaded with a warning emoji and key cost information. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a passthrough tool that calls other tools, the description covers purpose, cost, and usage restrictions. Output schema exists, so return values need not be explained. Complete given the tool's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with 100% description coverage. The description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a debugging tool for direct MCP tool calls, with a specific verb ('call') and resource ('tool'). It distinguishes from the sibling 'execute_code' by stating its debugging-only purpose and high token cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('only use for debugging raw tool input/output') and when not to use ('use execute_code for all normal operations'), providing clear guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict the token cost and latency of executing code based on historical samples for similar call patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code whose cost you want to estimate. |
| Name | Required | Description |
|---|---|---|
| estimatedInputTokens | Yes | |
| estimatedOutputTokens | Yes | |
| estimatedLatencyMs | Yes | |
| basedOn | Yes | |
| available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds value by specifying that predictions are 'based on historical samples for similar call patterns'. This gives context beyond annotations, though it could disclose limitations like accuracy depending on data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it could be slightly more structured (e.g., separating purpose from method). Still, it's concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one parameter, output schema present), the description is complete. It covers what the tool does and how it works, with no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'code' is fully described in the schema (100% coverage), and the description adds only the context of historical samples, not additional semantics for the parameter. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'predict' and the resource 'token cost and latency of executing code', distinguishing it from siblings like execute_code or get_metrics. It answers what the tool does precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cost estimation before execution but provides no explicit when-to-use, when-not-to-use, or alternatives. It lacks guidance on when this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply the X1 routing heuristic to one or all configured servers. Servers whose names match lightweight-payload patterns (search, calendar, email, etc.) are recommended as "passthrough". All others default to "execute_code" (safe default). Use apply=true to write the hints into conductor config.
| Name | Required | Description | Default |
|---|---|---|---|
| server_name | No | Analyse a single server (omit for all servers). | |
| apply | No | Write routing hints to ~/.mcp-conductor.json. |
| Name | Required | Description |
|---|---|---|
| recommendations | Yes | |
| applied | Yes | |
| config_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and readOnlyHint=false. The description adds behavioral context about the heuristic patterns and the apply flag writing to config, but does not contradict annotations. It lacks details on destruction or side effects beyond the config write, but the idempotent nature mitigates concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying essential information: main action, pattern logic, and apply behavior. It is front-loaded and concise, with 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, 100% schema coverage, and presence of an output schema, the description adequately covers the tool's behavior: heuristic, default action, and persistence option. It could mention that omitting server_name applies to all servers, but this is in the schema. Overall, it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, so schema_description_coverage is 100%. The description reinforces the optionality of server_name and the effect of apply=true, but does not add new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies the X1 routing heuristic to servers, classifying them as 'passthrough' or 'execute_code'. It uses a specific verb and resource ('Apply X1 routing heuristic to one or all configured servers') and distinguishes itself from sibling tools like execute_code and passthrough_call by focusing on routing recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for evaluating routing between passthrough and execute_code, and provides a conditional logic based on server names. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start recording all tool calls in the current session to a replay journal.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | No | Optional session ID. A UUID is generated if omitted. |
| Name | Required | Description |
|---|---|---|
| sessionId | Yes | |
| recordingPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating write operation (readOnlyHint=false) and non-idempotency (idempotentHint=false), the description adds minimal behavioral context—it does not explain what happens if called multiple times or whether it stops a previous recording. The description text is acceptable but not enhanced beyond annotation signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the purpose. No unnecessary words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no required arguments, output schema exists), the description is sufficient. The term 'replay journal' could be clarified but is likely defined elsewhere; overall, the description covers the essential behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter well-described in the schema. The description does not add further semantic detail about the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start recording'), the resource ('all tool calls in the current session'), and the output ('to a replay journal'). It distinguishes from siblings like 'replay_session' and 'stop_recording' which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'replay_session' or 'stop_recording'. No context about prerequisites or appropriate scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload MCP server configurations. Useful after modifying claude_desktop_config.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| added | Yes | |
| removed | Yes | |
| total_servers | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true and idempotentHint: false, indicating side effects. The description adds context by specifying the trigger (modifying config file) and the action (reloading configurations). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence without any fluff. Every word contributes to the tool's purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, an output schema, and annotations covering behavioral aspects, the description is complete. It explains what the tool does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter information. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name and title clearly indicate the action (reload) and resource (server configurations). The description provides a specific verb and resource, and it differentiates from siblings like add_server, remove_server, list_servers by focusing on reloading configurations after modifying a config file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: 'after modifying claude_desktop_config.json.' While it does not list alternative tools or when not to use, the context is clear and the use case is well-defined among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an MCP server from conductor config and disconnect it.
Removes the server configuration from ~/.mcp-conductor.json and triggers a reload. Use this to dynamically remove servers without restarting Claude.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the server to remove. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| server_name | Yes | |
| config_path | Yes | |
| message | Yes | |
| servers_after | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable context: it removes from a specific config file, triggers a reload, and works dynamically without requiring a restart. This fully leverages the description beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a usage note. Every sentence provides essential information without repetition or fluff. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with full schema coverage, rich annotations, and an output schema, the description is largely complete. It covers purpose, mechanism, and usage context. Minor omission: no mention of behavior if the server name does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is fully described in the schema with 100% coverage. The description does not add any additional semantic meaning or constraints (e.g., case sensitivity, behavior if server not found). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove an MCP server from conductor config and disconnect it'), specifies the effect (config removal and reload), and distinguishes itself from sibling tools like add_server or update_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'to dynamically remove servers without restarting Claude,' providing clear when-to-use context. However, it does not mention when not to use or explicitly contrast with alternatives, though siblings are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay a recorded session, optionally applying modifications. Detects divergence when replayed result differs from recorded result.
| Name | Required | Description | Default |
|---|---|---|---|
| recordingPath | Yes | Path to the .jsonl recording file. | |
| modifications | No | Optional list of modifications to apply during replay. |
| Name | Required | Description |
|---|---|---|
| result | No | |
| divergence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds divergence detection behavior beyond annotations, which already indicate read-only and idempotent properties. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate description for a tool with high schema coverage and annotations; mentions key behaviors but could elaborate on divergence detection outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond confirming the optional modifications parameter. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replays a recorded session and can optionally apply modifications, distinguishing it from sibling tools like record_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch between operation modes:
execution: All requests go through the code executor (default, maximum token savings)
passthrough: Direct tool calls without code execution (for debugging/comparison)
hybrid: Automatic selection based on task complexity
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | The operation mode to switch to. |
| Name | Required | Description |
|---|---|---|
| previous_mode | Yes | |
| current_mode | Yes | |
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the agent knows it changes state and is safe to reapply. The description adds that modes are switched but does not elaborate on side effects like whether ongoing operations are affected or if mode changes persist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single introductory sentence followed by a bullet list of three modes. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter with full enum documentation and an existing output schema (not shown but present), the description covers all necessary context: what the tool does, the available modes, and their use cases. No further information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the mode parameter with enum values and a clear description. The tool description merely repeats the enum values without adding extra semantic detail, so it does not significantly enhance schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool switches between operation modes, listing three specific modes. It distinguishes itself from siblings like compare_modes and recommend_routing by focusing on changing the mode, not comparing or routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when each mode is appropriate (e.g., 'maximum token savings' for execution, 'debugging/comparison' for passthrough, 'automatic selection' for hybrid). However, it does not explicitly state when not to use this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop an active recording session and finalise the replay journal.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | Session ID returned by record_session. |
| Name | Required | Description |
|---|---|---|
| recordingPath | Yes | |
| eventCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveness is not indicated. The description adds that the tool 'finalises the replay journal', implying a state change beyond just stopping. However, no details are given about side effects, permissions, or error conditions, which would be valuable given the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose efficiently with no redundant words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and an existing output schema, the description fully covers the tool's purpose and outcome. It is complete enough for effective invocation, especially given that annotations already provide behavioral hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'sessionId' described as 'Session ID returned by record_session.' The description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'stop' and the resource 'active recording session', and specifies the outcome 'finalise the replay journal'. It distinguishes itself from sibling tools like 'record_session' and 'replay_session' by focusing on termination of an active session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to stop vs. replay). It does not mention prerequisites, conditions, or exclusions, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transiently connect to a named MCP server from conductor config, list its tools and measure latency. Does NOT persist the connection or register the server. The server must be present in ~/.mcp-conductor.json.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Server name in conductor config to test. | |
| timeout_ms | No | Connection timeout in milliseconds. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| server_name | Yes | |
| connected | Yes | |
| tool_count | Yes | |
| tools | Yes | |
| latency_ms | Yes | |
| error | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: transient connection, non-persistence, listing tools, and latency measurement. No contradictions; the description complements annotations effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant words. The first sentence delivers the core action; the second provides critical caveats. Perfectly front-loaded and succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description covers purpose, behavior, prerequisites, and exclusions. With output schema present, return values need no explanation. Complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear parameter definitions. The description does not add additional semantics beyond what the schema already provides for 'name' and 'timeout_ms'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Transiently connect'), names the resource ('MCP server from conductor config'), and lists key actions ('list its tools and measure latency'). It clearly distinguishes from siblings like 'add_server' or 'diagnose_server' by emphasizing transience and non-persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: for transient testing of a configured server. Provides clear exclusion ('Does NOT persist the connection or register the server') and a prerequisite ('server must be present in ~/.mcp-conductor.json'). No sibling tool offers the same function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing MCP server's configuration (command, args, or env vars).
Use this to update API keys or other settings without removing and re-adding the server. Triggers a reload to apply changes immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the server to update. | |
| command | No | New command (optional, keeps existing if not provided). | |
| args | No | New arguments (optional, keeps existing if not provided). | |
| env | No | Environment variables to update (merges with existing). | |
| replace_env | No | If true, replace all env vars instead of merging (default: false). |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| server_name | Yes | |
| config_path | Yes | |
| message | Yes | |
| updated_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations by stating that updates trigger a reload. Annotations indicate destructiveHint=true and idempotentHint=true, and description does not contradict. Implicitly notes merge behavior for env vars.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load purpose and then provide usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what can be updated, that it triggers reload, and a common use case. With an output schema present, return values are handled. Could mention that server must exist, but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds marginal value by mentioning merge behavior for env and the replace_env option, but most parameter meaning is already in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'MCP server's configuration', listing specific fields (command, args, env vars). It distinguishes itself from siblings like add_server and remove_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case (updating API keys without removal) and notes that triggering a reload applies changes immediately. Does not explicitly mention when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v3.1.1add_serverbrave_web_searchcompare_modesdiagnose_serverdiscover_toolsexecute_codeexport_to_claudeget_capabilitiesget_hot_pathsget_memory_statsget_metricsimport_servers_from_claudelist_serverspassthrough_callpredict_costrecommend_routingrecord_sessionreload_serversremove_serverreplay_sessionset_modestop_recordingtest_serverupdate_serverEvery tool has a clearly distinct purpose. Even similar tools like execute_code and passthrough_call are explicitly differentiated in their descriptions for efficient vs debugging use. No two tools appear to perform the same function.
All tool names use snake_case and follow a consistent verb_noun or get_noun pattern (e.g., add_server, get_metrics, list_servers). The naming convention is uniform and predictable across all 24 tools.
With 24 tools, the set is on the high side (16-25 being 'heavy' per rubric). While each tool serves a clear role, the count feels slightly bloated, especially with tools like brave_web_search that seem peripheral to the core conductor functionality.
The tool surface covers most expected operations: CRUD for server configuration, diagnostics, execution, metrics, recording/playback, mode switching, and import/export. A minor gap is the lack of a disable/enable tool for individual servers, but overall it is comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server to manage a restaurant menu from AI agents - 39 tools over the DuckHub API.
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/darkiceinteractive/mcp-conductor'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
