claude-bridge

by JosiahSiegel

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, from dispatching and monitoring jobs to managing schedules and channels. Detailed descriptions further clarify any potential overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., cancel_dispatch, list_schedules, wait_dispatch). The main dispatch tools are named appropriately as core actions.
Tool Count5/5
16 tools is well-scoped for a bridge to Claude Code, covering help, dispatch, scheduling, monitoring, and channel management without being excessive or insufficient.
Completeness5/5
The tool surface provides comprehensive coverage for the bridge's purpose: running prompts, handling async jobs, scheduling, monitoring, and cancellation. No obvious gaps are present.
Average 4.3/5 across 16 of 16 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It implies a read operation but does not explicitly state read-only nature, side effects, or authorization needs. The description is too brief to adequately disclose behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences and front-loads the purpose. However, it could be restructured to include parameter guidance or behavioral notes without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input and lack of output schema, the description leaves out critical details like what fields the response contains (beyond last_job_id). An agent would need to infer the response structure, making it incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its only parameter (schedule_id). The description does not mention the parameter or explain how to obtain the schedule_id. It adds no meaning beyond the schema, which itself lacks a description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'detail view of one schedule', indicating retrieval of a single schedule. It distinguishes from sibling tools like list_schedules by implying a specific schedule is targeted, but does not explicitly mention the schedule_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests follow-up actions using get_dispatch or list_completions based on the returned last_job_id. However, it does not specify when to use this tool versus alternatives, or provide any prerequisites.
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 provided, so description must disclose behavior. It states the tool returns all schedules with their statuses, but does not mention read-only nature, potential pagination, ordering, or lack of side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core purpose ('Every schedule the bridge knows about') and includes relevant statuses. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters or output schema, the description is adequate. It covers what the tool returns. However, it does not clarify if results are paginated or if any default ordering exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% (trivial). Baseline score of 4 applies as the description adds no parameter info, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all schedules (active, completed, cancelled, error), which aligns with the tool name 'list_schedules'. It distinguishes it from sibling tools like 'get_schedule' which retrieves a single schedule. However, it could be more explicit that the verb is 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_schedule' or 'cancel_schedule'. The description assumes the agent knows to use this for a general overview but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the job is shielded from cancellation and that work continues if MCP call is aborted. No annotations provided, so description carries burden. Explains why default 50s is chosen.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with no filler. Front-loaded with main purpose, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description implies response contains status field. Covers polling pattern and error recovery. Could mention return format or error codes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds meaning for max_wait_seconds by explaining its default and rationale. job_id is not explained further, remaining vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Long-poll a job' and specifies the parameter max_wait_seconds. Distinguishes from siblings like get_dispatch (simple fetch) and cancel_dispatch (cancels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions to call in a loop and break on status != 'running'. Mentions re-entering with same job_id if aborted. Could be more explicit about when to use alternatives like get_dispatch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool cancels future ticks but not in-flight ones, and references the related tool. It is clear about its scope but lacks details on permissions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loaded with the primary action, and includes important distinction and alternative in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers what the tool does and its limitations. It could be improved by hinting at the source of schedule_id (e.g., from list_schedules) but is still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not add any meaning to the 'schedule_id' parameter beyond its type, leaving the agent to infer that it is the identifier of the schedule to cancel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Stop a schedule from firing further ticks' with a specific verb and resource, and it distinguishes from the sibling 'cancel_dispatch' by noting that in-flight ticks are not cancelled and directing to use that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (stop future ticks) and when not to use (for in-flight ticks), and provides an alternative tool 'cancel_dispatch' for the latter case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It reveals that the subprocess runs with its own session, stdout/stderr go to disk, the job survives transport timeouts and bridge restarts, webhook delivery is fire-and-log, and empty prompts return a synchronous error without creating a job. This is comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and a bullet-like section for webhook details. It front-loads the core purpose and proceeds logically. While slightly long, every sentence adds essential information, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is nearly complete. It covers return values (success and failure shapes), background behavior, survival, polling instructions, and webhook details. The only gap is that it relies on 'Args mirror dispatch' without explicitly listing all parameters, but the context is rich enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning for notification parameters (notify_url, notify_on, notify_headers) with details on payload and behavior, but it only says 'Args mirror dispatch' for the other 5 parameters, leaving them to the agent's knowledge of the sibling tool. This partial compensation is adequate but not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool spawns a background dispatch and returns a job_id immediately. It distinguishes itself from siblings like dispatch (synchronous) and wait_dispatch (polling) by focusing on long-running tasks that exceed MCP transport limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Use this for anything that may exceed the MCP transport's per-call ceiling (~60s in Cowork) — persona runs, refactors, anything in a busy project.' It also instructs to poll with wait_dispatch. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that it drops a pinned session, does not cancel running work, and affects future dispatches. However, it does not mention side effects, permissions, or return behavior, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver all key points: action, use case, and limitation/alternative. No wasted words. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, usage, and behavioral distinction. Missing are return values, error cases, or prerequisites, but the tool's simplicity reduces the need for exhaustive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'channel' parameter has 0% schema description coverage, and the description does not elaborate on its meaning, format, or where to obtain it. The implied meaning from the tool name and description is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Drop a channel's pinned session') and clearly identifies the resource and outcome. It also distinguishes itself from the sibling 'cancel_dispatch' by stating what it does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage context is provided: 'when a project MCP server has wedged inside the channel's session'. It also tells when not to use it and directs to an alternative ('use cancel_dispatch for that').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly explains behaviors: it sends SIGTERM, cancels the asyncio task, and details return values for actionable vs. non-actionable cases. The state distinction between 'cancelled' and 'abandoned' adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the purpose and then provide essential details. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and no output schema, the description covers all critical aspects: action, process, state distinction, and return values. It is fully adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not describe the job_id parameter. It only implies its use via context. The description fails to add meaning beyond the schema's type declaration, leaving a gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels a running job, specifies the mechanism (SIGTERM, asyncio task cancellation), and distinguishes the resulting state as 'cancelled' vs 'abandoned', which differentiates it from sibling tools like cancel_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use: to cancel a user-initiated job. It distinguishes cancellation states but does not explicitly mention when not to use (e.g., for scheduled jobs) or name alternatives like cancel_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It explains all possible statuses (running, done, cancelled, abandoned, error, orphaned), handling of unknown job_id, and that it works for live and disk-loaded jobs after restart. It does not mention authorization or rate limits, but it covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single line for the main purpose followed by a bulleted list of statuses. No redundant information; every sentence adds value. Front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no output schema, and no annotations, the description covers the tool's behavior comprehensively: status explanations, error handling for unknown IDs, and persistence across restarts. It is sufficient for an AI agent to understand what the tool does and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter job_id has 0% schema description coverage. The description adds meaning by specifying that an unknown job_id returns {ok: false, error: ...}, which is not in the schema. This compensates well for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Non-blocking read of a job's current state,' which clearly specifies the action (read) and resource (job's current state). This distinguishes it from siblings like dispatch (create) and wait_dispatch (blocking wait).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Non-blocking' implies when to use (avoid waiting) but does not explicitly contrast with alternatives like wait_dispatch. There are no when-not-to-use or exclusionary statements, though the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a pinned session_id and does not indicate work status, but it lacks details on side effects, data freshness, or whether it is a read-only operation. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey the essential information with no wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given 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), the description is complete. It explains the output (pinned session_id) and provides an important limitation with a cross-reference to a sibling tool. No further details are needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the input schema has no properties. According to the rubric, a baseline of 4 is appropriate for 0 parameters. The description does not need to add parameter details, and it does not detract from clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists channels and returns a pinned session_id, effectively communicating its purpose. It also distinguishes itself from the sibling tool list_jobs by clarifying what it does not provide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when not to use this tool (when checking for in-flight work) and directs the agent to use list_jobs as an alternative, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It describes the output structure in detail, implying a read-only information retrieval. However, it does not explicitly state that it has no side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with clear front-loading. It uses two paragraphs effectively but could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly explains the return shape (tools, workflows, concepts, gotchas) with field names. This is complete for a help tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so no param info needed. Baseline is 4, and description does not mention any parameters, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured guide covering tools, workflows, concepts, and gotchas. It distinguishes itself from sibling tools by being a meta-guide rather than an operational tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling once when starting or when unsure which tool fits. Provides clear context for use without needing to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it's cheap and non-blocking, explains return shape (list of get_dispatch shape with finished_at, raw omitted). Could elaborate on any side effects or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs, each sentence adds value. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 optional parameters, no output schema, and no annotations, description is fairly complete. Covers return shape, typical polling pattern, and limitation (raw omitted). Could mention pagination for limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning to parameters: since is a threshold for finished_at, limit defaults to 50. Explains usage patterns that go beyond schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists completed jobs filtered by finished_at > since, oldest first. Verb 'list' with resource 'completions' is specific and distinct from sibling tools like list_jobs or get_dispatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage patterns: use since=0 for all completions, track largest finished_at for polling. Advises on caller frequency (start of every turn) and contrasts with get_dispatch for full payloads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains that failures never raise (always return a result) and describes timeout behavior. However, it could be more explicit about side effects like state changes in the devcontainer, but overall it gives good insight into behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose, a usage guideline line, and a clear Args/Returns layout. It is concise given the number of parameters and the need for behavioral explanation, though slightly longer than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema, sibling tools), the description is complete. It explains the return value format (success/failure fields), when to use this vs dispatch_async, and covers parameter details thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter in the Args section, adding meaning beyond the bare schema. It covers prompt, channel, timeout_seconds, permission_mode, and cwd with usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a prompt against Claude Code and returns the result, specifying the verb, resource, and scope. It distinguishes itself from the sibling dispatch_async by mentioning short vs long prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (for short prompts under ~60s) and when to use the alternative dispatch_async (for longer prompts) to avoid transport ceiling issues. Also explains the channel parameter for session continuity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a key behavioral trait: 'raw is stripped from done-state summaries to keep the response cheap.' This adds useful context beyond a simple listing, though it could mention the response format (e.g., list of objects with summary fields).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The key information is front-loaded: what it lists, the trade-off, and the alternative. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers everything needed: purpose, behavioral caveat, and fallback. It is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description does not need to add parameter details and doesn't repeat schema information. It mentions the output characteristic (cheap, stripped raw) which indirectly relates to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tracked jobs (running and finished) using a specific verb ('list') and resource ('jobs'). It distinguishes itself from sibling tool 'get_dispatch' by noting the omission of raw data for cheapness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for a cheap overview) and when to use an alternative (get_dispatch for full payload). This guides the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: each tick is independent, schedule persists to disk and resumes after restart, self-cancellation via sentinel, webhook payload shape, and per-tick timeout. It provides rich context for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary paragraph, Args list, Returns, and additional details. It is comprehensive but slightly verbose, though every section earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all aspects: parameters, return value, webhook payload, self-cancellation, persistence, and chaining. With no output schema, it provides the return structure. It is complete for a scheduling tool with 12 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining every parameter in detail, including mutual exclusivity (until vs. until_seconds), timezone interpretation, chaining behavior, and webhook options. Examples like '14400 = 4 hours' add clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recurring dispatch: fire prompt on channel every interval_seconds...' It distinguishes from siblings like dispatch (one-off) and dispatch_async (async single) by explicitly using 'recurring' and detailing scheduling behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recurring tasks and provides a self-cancellation pattern example. However, it does not explicitly contrast with siblings or state when not to use it, leaving implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the long-poll behavior: returns immediately if any completion is available, otherwise waits up to max_wait_seconds. The loop re-entry and default time rationale are explained. However, it does not detail what constitutes a 'completion' or any potential side effects, though for a poll tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a purpose: first defines the core behavior, second explains the immediate-return condition, third provides practical usage guidance. No extraneous words. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple long-poll tool with no output schema and minimal parameters, the description covers all essential aspects: action, parameters, behavior, and use case. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning to 'since' as a cursor and states that 'max_wait_seconds' default is below the MCP transport ceiling. This provides context beyond the schema, though it could specify the format of 'since' (e.g., timestamp).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Long-poll up to max_wait_seconds for any new completion since the cursor', specifying the exact verb (long-poll/wait) and resource (any completion). It distinguishes itself from sibling tools like wait_dispatch by focusing on any completion rather than a specific dispatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful when watching schedule ticks land without polling each tick's job_id separately', providing a clear use case. It also explains the default timing strategy: 'Default 50s is below the MCP transport ceiling so you can re-enter in a loop', guiding when and how to use this tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description fully carries the burden. It discloses the bounded buffer, persistence, event loss before feature shipped, optional JSONL log, and event structure. This is thorough behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured with sections for modes, common types, and notes. It is front-loaded with the main purpose, though slightly long due to necessary detail. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description adequately describes event structure (ts, event, type-specific fields). It covers usage patterns, edge cases (buffer, persistence, limitations), and provides a complete picture for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds deep meaning to all 4 parameters: 'since' cursor usage, 'limit' default, 'types' as allow-list with common types, and 'notable_only' with detailed mode definitions. It fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns bridge events with filtering, using a specific verb and resource. It distinguishes from sibling tools like list_completions or list_schedules by focusing on the generic event log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly describes two read modes (debug vs. surfacing) with guidance on when to use each, explains the cursor pattern, and details how the 'types' parameter composes with 'notable_only'. This provides clear when-to-use and when-not-to-use advice.
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:

[![claude-bridge MCP server](https://glama.ai/mcp/servers/JosiahSiegel/claude-bridge/badges/card.svg)](https://glama.ai/mcp/servers/JosiahSiegel/claude-bridge)

Score Badge

Copy to your README.md:

[![claude-bridge MCP server](https://glama.ai/mcp/servers/JosiahSiegel/claude-bridge/badges/score.svg)](https://glama.ai/mcp/servers/JosiahSiegel/claude-bridge)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JosiahSiegel/claude-bridge'

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