Claude Bridge
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Tools are mostly distinct: send/receive/clear/status are clearly separated by purpose. However, bridge_status (last N messages from all channels) overlaps slightly with bridge_receive, which could cause minor confusion about which to use for broad monitoring.
Naming Consistency5/5All tools consistently use the pattern 'bridge_<verb>', with verbs that clearly describe the action (send, receive, channels, ping, clear, status). No mixing of cases or irregular naming.
Tool Count5/5With 6 tools, the count is well-scoped for an inter-agent messaging bridge. Each tool covers a distinct operation, and there's no bloat or deficiency.
Completeness3/5The core messaging lifecycle is covered (send, receive, clear, check status, list channels). However, missing capabilities like channel creation (if not implicit), message deletion by ID, or direct addressing of specific agents could be gaps in practical multi-agent workflows.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the tool checks aliveness and returns a status summary, but does not describe the output format, error behavior (e.g., if the server is down), or whether it is purely read-only. The lack of detail leaves the agent uncertain about the tool's side effects and return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the essential purpose without any extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally complete but lacks critical details. It does not explain the return value structure, error handling, or how it differs from the overlapping bridge_status sibling. The agent would need to infer or test to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage trivially), so the description does not need to add parameter details. It adds no extra meaning beyond the schema, which is acceptable for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Check if the bridge server is alive and get a status summary.' It uses specific verbs and identifies the resource. While it distinguishes from tools like bridge_send and bridge_receive, it does not explicitly differentiate from the sibling bridge_status, which could overlap in providing a status summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., bridge_status, bridge_channels). There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool has no annotations, so the description carries full burden. It mentions 'ALL channels' and the per_channel parameter, but does not disclose whether the tool is read-only, if results change over time, or any rate limits. Given the read-like nature, basic safety context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key purpose and usage context. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with full schema coverage, no output schema, and the description adds some context, it is adequate but could be improved by mentioning the return format or when to use this over siblings like bridge_receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is well-described in the schema. The description adds further context by indicating it applies per channel, which aligns with the schema. Minimal additional value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the last N messages from ALL channels, distinguishing it from other bridge tools. However, it could explicitly name the verb 'get' in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'useful for getting a full picture of what's happening across agents,' which implies a monitoring use case, but provides no explicit guidance on when not to use it or how it differs from other tools like bridge_receive or bridge_channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It correctly indicates a read operation and the polling pattern, but fails to mention potential edge cases (e.g., behavior when channel doesn't exist, error handling, rate limits, or message ordering). This leaves significant gaps for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the core purpose, the second adds actionable usage guidance. Perfectly concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides adequate high-level purpose and usage hints but lacks essential details like return format, error scenarios, and message ordering. For a tool intended for real-time polling, the missing output structure could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the polling use case and the role of 'since_id', but does not significantly enhance understanding beyond what the schema already provides for 'channel' and 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read messages' and the resource 'from a named channel', which distinguishes it from sibling tools like bridge_send (write) and bridge_channels (list channels). However, it does not explicitly differentiate from related read tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for usage: 'Pass since_id to only get messages newer than a known message' and 'Poll this every few seconds to simulate real-time communication.' This gives clear when-to-use hints but does not offer explicit when-not or alternatives among siblings, relying on implied distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It correctly indicates the tool is a read operation (list) and the scope is 'active channels', but does not describe any other behavioral aspects like limits or side effects. It is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is well front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description communicates the essential purpose. However, it could mention what 'active' means or that the tool only lists channels (not sending/receiving). A bit more completeness about the scope would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (trivially). The description adds no param-specific info but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'active channels'. It mentions an additional detail, message counts, but does not explicitly differentiate from siblings like bridge_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as bridge_status or bridge_clear. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool clears all messages (destructive), but does not mention permissions, irreversibility, rate limits, or any side effects. This lack of detail for a destructive operation is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, and no wasted words. The description is highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose and a use case. However, it does not mention return behavior or confirmation, which would be helpful for an agent. Adequate but minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'channel', and the description says 'Channel to clear', which adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Clear' and the resource 'all messages from a specific channel', distinguishing it from sibling tools like bridge_send or bridge_receive. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Useful for resetting state', which implies a usage context, but does not explicitly state when to use this tool versus alternatives or when not to use it. It provides only a general hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the message is readable by another agent via bridge_receive, which implies the message persists and is accessible. However, it does not describe whether the send is synchronous, if there are delivery guarantees, rate limits, or what happens if the channel doesn't exist (e.g., auto-creation or error). Without annotations, these gaps leave the agent somewhat uncertain about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. The first sentence states the action and destination, the second provides concrete naming examples. Every sentence is essential and adds clear value. No repetition or filler. The information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 3 parameters with 100% schema coverage, no output schema, and no annotations, the description covers the key usage context well. It explains the communication pattern (send/receive pair), the naming convention for channels, and how the other agent accesses the message. The only minor gap is the lack of information about error conditions or delivery semantics, but for a simple message-sending tool, this is largely adequate in combination with the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters with descriptions. The description adds guidance on channel naming conventions (e.g., 'demo:orchestrator'), which provides useful context beyond the schema's generic 'Channel name' description. However, the description does not clarify the relationship between 'sender' and the bridge identity, or whether 'content' has size limits. The schema is doing the heavy lifting, and the description adds marginal but valuable guidance on channel format and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a message'), the target ('a named channel on the Claude Bridge'), and who can read it ('the other agent can read it with bridge_receive'). It distinguishes the tool from siblings like bridge_receive by explicitly naming the complementary tool. This is a specific verb+resource combination that leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (to send a message to another agent) and gives naming conventions for channels ('descriptive channel names like 'demo:orchestrator' or 'demo:worker''). While it doesn't explicitly state when not to use it or mention alternative tools beyond bridge_receive, the sibling context is available and the naming examples are helpful for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/constripacity/Claude-Bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server