The claude-mcp-bridge server wraps the Claude Code CLI as MCP tools, enabling any MCP-compatible client (Cursor, VS Code, Windsurf, etc.) to leverage Claude's AI capabilities.
query: Execute prompts with optional file context (text/images), effort control (low/medium/high/max), per-call budget caps, session resume for multi-turn conversations, and a working directory for project-aware responses.
structured: Generate JSON output validated against a provided JSON Schema — ideal for data extraction, classification, and machine-parseable output.
search: Perform web searches via Claude's WebSearch/WebFetch tools, returning synthesized answers with source URLs.
listSessions: Retrieve metadata for active Claude CLI sessions (model, cost, turn count, timestamps).
ping: Health check verifying CLI installation, authentication status, and server configuration — no cost incurred.
Across all tools: every response includes execution metadata (_meta) with duration, model, session ID, cost, and token breakdowns. The server also handles concurrency management (up to 3 subprocesses), fallback models on quota exhaustion, and supports both subscription (claude login) and API key authentication.
MCP server that wraps Claude Code CLI as a subprocess, exposing its capabilities as Model Context Protocol tools.
Works with any MCP client: Codex CLI, Gemini CLI, Cursor, Windsurf, VS Code, or any tool that speaks MCP.
If you're in a terminal agent (Codex CLI, Gemini CLI) with shell access, call Claude Code CLI directly:
# Analyze specific files
claude -p --bare --tools Read -- "Analyze src/utils/parse.ts for edge cases"
# With budget cap
claude -p --bare --max-budget-usd 0.50 "Is this retry logic sound?"--bare skips hooks, memory, and plugins for clean subprocess use. --tools restricts which tools Claude can use at all; --allowed-tools only pre-approves permission and leaves everything else, including Bash, still reachable. --max-budget-usd prevents runaway costs.
--tools is variadic, so end the list with -- (or another flag) before the prompt. Without it the prompt is read as one more tool name and the CLI exits with "Input must be provided".
For code review, see Code review with this CLI.
Use this MCP bridge instead when:
Your client has no shell access (Cursor, Windsurf, Claude Desktop, VS Code)
You need structured output with native --json-schema validation
You need session resume across calls (--resume SESSION_ID)
You need concurrency management and security hardening
You want cost metadata surfaced in MCP responses
Related MCP server: consult-mcp
npx claude-mcp-bridgeClaude Code CLI installed and on PATH
Authentication (one of):
Subscription (default): claude login (uses your Pro/Max plan, no API credits needed)
API key: set ANTHROPIC_API_KEY + CLAUDE_BRIDGE_USE_API_KEY=1 (billed per use via console.anthropic.com)
Add to ~/.codex/config.json:
{
"mcpServers": {
"claude-bridge": {
"command": "npx",
"args": ["-y", "claude-mcp-bridge"]
}
}
}Add to ~/.gemini/settings.json:
{
"mcpServers": {
"claude-bridge": {
"command": "npx",
"args": ["-y", "claude-mcp-bridge"]
}
}
}Add to your MCP settings:
{
"claude-bridge": {
"command": "npx",
"args": ["-y", "claude-mcp-bridge"],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-...",
"CLAUDE_BRIDGE_USE_API_KEY": "1"
}
}
}Tool | Description |
query | Execute prompts with file context, session resume, effort control, and budget caps. Supports text and images. For code review, see Code review with this CLI. |
search | Web search via Claude CLI's WebSearch and WebFetch tools. Returns synthesized answers with sources. |
structured | JSON Schema validated output via Claude CLI's native |
ping | Health check with CLI version, auth method, capabilities, and model config. |
listSessions | List active sessions with cumulative cost, turn count, and timestamps. |
Execute a prompt with optional file context. Supports session resume via sessionId, effort control (low/medium/high/max), and budget caps (maxBudgetUsd). Images (.png, .jpg, .gif, .webp, .bmp) up to 5MB each are passed to Claude's Read tool.
Key parameters: prompt (required), files, model (default sonnet), sessionId, effort, maxBudgetUsd, workingDirectory, timeout (default 60s).
Web search powered by Anthropic's WebSearch tool via Claude CLI. Returns synthesized answers with source URLs.
Key parameters: query (required), model (default sonnet), maxResponseLength, maxBudgetUsd, timeout (default 120s).
Generate JSON conforming to a provided schema using Claude CLI's native --json-schema flag. Returns clean JSON in the first content block, metadata in a separate block so JSON parsing isn't broken.
Key parameters: prompt (required), schema (required, JSON string, max 20KB), files, model (default sonnet), sessionId, maxBudgetUsd, timeout (default 60s).
No parameters. Returns CLI version, auth method (subscription/api-key/none), configured models, capabilities, and server version.
No parameters. Returns active sessions with metadata: sessionId, model, createdAt, lastUsedAt, turnCount, totalCostUsd.
All tools attach execution metadata (_meta) with durationMs, model, sessionId, totalCostUsd, and token breakdowns. See DESIGN.md for details.
Variable | Default | Description |
| Shared default for all tools | |
|
| Default for query |
|
| Default for structured |
|
| Default for search |
|
| Fallback on quota exhaustion ( |
Model resolution: explicit parameter > tool-specific env var > CLAUDE_DEFAULT_MODEL > built-in default.
Variable | Default | Description |
|
| Max concurrent subprocess spawns |
|
| Path to CLI binary |
| Global cost cap in USD (per call) | |
| API key (only forwarded when | |
| Set to |
Variable | Default | Description |
|
| Default effort for search |
| Default effort for query |
Each spawned subprocess gets an explicit built-in toolset. The defaults are read-only, so Bash, Write and Edit are not granted unless you widen them below.
Variable | Default | Description |
|
| Built-in tools for query |
|
| Built-in tools for structured |
|
| Built-in tools for search |
Accepts a comma or space separated list, default for the CLI's full built-in set, or an empty value for no tools. Widening these gives the subprocess real capability in the working directory you pass it. See SECURITY.md § Tool Sandboxing.
You need... | Consider |
Structured output, effort/budget control, session resume, cost metadata | This bridge |
Multi-tool orchestration (read, grep, edit, bash as separate MCP tools) | |
Session continuity with async execution | |
Maintained lightweight wrapper | |
Native Claude Code MCP (built-in, no wrapper) |
|
Claude Code CLI has minimal startup overhead. Wall time is dominated by model inference and any agentic exploration.
Scenario | Typical time |
Trivial prompt (sonnet) | 5-10s |
Web search + synthesis | 15-30s |
Cost metadata (totalCostUsd, token breakdowns) is returned in _meta on every response.
Two MCP servers, same architecture, different underlying CLIs. Each wraps a terminal agent as a subprocess and exposes it as MCP tools. Pick the one that matches your model provider, or run both for cross-model workflows.
CLI | Claude Code | Codex CLI |
Provider | Anthropic | OpenAI |
Tools | query, search, structured, ping, listSessions | codex, search, query, structured, ping, listSessions |
Code review | Use Claude Code built-ins directly (not via this bridge), or |
|
Structured output | Native | Ajv validation |
Session resume | Native | Session IDs with multi-turn |
Budget caps | Native | Not supported |
Effort control |
| Not supported |
Cold start | ~1-2s | <100ms (inference dominates) |
Auth |
|
|
Cost | Subscription (default) or API credits (opt-in) | Pay-per-token |
Concurrency | 3 (configurable) | 3 (configurable) |
Model fallback | Auto-retry with fallback model | Auto-retry with fallback model |
Both share: subprocess env isolation, path sandboxing, output redaction, FIFO concurrency queue, MCP tool annotations, _meta response metadata, progress heartbeats.
The reviewer prompt is supplied by the caller. The bridge does not bundle review prompts (see ADR-001).
In Claude Code (interactive REPL): use the built-in /review, /security-review, /ultrareview. REPL-only; not reachable via claude -p or this bridge.
Through this bridge (query / structured): pass the review prompt as plain text. Slash commands (built-in or user-installed ~/.claude/commands/) do not resolve through the bridge, the isolation flags (--bare on the API-key path, --setting-sources "" on the subscription path) block all skill resolution by design. Tracked upstream: anthropics/claude-code#37207.
Direct claude -p (no bridge): user skills resolve as /skill-name when no isolation flags suppress them. For subprocess-isolated review use the hardened invocation below.
Route based on where you are:
Already in Claude Code? Type /review, /security-review, or /ultrareview. Skip the rest of this section.
Calling from another MCP host (Cursor, Codex CLI, Gemini CLI, Claude Desktop)? Slash commands and skills are not reachable through the bridge. Pass your review prompt as plain text to query / structured, or invoke claude -p directly per below.
claude -p invocation (subprocess-isolated)For shell-equipped consumers (terminal agents, CI, BYOS skills), invoke the CLI directly with hardened isolation flags:
claude -p \
--permission-mode plan \
--bare \
--add-dir <repo-root> \
--strict-mcp-config \
--mcp-config '{"mcpServers":{}}' \
--no-session-persistence \
--max-budget-usd 0.50 \
"<your review prompt + diff or file references>"--permission-mode plan: read-only.
--bare: strips parent's hooks, plugins, auto-memory, and CLAUDE.md autoload.
--add-dir <repo-root>: makes the repo's CLAUDE.md / AGENTS.md available where the diff warrants it.
--strict-mcp-config --mcp-config '{"mcpServers":{}}': blocks parent's MCP servers from leaking in. The inner mcpServers key is required; the schema rejects bare '{}'.
--no-session-persistence: no session files for one-off reviews.
--max-budget-usd: per-call cost cap.
For Claude Code users who want a reusable command, drop this into ~/.claude/commands/review-claude.md:
---
description: Code review via subprocess-isolated claude -p
---
Run code review on the diff between origin/main and HEAD.
```bash
claude -p \
--permission-mode plan \
--bare \
--add-dir "$(git rev-parse --show-toplevel)" \
--strict-mcp-config \
--mcp-config '{"mcpServers":{}}' \
--no-session-persistence \
--max-budget-usd 0.50 \
"Review the diff below for bugs, missing error handling on user input, tests modified to silence failures, and security issues (injection, missing auth checks, secret leaks). For each finding cite file:line, severity, and a suggested fix. Skip style/formatting.
$(git diff origin/main...HEAD)"
```A starting point; adapt freely:
Review the following diff:
<diff content>
Look for:
- Bugs that would surface in production
- Missing error handling on user-supplied input
- Tests modified to silence failures rather than verify behaviour
- Security issues (injection, missing auth checks, secret leaks)
For each finding cite file:line, severity (high/medium/low), and a suggested fix.
Skip style/formatting; assume an autoformatter handles those.npm install
npm run build # Compile TypeScript
npm run dev # Watch mode
npm test # Run tests (vitest)
npm run lint # ESLint
npm run typecheck # tsc --noEmit
npm run smoke # Smoke test against live CLIDESIGN.md - Architecture, sessions, cost tracking, response metadata, progress notifications
SECURITY.md - Environment isolation, path sandboxing, output redaction, tool sandboxing
CHANGELOG.md - Release history
MIT
List active Claude CLI sessions tracked by this server. Returns session metadata (IDs, models, timing, turn counts, cumulative cost) for orchestration. Use to check available sessions before resuming with sessionId. No cost (local lookup only).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly and idempotent. Description adds 'No cost (local lookup only)', clarifying behavior 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 sentences, front-loaded with purpose, no redundant information. Each sentence contributes unique 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?
Covers purpose, return content, usage context, and cost. No output schema, so description fully compensates. All necessary information present.
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?
No parameters exist, so schema coverage is 100%. Baseline 3 applies; description adds value by listing return fields but not required.
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 'List active Claude CLI sessions' with specific resource and verb. It distinguishes from siblings like search and query by focusing on sessions tracked by this server, making it unique.
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 explicit usage guidance: 'Use to check available sessions before resuming with sessionId.' Does not state when not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check: verifies Claude CLI is installed and authenticated, reports versions, capabilities, and configuration. No cost (local check only).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds that it's local only and costless, providing extra behavioral context beyond annotations 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?
Two concise sentences that front-load the purpose and include all necessary details without waste.
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 tool with no parameters, rich annotations, and no output schema, the description fully covers purpose, scope, and cost, making it complete for agent 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?
No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4, and no additional parameter info needed.
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 tool performs a health check for Claude CLI, verifying installation, authentication, and reporting versions, capabilities, configuration. It is specific and distinguishes itself from sibling tools that handle data retrieval.
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 notes 'No cost (local check only)', implying when to use (verify setup) and when not (no remote calls). While it doesn't explicitly compare to siblings, the purpose is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a prompt via Claude Code CLI with optional file context and session resume. Claude is an AI coding agent that can generate, analyze, refactor, and explain code.
Capabilities: code generation and refactoring, code analysis and explanation, file understanding (text and images), multi-turn conversations via sessionId.
Cost: Default model is Sonnet (~$0.01-0.10/call). Use effort="low" for simple tasks, effort="high" + model="opus" for complex analysis. Set maxBudgetUsd to cap per-call cost (recommended for effort="max" or model="opus").
Tips:
Set workingDirectory to the target repo for project-aware responses.
Break complex tasks into focused prompts rather than one large request.
Resume multi-turn conversations with sessionId from a previous response's metadata.
Include relevant files via the files parameter for targeted context (text files inlined in prompt, images trigger allowed-tools mode).
Use noSessionPersistence=true for stateless one-shot calls.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | File paths (text or images) relative to workingDirectory | |
| model | No | Model alias or full Claude model name | |
| effort | No | Effort level: low, medium, high, or max (passed to --effort) | |
| prompt | Yes | The prompt to send to Claude | |
| timeout | No | Timeout in milliseconds (default: 60000, image queries: 120000) | |
| sessionId | No | Claude session ID to resume with --resume | |
| maxBudgetUsd | No | Maximum cost budget in USD for this call (passed to --max-budget-usd) | |
| resetSession | No | Clear stored session state before execution (use with sessionId to start fresh) | |
| workingDirectory | No | Working directory for file resolution and CLI execution | |
| maxResponseLength | No | Soft limit on response length in words | |
| noSessionPersistence | No | Disable session persistence for ephemeral print calls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive and non-idempotent behavior with open-world hint. The description adds context: capabilities, cost structure, session management, and limitations like image query timeout. No contradiction with annotations; the tool's potential to generate/refactor code is noted but not claimed to modify persistent 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 fairly lengthy but front-loaded with the core purpose, followed by capabilities, cost, and tips. It is well-structured but could be slightly more concise without losing 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?
Given the tool's complexity (11 parameters, no output schema), the description is comprehensive: covers purpose, usage, parameter semantics, cost, and practical tips. It adequately equips an agent to understand when and how to invoke the 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 description coverage is 100%, and the description adds valuable meaning beyond each parameter's schema: explains files as text/images, sessionId for resume, maxBudgetUsd as cost cap, effort levels, and workingDirectory for context. Tips further clarify parameter usage.
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 'Execute a prompt via Claude Code CLI' and lists capabilities like code generation, analysis, and multi-turn conversations. It distinguishes itself from sibling tools (listSessions, ping, search, structured) by focusing on prompt execution with optional file context and session resume.
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 extensive usage guidance: cost info, effort levels for different task complexities, tips for workingDirectory, breaking tasks, resuming sessions, including files, and stateless calls. However, it does not explicitly compare this tool to siblings (e.g., when to use search instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Web search via Claude Code CLI using WebSearch and WebFetch tools. Searches the web and synthesizes a comprehensive answer with source URLs.
Use for: current information, documentation lookups, API references, comparing libraries, and research questions.
Cost: Typically ~$0.02-0.05/search with Sonnet.
Tips:
Ask specific, focused questions for best results.
Results include source URLs for verification.
Use maxResponseLength to control response verbosity.
Increase timeout for complex research queries that may require multiple web fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model alias or full Claude model name | |
| query | Yes | Search query or question | |
| effort | No | Effort level: low, medium, high, or max (default: medium for search) | |
| timeout | No | Timeout in milliseconds | |
| sessionId | No | Claude session ID to resume with --resume | |
| maxBudgetUsd | No | Maximum cost budget in USD for this call (passed to --max-budget-usd) | |
| workingDirectory | No | Working directory for the CLI | |
| maxResponseLength | No | Soft limit on response length in words | |
| noSessionPersistence | No | Disable session persistence for ephemeral print calls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations: cost estimates, recommendation to increase timeout for complex queries, and that results include source URLs. However, it does not clarify the non-read-only nature (readOnlyHint=false) or any side effects, leaving some behavioral traits implicit.
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 concise: a clear opening sentence, bullet points for use cases and tips, and a cost note. It is front-loaded with purpose and well-structured, with no redundant sentences.
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 tool with 9 parameters and no output schema, the description covers purpose, use cases, cost, and practical tips. It could mention result pagination or format details, but overall it provides sufficient context for an AI agent to use the tool effectively.
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?
All 9 parameters have schema descriptions (100% coverage). The description adds practical usage guidance for maxResponseLength, timeout, and effort, helping the agent understand how to use them effectively beyond what the schema provides.
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 performs web search via Claude Code CLI and synthesizes a comprehensive answer with source URLs. It is distinct from sibling tools like listSessions, ping, query, and structured, which serve 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 explicitly lists use cases (e.g., current information, documentation lookups) and provides tips (e.g., ask specific questions, use maxResponseLength). It does not specify when not to use or compare directly with alternatives, but the context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate JSON conforming to a provided JSON Schema. Uses Claude CLI's native --json-schema flag for validated output (not client-side validation).
Use for: data extraction from text/files, classification, entity parsing, or any task needing machine-parseable output.
Cost: Similar to query (~$0.01-0.10/call). Schema complexity doesn't significantly affect cost.
Tips:
Pass the JSON Schema as a JSON string in the schema parameter.
Schema max size: 20KB. Keep schemas focused for reliable output.
For extraction tasks, include source text via the files parameter or inline in the prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Text file paths to include as context | |
| model | No | Model alias or full Claude model name | |
| prompt | Yes | What to generate or extract | |
| schema | Yes | JSON Schema as a JSON string | |
| timeout | No | Timeout in milliseconds (default: 60000) | |
| sessionId | No | Claude session ID to resume with --resume | |
| maxBudgetUsd | No | Maximum cost budget in USD for this call (passed to --max-budget-usd) | |
| workingDirectory | No | Working directory for file resolution and CLI execution | |
| noSessionPersistence | No | Disable session persistence for ephemeral print calls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true) provide basic safety signals. The description adds valuable behavioral context: it uses native CLI validation (not client-side), cost is ~$0.01-0.10/call and unaffected by schema complexity, and it is designed for machine-parseable output. These details go beyond what annotations convey.
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 concise: a lead sentence stating the core function, then a brief use case bullet, a cost note, and a tips section. Every sentence serves a purpose with no redundancy. The structure is front-loaded with the most important 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?
Given the tool has 9 parameters, no output schema, and moderate complexity, the description covers the essential aspects: purpose, use cases, cost, and parameter tips. It could mention default behavior (e.g., timeout default of 60000) or error handling, but the parameter schema covers most details. Overall, it is sufficiently complete for an agent to use 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?
All 9 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds extra meaning: for the 'schema' parameter it notes 'Pass the JSON Schema as a JSON string' and 'Schema max size: 20KB'; for 'files' it explains 'include source text via the files parameter or inline in the prompt.' These tips improve parameter understanding beyond the schema alone.
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 'Generate JSON conforming to a provided JSON Schema' using a specific implementation (Claude CLI's --json-schema flag). It lists concrete use cases like data extraction, classification, and entity parsing, which distinguish it from sibling tools such as 'query' (likely free-form) and 'search' (retrieval).
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 says 'Use for: data extraction from text/files, classification, entity parsing, or any task needing machine-parseable output.' It also provides practical tips (schema max size, including source text via files parameter) but does not explicitly state when not to use this tool or mention alternatives beyond implying it's better than client-side validation.
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.
v0.6.0listSessionspingquerysearchstructuredEach tool serves a clearly distinct purpose: listing sessions, health checking, executing prompts, web searching, and structured JSON generation. No overlap or ambiguity.
Tool names follow no consistent pattern: 'listSessions' uses camelCase verb_noun, 'ping' and 'query' are single-word verbs, 'search' is a verb, 'structured' is an adjective. Mixing conventions makes the naming unpredictable.
With 5 tools covering session management, health check, code query, web search, and structured output, the count is well-scoped for the server's purpose of bridging to Claude CLI.
The tool set covers the core intended actions (query, search, structured output) and adds session listing and health check. Minor gaps exist (no tool to create or manage sessions beyond listing), but agents can work around them.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hampsterx/claude-mcp-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
