opencode-mcp-bridge

by teodorgross

Overview Schema Related Servers Score Discussions

JavaScript

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 targets a distinct aspect of the opencode lifecycle: server health, configuration, run creation, monitoring, cancellation, and result retrieval. While several tools return run information (status, result, messages, diff, todos), their descriptions clearly differentiate the exact data each returns.
Naming Consistency4/5
All tools share the consistent 'opencode_' prefix and snake_case format. The naming mixes nouns for query tools (opencode_result, opencode_todos) and verbs for action tools (opencode_dispatch, opencode_wait), which is a reasonable convention, though not a uniform verb_noun pattern.
Tool Count4/5
With 15 tools, the server sits at the upper edge of a well-scoped set. Each tool serves a clear purpose in managing opencode runs, covering dispatch, waiting, follow-up, cancellation, and detailed inspection, without unnecessary redundancy.
Completeness5/5
The tool set provides comprehensive coverage of the opencode run lifecycle: creating runs, following up, waiting, answering questions, cancelling, and retrieving results, messages, diffs, todos, and status. Configuration tools for models, agents, and health are also included, leaving no obvious gaps.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 7, 2026
- 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 fully disclose behavior. It only mentions the non-blocking aspect, but does not clarify read-only nature, error handling for invalid runIds, authentication needs, or whether the call has side effects. This is a significant gap for a status tool.
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 and directly states the core action and timing attribute. Every word contributes meaning, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what 'current state' entails—such as possible status values, whether it includes progress metrics, or how to interpret the result. It leaves the agent without enough information to reliably use the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage for runId is 100% with a clear definition, so the baseline of 3 applies. The description does not add any additional parameter semantics beyond what the schema already provides.
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?
Description uses the specific verb 'Returns' and identifies the exact resource ('current state of a run') with a distinctive qualifier ('immediately, without waiting'). This clearly differentiates it from sibling tools like opencode_wait and opencode_result, which imply waiting or final results.
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 'without waiting' gives clear context for when to use this tool (non-blocking status checks) versus waiting for completion. However, it does not explicitly name alternative tools or provide when-not-to-use conditions, so it stops short of full marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It does add a notable behavioral guarantee—'Never returns API keys'—and clarifies the source ('configured in opencode'). However, it does not mention pagination, error behavior, or other operational details that might affect an agent's expectations.
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 tight sentences: the first states the core function and output format, the second gives a parameter hint and a security guarantee. No wasted words; information 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with fully documented parameters, the description covers the essential context: what is listed, how to filter, and a key safety property. It does not require a return-value explanation since no output schema exists, and the schema covers parameter details. Slightly more behavioral context could nudge it to 5, but it is adequate as-is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all three parameters. The description only adds a redundant note to use 'filter' for narrowing, which is already clear in the parameter description. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Lists') and resource ('providers and models configured in opencode'), and explains the output format ('provider/model' IDs). This distinguishes it from sibling tools like opencode_set_model or opencode_agents, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (list models to see available options) and offers a hint on 'filter', but it does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks exclusionary guidance such as 'use opencode_set_model to change the model'.
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 discloses the output content but does not explain behavior for unfinished runs, error handling, or whether it is a read-only operation. It covers basic expectations but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the tool's purpose and returned data. No wasted words, clearly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the description lists the return contents. However, since there is no output schema, it could benefit from explicitly stating the requirement that the run must be finished and possibly how to determine that. Minor gap relative to its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the runId parameter is already described as 'The runId of the run.' The description adds no additional semantic detail, so the baseline score of 3 applies.
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 the final result of a finished run, specifying the content (reply text, changed files, cost). This distinguishes it from siblings like opencode_status (status info) and opencode_diff (individual changes).
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?
It implies usage for finished runs, which is a useful contextual cue, but it does not explicitly state when not to use it or mention alternatives like checking status first. The guidance is present but indirect.
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 persistence and partial-update semantics ('only the fields you pass are changed'), which is valuable. But it omits return values, reset behavior, or side effects like overwriting existing configuration, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the core purpose front-loaded and no redundancy. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose and partial-update behavior are clear, and the schema covers all parameters. However, with no output schema and no annotations, the description is minimal: it does not explain return values, reset behavior (beyond the model empty-string hint in schema), or how the persisted settings affect sibling tools. Adequate but with clear gaps.
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 already provides 100% coverage with descriptions and examples for all 7 parameters. The description adds the crucial semantic that every field is optional and only provided fields are updated, which clarifies partial updates beyond what the schema states. This is a meaningful addition.
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 ('persists') and clearly scopes what the tool does: it sets the model, agent, and permission mode for future opencode tasks. This distinguishes it from siblings like opencode_models or opencode_agents, which likely list or query available options.
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 states that the tool affects future tasks, giving implied usage context ('use this to set persistent defaults'). However, it does not mention when not to use it, such as for per-run overrides (e.g., opencode_dispatch), or name any alternatives, so the guidance is limited.
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 burden. It describes a read-only list operation ('Lists') but does not disclose edge cases such as behavior when the directory is invalid or omitted. For a simple listing tool, the lack of additional behavioral context is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, the resource, and the purpose with zero 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 listing tool with one optional parameter and no output schema, the description sufficiently conveys the return content (agents with mode and description) and the intended use case. It does not mention default directory behavior, but it is adequately complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'directory' is fully documented in the schema (100% coverage), and the tool description adds minimal extra meaning beyond the schema. The phrase 'configured in opencode' gives context but does not add parameter-level details, so the baseline 3 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 uses the specific verb 'Lists', identifies the resource 'agents configured in opencode', and clearly states the purpose ('for use as the agent parameter of a dispatch'). This clearly distinguishes it from sibling tools such as dispatch or models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly ties the tool's output to the 'agent' parameter of a dispatch, implying when this tool should be used. It does not explicitly state when not to use it or compare directly with alternatives, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the abort action and the cleanup side effect, but does not mention whether cancellation is reversible, what happens if the run is already finished, or any error conditions. Some behavioral context is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with two clear clauses. Every word adds value (abort action, target state, cleanup side effect), with no redundant or vague wording.
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 one-parameter tool with no output schema, the description covers the primary action and a key side effect. It is adequate but could be more complete by addressing edge cases (e.g., run already completed or nonexistent) or what the return value indicates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the sole parameter (runId) with a description, and the tool's description adds no extra parameter-specific meaning. The schema's 'The runId of the run' is minimal, and the description does not elaborate on how to obtain or format the ID, so value added is neutral.
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 ('Aborts') and resource ('a running opencode run'), clearly distinguishing it from sibling tools like opencode_wait or opencode_status. It also mentions a secondary action (cleans up temporary session), further clarifying its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'running opencode run' provides clear context for when to use this tool (only on active runs). It does not explicitly name alternatives or exclusions, but the intended usage is strongly implied and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the keepSession requirement and the return of a new runId, but it does not mention that the 'model' parameter is ignored or discuss side effects on the previous run or error conditions, leaving notable gaps for a mutation-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the action and purpose, the second adds the prerequisite and return value. This is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, the prerequisite, and the return value, which is adequate for a simple follow-up tool with no output schema. It lacks explicit details about failure modes or the ignored model parameter, but the schema enriches parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions, including an explicit note that 'model' is IGNORED. The description text itself adds no parameter-level detail beyond what the schema already provides, so the 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sends a follow-up instruction'), the target resource ('session of an earlier run'), and the benefit ('so the subagent keeps everything it already worked out'). This distinguishes it from the sibling opencode_dispatch, which would start a new run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit prerequisite ('Requires that the earlier run was dispatched with keepSession: true') and points to the next step ('Returns a new runId to wait on'). It does not explicitly name alternative tools or exclusions, but the distinction from dispatch is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Returns' implies a read-only operation, and it adds context about being useful during in-progress tasks. However, it does not explicitly state non-destructive behavior, permissions, or rate limits, though for a simple read tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key action 'Returns' and includes a useful contextual phrase. It is concise with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one parameter, no output schema—the description sufficiently explains what it does and when it is most valuable. It does not describe the response format, but the todo list concept is self-explanatory and the usage context is clear.
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 provides 100% coverage with a basic description of runId ('The runId of the run'). The tool description adds no further semantic detail about the parameter, so the baseline score of 3 applies.
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 the subagent's own todo list for a run, using a specific verb and resource. It distinguishes itself from sibling tools like opencode_result or opencode_status by emphasizing it is the most informative view during a long task while it is still working.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool—while a long task is still working—making it useful for monitoring progress. However, it does not explicitly name alternative tools or exclusion criteria, such as recommending opencode_result for final output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (listing runs) and the output fields (status, duration), but does not explicitly state whether it is read-only or if there are any side effects. Since it is a list operation, safety is implied, but a clearer nod to non-destructiveness would earn a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then adds useful output details. Every word earns its place, with no redundancy or fluff.
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 0-parameter tool with no output schema, the description provides sufficient context: it states the action, scope, and returned fields. It could be slightly richer by mentioning ordering or that it includes currently running runs, but the description is complete enough for this complexity level.
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 zero parameters, and the schema is empty. Per the guidelines, the baseline is 4 because no parameter documentation is needed. The description adds no parameter info, but none is required.
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 ('Lists') and a clear resource ('every run of this MCP session'), and it specifies what info is returned (status and duration). This clearly distinguishes it from sibling tools like opencode_status or opencode_result, which focus on different aspects.
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 the tool is for retrieving run history of the current MCP session, which provides clear context. It does not explicitly mention when not to use it or point to alternatives, but for a simple 0-parameter listing tool, the context is adequate.
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 the full burden. It discloses a key side effect: starting a local server if none is running, or attaching to an existing one. It also clarifies the output is a version and current settings report, which is valuable behavioral context beyond the basic purpose.
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, well-structured sentence delivers all relevant information: the conditional start/attach behavior and the reported outputs. There is no wordiness or redundancy; every clause adds meaning.
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?
For a parameterless, schema-less health check tool, the description fully explains what the tool does, its side effects, and what it reports. No output schema exists, so the description's mention of version and settings adequately covers the return values. The scope is small and the description is sufficient.
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 zero parameters, so the baseline is 4. The description does not need to elaborate on parameter meanings, and it appropriately avoids adding irrelevant parameter 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 uses specific verbs ('starts', 'attaches', 'reports') and clearly identifies the resource: the opencode connection. It explicitly states the two key outcomes—starting/attaching to a server and reporting version/settings—which clearly distinguishes it from sibling tools that handle agents, models, dispatch, or runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a connection/health check tool but does not explicitly state when to use it versus alternatives. It does not mention exclusions or alternative tools, relying on the title and context to convey its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the configuration dependency and the automatic rejection behavior, and clarifies the ordered structure of answers. However, it does not state whether the run automatically resumes after answering or how errors are handled, 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?
The description is three sentences, each earning its place: the first states the core purpose, the second provides a critical usage condition, and the third clarifies parameter structure. It is concise, front-loaded, and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, prerequisites, and parameter format. It could be more explicit about what happens after the answer is submitted (e.g., run resumes), but the provided context is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description adds limited semantics beyond the schema. The mention of 'answers' holds one array of chosen labels per question reinforces the schema but does not introduce new information. Baseline 3 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 opens with a specific verb ('Answers') and a clear resource ('the question a run is parked on'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like opencode_wait or opencode_cancel by focusing specifically on answering a parked question.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is reachable ('Only reachable when autoAnswerQuestions is disabled') and when it is not ('otherwise questions are rejected automatically'), providing clear usage boundaries. It also explains the rationale (preventing headless runs from hanging), which helps the agent decide when to invoke it.
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 carries the full burden. It discloses that the tool relies on workspace snapshots and returns empty results outside a git repository, which is important behavioral context. It stops short of explicitly stating it is read-only, but the read-only nature is implied and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a necessary caveat. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with no output schema and no annotations: it explains the core functionality, the key limitation, and the relation to a sibling tool. It does not detail the patch format, but the term 'patch' is sufficiently clear for most users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra parameter-level details beyond what the schema already provides, but it does clarify the output scope (actual patches vs file names).
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 the actual patch per file for a run, which is specific and distinguishes it from opencode_result that lists file names. The verb 'returns' and resource 'patch per file' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with opencode_result ('not just the file names', 'opencode_result still lists the touched files'), indicating when to use this tool versus the sibling. Also provides a clear caveat about the git repository requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It uses 'Returns' and 'audit' to clearly indicate a read-only operation, and specifies the content includes tool calls. It doesn't mention potential large payloads or rate limits, but the schema's maxChars parameter hints at truncation, and the description is honest about the scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function and followed by a usage cue. No filler words or redundant information.
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?
For a simple two-parameter tool, the description plus schema fully defines the tool's behavior. The lack of an output schema is compensated by the explicit statement of what is returned (every message with tool calls).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both runId and maxChars, so the description need not explain parameters. It adds no additional parameter details, staying at the baseline of 3.
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 'Returns the complete conversation of a run's session — every message with its tool calls.' This identifies the exact resource (run's session) and action (returns transcript), and differentiates from sibling tools by focusing on the full audit trail rather than a summary.
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 says 'Use this to audit what the subagent actually did when the summary is not enough,' providing a clear condition for when to select this tool. Though it doesn't name a specific alternative, it refers to 'the summary' as an implicit alternative, which is sufficient context.
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 discloses the asynchronous nature: 'Returns IMMEDIATELY with a runId, without waiting for the result.' It also warns that the session knows nothing about the conversation, which tells the agent to include all 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 entire description is two sentences, front-loaded with the core purpose, and packs critical workflow instructions without verbose filler.
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?
For an asynchronous dispatch tool with 8 parameters and no output schema, the description covers the essential workflow: create, get runId, call wait. It also explains the session isolation, giving the agent everything needed to invoke it 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?
Schema coverage is 100%, with detailed descriptions for all 8 parameters including the model ignoring note. The description adds no additional parameter-specific meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a temporary opencode session and hands it the task', specifying the verb and resource. It also distinguishes itself from siblings by explicitly noting the immediate return of a runId and the need to call opencode_wait later.
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 provides the follow-up action: 'Afterwards call 'opencode_wait' with the runId until the run is finished.' It also explains the key constraint that the task must be self-contained, which is essential for using a stateless session.
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 carries full burden and does so thoroughly: it discloses that the tool never blocks indefinitely, never shortens the run, returns the moment opencode reports idle with no polling delay, and emits notifications/progress while waiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph, front-loading the core behavior and then adding necessary clarifications. Every sentence adds relevant information about timing, parallel runs, or notifications.
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?
For a tool with no output schema, the description explains what returns (full result or progress report), the timeout behavior, the idle detection, and the progress notifications. It is complete for the tool's purpose.
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 schema already covers all three parameters with descriptions, but the description adds context: runId is the one returned by opencode_dispatch, runIds allows waiting for the first of several parallel runs, and maxSeconds has a default of 55s. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits up to maxSeconds for a run to finish and returns the full result or a progress report. It uses a specific verb ('wait') and resource ('a run'), distinguishing it from sibling tools like opencode_result or opencode_cancel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs that if a run is still running, a progress report comes back and one should simply call again, and it explains how to pass runIds to wait for the first of several parallel runs. However, it does not explicitly name alternative tools for when not to use this one.
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:

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

Score Badge

Copy to your README.md:

[![opencode-mcp-bridge MCP server](https://glama.ai/mcp/servers/teodorgross/opencode-mcp-bridge/badges/score.svg)](https://glama.ai/mcp/servers/teodorgross/opencode-mcp-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/teodorgross/opencode-mcp-bridge'

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