opencode-mcp-bridge
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool clearly targets a distinct aspect of session or server management: health vs status vs context vs diff serve different query depths, send vs command vs interrupt handle different input methods, and checkpoint/retry/list_checkpoints form a clear lifecycle. The only near-overlap (health vs server_health) is explicitly disambiguated in the description.
Naming Consistency4/5All tools share the opencode_ prefix and use snake_case, providing a consistent style. However, the pattern mixes bare nouns (health, status, context) with verb-first forms (set_model, list_checkpoints, server_restart), so it is not a strict verb_noun pattern throughout.
Tool Count3/528 tools is on the heavy side, straddling the 'too many' threshold. The breadth is justified by the complex session-lifecycle and server-management domain, but the count exceeds the typical well-scoped range and may introduce selection overhead for agents.
Completeness5/5The surface covers the full session lifecycle (start, read, interrupt, kill), checkpointing (save, list, retry), batch operations, configuration, and server health. No obvious dead ends or missing operations for the stated purpose of bridging to OpenCode.
Average 3.3/5 across 28 of 28 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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 carries full burden for behavioral disclosure. It doesn't mention whether logs are filtered by session, whether they cap at a certain size, how 'recent' is defined, whether this is a read-only operation (which seems likely but isn't stated), or what format the log entries take. The description gives almost no behavioral information beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero wasted words. However, it's arguably under-specified rather than properly concise — it's too terse to be genuinely useful. It's readable and front-loaded but at the cost of meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description needs to do more work. It doesn't explain the output format, the meaning or interaction of the two optional parameters, what 'recent' means, or how this relates to the many sibling tools. The description is insufficient for an agent to confidently select and correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'recent' which loosely maps to last_n, but the parameters last_n and session_id have no semantic explanation beyond their names. The description doesn't clarify what last_n means (number of entries?) or what session_id filters (which bridge session?), and whether both interact or are mutually exclusive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns recent bridge log entries' has a clear verb+resource (returns logs), and the word 'recent' gives some scoping. However, it doesn't distinguish from siblings like opencode_health or opencode_status, and 'bridge log' is somewhat ambiguous without context about what the bridge is or which subsystem it belongs to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as opencode_health, opencode_status, or opencode_server_health. It doesn't state whether this is for debugging, monitoring, or retrieval of specific sessions. The description implies using it when logs are needed but provides no context, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description gives no indication of what this tool returns, whether it's a read-only operation, whether it makes external calls, its cost implications, or what 'model and statistics' concretely resolves to. With zero annotations and only a vague sentence, the transparency 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length. However, it is under-specified rather than efficiently written — 'Queries OpenCode model and statistics information' is vague and could mean almost anything. Terse without being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool takes no parameters and has no output schema. The description must carry all the burden of explaining what it returns, but it fails to do so. 'Model and statistics information' doesn't tell the agent the response shape, what metrics are included, whether it's instantaneous or aggregated, or how it differs from opencode_status. For a no-schema, no-annotation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, meaning there are no parameters to explain. The baseline for 0 params is 4, and there is genuinely nothing for the description to add here. This dimension is automatically strong because the parameter surface is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Queries OpenCode model and statistics information' which states a rough verb+resource but is overly vague. It doesn't specify WHAT model info or WHICH statistics, nor does it distinguish itself from siblings like opencode_status or opencode_health which could plausibly return similar information. The purpose is too ambiguous for a tool named 'usage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. A 'usage' tool could overlap heavily with opencode_status, opencode_active, opencode_health, or opencode_batch_status. There is no context about what query scenario this addresses or when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. The description says it 'submits it with Enter,' implying an active keypress/execution action, but doesn't disclose what happens after submission (does it block? does it execute in a terminal?), whether it requires an active session, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It front-loads the key action (sends a command or text) and adds the useful detail of Enter submission. Efficient and to the point, though it could use a bit more explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 2-parameter tool with no output schema and no annotations, so the description should be self-sufficient. It tells what the tool does but misses key context: possible error conditions, whether it blocks for a response, behavior when no session is active, and how it relates to opencode_send. For a tool that likely executes arbitrary commands, this is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (command and session_id) are documented in the schema itself. The description doesn't add meaning beyond what the schema provides; it doesn't clarify command semantics, format expectations, or the distinction between 'command' vs 'text.' Baseline 3 is appropriate given full schema coverage and minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it sends a command or text to OpenCode and submits it with Enter. The verb is clear (sends/sends+submits), but it doesn't distinguish itself from sibling opencode_send, which likely does something similar. 'Submits it with Enter' adds a meaningful detail, but the purpose is ambiguous versus a near-identical sibling name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Given the large sibling set including opencode_send, opencode_batch, and opencode_interrupt, there is no indication of when this should be preferred. No exclusions, no alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention whether the file must exist, what happens if the file isn't tracked, whether this is read-only (safe), or what the return structure looks like. For a tool that doesn't reveal its output format, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with zero waste. It's appropriately short and directly states the function. However, at this brevity it borders on under-specification rather than deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 27 sibling tools create a complex context that this description does not address. For a tool that returns metadata (unclear return format), with no behavioral disclosures, and no usage contrast against similar checkpoint/list tools, the description is too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds nothing beyond the schema for the two parameters (filepath and session_id both self-explanatory in their enum-like descriptions). The description's mention of 'tracked during the session' hints at session context, which slightly complements the session_id parameter, but adds no new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns 'change metadata' for a file, which is a specific verb+resource. However, 'change metadata' is somewhat ambiguous—it doesn't specify what kind of changes (diff content? timestamps? status flags?) or in what format. It's distinguishable from siblings like opencode_checkpoint, but the purpose could be sharper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description doesn't mention when a user would need change metadata, prerequisites (file must be tracked in session), or contrast with similar tools like opencode_checkpoint or opencode_list_checkpoints. With 27 siblings, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, whether it works with mixed valid/invalid session IDs, what happens with unknown IDs, or any latency/batching behavior. For a non-annotated tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It conveys the core purpose quickly and front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has simple structure (one array parameter, no output schema, no nested objects), so complexity is low. The description is adequate for a minimal status-checking tool, but it lacks detail about result mapping and edge cases that would matter for an agent invoking this on a batch of IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the schema already documents 'session_ids' as 'Session IDs to check.' The description adds little semantic nuance beyond this — it doesn't clarify array size limits, ID format expectations, or how results map back to individual inputs. With full coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Returns status for a batch of session IDs,' which is a clear verb+resource combination. It distinguishes the batch nature of this tool from the likely single-session opencode_status sibling, but it does not explicitly differentiate or explain what 'status' contains or how the returned format differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this batch status tool versus opencode_status (single session) or when a batch check is appropriate. It does not state alternatives, exclusions, or context where the tool is most/least useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. The description does not disclose side effects of updates, whether changes persist across sessions, whether validation occurs, whether this is a safe read operation, or how the get behavior works or what it returns. For a tool that both reads and mutates configuration, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that efficiently names the tool's dual purpose and the three options. No wasted words. It could be slightly more informative while still concise, but the structure is appropriately tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that both gets and updates configuration with 3 undocumented parameters and no output schema, the description is thin. It doesn't explain how get vs. update is triggered (parameter presence?), what the return value looks like for a get, or what constraints exist on values. Given the dual-mode behavior and zero schema coverage, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only lists parameter names without adding any meaning. It doesn't say whether effort_level values map to specific behaviors, what default_agent expects (name format?), or how parameters interplay (e.g., does passing a parameter mean update, and passing none mean get?). The enum for effort_level is in schema but its semantic meaning is unexplored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual purpose: get or update configuration options, and names the specific options (effort_level, default_model, default_agent). This is a specific verb+resource combination. However, it doesn't distinguish from siblings like opencode_set_model, which overlaps partially with setting default_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. For instance, opencode_set_model appears to handle model setting, yet there's no clarification whether opencode_config should be used instead or when each applies. No exclusions or context about when getting vs. updating is appropriate given both are supported by this same tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether switching destroys state, requires an existing session ID, affects ongoing work, or what happens to the previously active session. For an action that changes global state, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately concise for a simple state-switching tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter switch tool with a well-documented single param, the description is mostly adequate. However, without annotations and without output schema, the tool doesn't disclose error behaviors (e.g., what happens with a nonexistent session ID) or side effects of switching. Given the many related opencode_* siblings, a bit more context on effects would strengthen completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'session_id' is documented in the schema ('Session ID to make active'). The description adds minimal extra meaning beyond the schema, but with only one well-described parameter, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb+resource construction ('Switches the active session to the specified session ID'). It identifies the tool as switching to a given session, which is distinct enough, though it doesn't elaborate on what switching means (context reload, workspace views, etc.). It does not explicitly distinguish from siblings like opencode_active or opencode_context, though the intent is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is used to make a different session active, which provides some context. However, it offers no guidance on when to use this versus alternatives like opencode_active (which likely queries the active session) or opencode_start. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return value (output buffer and reason) which helps, but doesn't disclose side effects like whether the task is truly terminated, whether unsaved work is lost, whether it's reversible, or whether subsequent retry is possible. For an interrupt action, these behavioral details matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the action, the mechanism (Ctrl+C), and the return value. Zero wasted words. The information is front-loaded and complete for what it claims.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interrupt action with no annotations and no output schema, the description is thin. It doesn't state preconditions (e.g., must have an active task), post-conditions (silent vs. verbose interruption, whether process restarts), or edge cases (what happens with no task running). Sibling tools like opencode_retry and opencode_kill suggest a lifecycle this tool participates in, but that context is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema. The 'reason' parameter's purpose (why interrupting) is clear. However, the description adds nothing beyond the schema — no guidance on what makes a good reason or how session_id should be formatted/selected when multiple sessions exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (sends Ctrl+C / interrupt), the resource (the task), and the effect (interrupts the task). It also specifies the return behavior (final output buffer and reason). While it doesn't explicitly distinguish from siblings like opencode_kill or opencode_send, the 'interrupt' action is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include opencode_send, opencode_kill, and opencode_retry, which could overlap conceptually with interrupting a task, but the description doesn't clarify when interrupt is preferred or when kill/retry would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Terminates a session and frees all its resources' implies destructive action but doesn't state whether it requires confirmation, whether it's reversible, what happens to an active session when killed, or what the impact is on the agent. No mention of irreversible consequences or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core action in 8 words. It's appropriately front-loaded and contains no filler or redundant content relative to the tool's obvious purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description should do more. It doesn't describe what happens to the active session by default, whether other resources (logs, checkpoints) are affected, or what return/confirmation the agent should expect. The simplicity of the tool helps, but the destructive nature with zero annotation coverage demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there's only one optional parameter. The schema already documents session_id as 'Session ID (defaults to active session),' and the description doesn't add meaning beyond that. With such high schema coverage and a single self-documenting param, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Terminates') plus a resource ('session') and states the effect ('frees all its resources'). It's specific enough to distinguish from siblings like opencode_interrupt (interrupting vs killing) and opencode_retry, though it doesn't explicitly differentiate from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't clarify the distinction between terminating (kill) vs interrupting (interrupt) vs stopping/cleaning up, which is relevant given the rich sibling set. No exclusions or preferred scenarios stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'gets or sets' which implies both read and write behavior, but doesn't disclose whether toggling 'on' has side effects, whether it affects other tools, whether it requires auth, or how delegation affects subsequent operations. The dual get/set behavior is the only transparency offered, and that's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste. Every word earns its place: 'Gets or sets' defines the action semantics, 'delegation toggle' defines the resource, and the on/off values are specified. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a get/set mutation tool with no annotations and no output schema. For a tool that can both read state and change behavior, the description should explain what delegation means in this context, what happens when toggled on/off, and whether there's a default state. With zero annotations and zero output schema, the description is underspecified for the operational complexity hidden behind such a simple interface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there's only 1 parameter with an enum, so the schema itself fully enumerates valid values ('on'|'off'). The description mentions the toggle values ('on' | 'off') which mirrors the enum. Since the schema fully self-documents the only parameter via the enum, the description adds minimal but non-zero context by explaining these represent delegation states. Baseline 3 is appropriate given the single, enum-constrained parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States verb 'gets or sets' with resource 'delegation toggle' and the on/off values. It's clear what the tool does, though it doesn't explicitly distinguish itself from siblings like opencode_set_model (delegation vs model are distinct enough). Purpose is clear but sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. With 27 sibling tools including similar opencode_* operations, there's no indication of when delegation toggling is appropriate, whether there are prerequisites (e.g., server running), or consequences of toggling delegation. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it returns ID and status but doesn't explain whether this is a read-only operation, whether it errors when no session is active, what status values are possible, or whether it requires authentication. With zero annotation coverage, more behavioral detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, zero wasted words. Every word carries meaning about the return value (ID and status) and scope (active session). Appropriate length for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter, the description is reasonably complete. No output schema exists, so the description must convey what is returned (ID and status), which it does. However, given the large sibling set with overlapping names (opencode_status, opencode_context, opencode_list), a note on distinction would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to document. The baseline of 4 for 0-parameter tools applies here since parameter semantics is entirely moot and the description correctly doesn't attempt to describe nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Returns') and the resource ('the currently active session'), specifying that it provides the ID and status. This is clear about what is returned, though it doesn't distinguish this from opencode_status, opencode_list, or opencode_context siblings which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like opencode_status, opencode_list, and opencode_context, there's ambiguity about when the agent should prefer opencode_active. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the operation is non-interrupting ('WITHOUT interrupting it'), which is useful. However, it doesn't clarify what a 'checkpoint snapshot' includes, how many checkpoints are retained, whether checkpoints persist across sessions/restarts, or whether this tool has side effects. The non-interruption disclosure is the strongest signal, but more behavioral context would be valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence that conveys purpose and a key behavioral constraint. No wasted words. It's concise without being too sparse, though slightly more context (like checkpoint retention policy) would not have hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and no output schema. The description adequately covers the essentials for a simple action tool. However, it doesn't explain what the checkpoint can later be used for (restore? diff?), how it relates to opencode_restore or opencode_list_checkpoints, what happens on failure, or how checkpoint frequency/size behaves. Given the nearby sibling tools, some cross-tool relationships would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single session_id parameter is documented). The description doesn't elaborate on session_id semantics beyond what the schema says, but with full schema coverage the baseline of 3 is appropriate. The description adds no extra parameter context, which is acceptable given the schema already documents the one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (saves) and resource (checkpoint snapshot of session state). The 'WITHOUT interrupting it' phrase adds meaningful scoping. However, it doesn't explicitly distinguish it from the sibling tool opencode_list_checkpoints, though the intent is reasonably inferable from the word 'saves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes what the tool does but provides no guidance on when to use it versus alternatives like opencode_list_checkpoints or opencode_context. There's no mention of how checkpointing relates to other session management tools, when checkpointing is beneficial, or why one might use this instead of other state-management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states the tool loads a checkpoint and spawns a new session, which covers the basic mechanism, but doesn't disclose side effects (e.g., does the new session supersede the current one? Is the current session killed? What happens to in-flight work?), error conditions (invalid checkpoint_id), or any state implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. Every word earns its place. Front-loads the core action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description must carry more weight. For a tool with two parameters including an optional continuation_hint, the description could explain how the hint combines with the original session instructions, whether the retry replays prior conversation or starts fresh from the checkpoint state, and what the return value indicates. This is a moderately complex state-management operation that leaves significant behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are described in the schema (checkpoint_id is the ID to retry from; continuation_hint is an optional extra instruction). The description adds that it's a 'retry' operation and mentions 'continuing from that state', which adds marginal context about the continuation_hint parameter being an addition to the original instruction. However, it doesn't elaborate on the format or semantics of continuation_hint beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Loads') with a clear resource ('saved checkpoint') and action ('spawns a new session continuing from that state'). It clearly distinguishes from siblings like opencode_checkpoint (which saves) and opencode_list_checkpoints (which lists). However, it doesn't explicitly differentiate from opencode_start or opencode_switch, which might also involve session initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (load a checkpoint to continue work), giving some context. However, it doesn't explicitly state when to use this vs alternatives, doesn't note prerequisites (e.g., checkpoint must exist), and doesn't clarify when NOT to use it (e.g., if you want a fresh session).
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description doesn't state whether this tool makes external API calls, whether classification is local/heuristic or model-based, whether there are side effects (e.g., does it just return a recommendation or does it actually trigger delegation?), or whether it modifies any state. For a decision-making tool, the lack of clarity on side-effectfulness is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the action verb. Every element serves a purpose. The description lists the three decision outputs (delegate, model, strategy) which is useful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool (classification decision) with no annotations and no output schema. The description explains inputs and decision axes but doesn't describe the return format, whether the classification is deterministic, or what 'strategy' entails. Given the no-output-schema constraint, the description could be more explicit about the nature of recommendations it produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'task' is described as 'Task description to classify' which maps directly to the tool's purpose. The description adds minimal meaning beyond the schema, but with only one parameter at full coverage, this is acceptable. The description's mention of 'delegate to OpenCode, recommended model, and strategy' gives context on what the task parameter feeds into.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (classifies), resource (task), and the three outputs (delegate to OpenCode, recommended model, strategy). It's a classification/decision tool distinct from siblings like opencode_send, opencode_start, and opencode_list which perform direct operations. However, it could more precisely distinguish itself from opencode_status or opencode_health which also assess OpenCode state but with 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is an evaluation/pre-decision tool used before delegating to OpenCode, but doesn't explicitly state when to use it versus alternatives like opencode_send or opencode_command. There's no explicit when-not guidance or mention of alternatives. The context is inferable that this is a preliminary decision tool but not explicitly stated.
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 of behavioral disclosure. It reveals the parallelism cap (up to 3) and the dependency mechanism, which are useful behavioral traits. However, it does not disclose what happens on partial failure (do successful tasks get killed?), whether parallel sessions compromise resource use, or what the return value/status reporting looks like. Given a launch tool with no annotations, more behavioral detail would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single declarative sentence that is efficient and front-loaded with the core purpose. It captures the most important constraints (parallelism limit, dependency support) without waste. The compact wording earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch/parallel execution tool with a nested-object parameter and no output schema, the description could be richer. It explains the core mechanism (parallelism + dependencies) but omits expected return/status semantics, failure behavior, or how results are retrieved (e.g., via opencode_batch_status). While the parameter schema is fully documented, the tool's overall operational behavior is somewhat underspecified given its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all fields including task, depends_on, model, workdir, auto_approve, and agent. The description adds the significance of depends_on (referencing 'Session ID or task_N index that must complete first') and the 3-session concurrency limit, which enriches the tasks parameter meaning. However, it does not clarify field interactions like whether auto_approve or model apply per-task, so value over schema is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Starts up to 3 parallel OpenCode sessions with dependency support.' The verb 'Starts' plus the resource (OpenCode sessions) and the key constraint (up to 3 parallel, dependency support) are all conveyed. It distinguishes from siblings like opencode_start (single session) and opencode_batch_status by mentioning parallelism and dependencies, though it could more explicitly contrast with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parallel execution via 'up to 3 parallel sessions' and 'dependency support,' which signals when to use this tool (when running multiple tasks concurrently). However, it does not explicitly state when NOT to use it or point to alternatives like opencode_start for single tasks. The 'dependency support' mention hints at sequencing use cases but stops short of explicit guidance.
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 of behavioral disclosure. The description is a read-only reporting tool by nature (returns a report), which is implicitly safe. However, it doesn't detail whether the report reflects live state or cached data, whether the tool requires an active session, or what happens if session_id is invalid or stale. The field list is informative but behavioral specifics are thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose ('Returns a full health report for a session') followed by a comma-separated enumeration of the report's contents. It's efficient with no wasted words or redundancy, though the long field enumeration adds moderate length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 1 parameter, is fully schema-covered, and no output schema exists. Given its simplicity, the description reasonably captures the report's contents. However, without an output schema and with no annotations, the description must fully communicate what the report contains — and while it lists field names, it doesn't explain their meaning or format. For a reporting tool this is a mild completeness gap, but adequate for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter session_id is documented as 'Session ID (defaults to active session)'. The description's mention of 'for a session' aligns with this. Baseline 3 is appropriate since the schema already fully documents the parameter with its default behavior. The description adds no additional param detail beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a health report for a session, listing eight specific data points (status, uptime, last activity, output line count, recovery attempts, contract violations, file change count, operation log count). It uses a specific verb ('returns') and resource ('session health report'), and is distinguishable from siblings like opencode_status (session status) and opencode_server_health (server-level health). It doesn't explicitly name its sibling differentiation but the specificity of a 'full health report' with enumerated fields distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for a session') but provides no explicit when-to-use or when-not-to-use guidance. It doesn't mention when to prefer opencode_status over this tool or how it relates to opencode_server_health. The session scoping is clear, but no exclusions or alternatives are named.
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's an inherently read-only listing operation ('Lists all tracked...'), which is clear from the wording itself, making it evident this is a safe non-destructive call. However, it doesn't disclose whether the listing is sorted/ordered, whether there are pagination limits, or what 'tracked' precisely means. For a read-only list operation, the declaration of what is listed is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that states the operation, scope, and returned fields with zero wasted words. Perfectly front-loaded and concise for a zero-parameter listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list operation with no output schema, the description is reasonably complete about what is returned. However, it lacks richer context such as ordering, filtering capabilities (none exist), or what 'active status' means versus the other status fields. Given low complexity, the description is adequate but slightly thin on behavioral nuance around what distinguishes 'tracked' and how the list is organized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters (100% schema coverage by virtue of no params existing), so the baseline is 4. The description meaningfully explains what the returned records contain (IDs, tasks, statuses, active status), which adds value beyond the empty schema even though no parameters need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') with a clear resource ('all tracked OpenCode sessions') and enumerates the fields returned (IDs, tasks, statuses, active status). It distinguishes fairly well from siblings like opencode_status (which likely shows one session's status) and opencode_active, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. Siblings like opencode_status, opencode_active, and opencode_batch_status also relate to session state, so without explicit guidance on selection, the agent may struggle to know when 'listing all' is preferred over checking a specific session.
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 what it returns (last 200 lines + status) which adds basic behavioral context. However, it doesn't disclose whether output is cleared after reading, whether this is destructive, or the exact nature of 'session status'. For a read tool the disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the key action and output. Zero waste. Could add a bit more context but it's efficiently written and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema, the description covers the essentials: what it returns and the scope (last 200 lines + status). However, it lacks context on when to use it vs. opencode_logs or opencode_context, and doesn't explain what 'session status' contains. Adequate but with gaps given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—the single optional session_id parameter is documented in the schema. The description adds nothing beyond the schema for this parameter. Baseline 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (returns) and resource (last 200 lines of buffered output plus session status). It distinguishes this from siblings like opencode_logs (which likely fetches full logs) and opencode_status (status-only). Clear enough to communicate the core function, though it doesn't explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—reading buffered output from a session—but doesn't explicitly state when to prefer this over siblings like opencode_logs, opencode_status, or opencode_context. No when/when-not guidance or alternative tool references. The default-to-active-session behavior is implied but not explicitly stated in the description.
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 exist, so the description carries the burden. It discloses the supported key set and implies raw passthrough, but doesn't state side effects like whether output is appended asynchronously, whether input is echoed, or whether there's a risk to running processes. The '<enter>'/'<ctrl-c>' examples hint at interaction but lack contextual depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence effectively communicates the core behavior, followed by a compact list of supported special keys. No waste, but slightly more context could be included without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive PTY-send tool with no annotations and no output schema, the description covers the essential action and key support. However, it doesn't explain return/output behavior, whether keys are case-sensitive or escaped, or what happens if no session is active. Adequate but with gaps for a tool that writes to a live process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The description adds the key-sequence syntax concept ('yes<enter>', '<ctrl-c>'), which complements rather than repeats the schema. Baseline 3 is appropriate given full schema coverage and light added semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Sends raw text or keystrokes to the PTY') and lists supported special keys. It distinguishes intent from siblings like opencode_command and opencode_interrupt, though it doesn't explicitly contrast against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage (sending input to a running PTY process) and gives supported key syntax as examples in the schema. However, it doesn't explicitly state when to use this vs alternatives like opencode_command or opencode_interrupt, nor when it should NOT be used.
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 of disclosure. It states what the tool returns (operation log and file changes) but does not clarify whether this is a read-only operation, what the default scope is, whether it's bounded/time-limited, or how 'tracked for this session' behaves for completed vs. active sessions. With zero annotation coverage, more behavioral context would be valuable, but the core behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero waste. Front-loaded with the functional purpose, it communicates exactly what the tool does in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 optional parameters, 100% schema coverage, no nested objects, and no output schema, this is a relatively simple tool. The description adequately covers its purpose. However, it doesn't clarify what shape the returned operation log/file-changes take, which an agent might want to know for parsing the response. Overall adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both parameters (last_n, session_id) are documented in the schema with descriptions. The description itself adds minimal parameter detail beyond what the schema provides. Per the calibration rules, this is baseline 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific purpose: 'Returns the operation log and file changes tracked for this session.' It uses a specific verb (returns) with specific resources (operation log, file changes) scoped to the session. It distinguishes itself reasonably from siblings like opencode_logs (system logs) and opencode_usage, though it doesn't explicitly compare against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (session operation history) but provides no explicit when-to-use or when-not-to-use guidance. It doesn't name alternatives or exclusions. The context is clear from the resource scope (session operations) but lacks explicit direction on when this is preferred over opencode_logs or opencode_usage.
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 states the tool writes to two locations (workspace and user home profile), which is a meaningful behavioral disclosure. However, it doesn't disclose side effects like potential overwriting of existing guideline files, whether it's idempotent (safe to re-run), or whether it modifies user home beyond the profile directory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the action. It communicates purpose and destination efficiently. Not verbose, though it could note whether the operation is idempotent or destructive without much additional length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter setup tool with no output schema, the description is fairly complete. It states what it does and where. However, for a setup tool that writes to persistent storage, more context would help: is it safe to re-run? Does it overwrite existing files? What happens on failure? These are notable gaps for an operation with persistent side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage (trivially, since the schema is empty), there are no parameters to document. The description stands on its own without needing to explain any parameters. The baseline for 0 parameters is high since there's nothing lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('writes OpenCode subagent guidelines to local workspace and user home profile directory'). It clearly identifies what the tool does and where it writes. It doesn't explicitly distinguish from siblings, but the 'One-time setup' framing and unique action make it reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'One-time setup' phrase gives implied usage context - this is a setup task, not a recurring operation. However, it doesn't explicitly state when to use this vs alternatives, nor does it mention that it should likely be run before other opencode tools become functional. No exclusions or alternative tool references are provided.
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 discloses the output (a status string) and the full set of possible values, which is genuinely useful behavioral context. However, it doesn't describe what triggers stale vs. waiting_input transitions, polling semantics, or whether the tool blocks/fails on invalid session IDs. The status enum partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single informative sentence that front-loads the purpose and enumerates all eight possible return values. No wasted words or redundancy. Could arguably be more structured, but for a simple status-check tool this is appropriately tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter status tool with no output schema, listing all possible status values provides meaningful completeness. The enum of 8 statuses effectively substitutes for an output schema. Minor gap: no guidance on how to interpret or act on each status value, but for a read-only state query this is largely sufficient given the sibling toolset (e.g., opencode_retry, opencode_interrupt) handles follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single session_id parameter, so the baseline is 3. The description mentions 'a session' but does not add detail about session_id format, optionality behavior, or what happens when omitted (defaults to active). The schema's description already covers the default-to-active behavior, so no additional value is added by the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') with a clear resource ('current status of a session') and exhaustively lists all possible status values (running, idle, waiting_input, stale, done, error, contract_violated, starting). While it doesn't explicitly distinguish from sibling tools, the status enumeration makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (checking session state before proceeding) but provides no explicit when-to-use guidance or alternatives. It doesn't state when this should be preferred over sibling tools like opencode_batch_status or opencode_health, though these are conceptually distinct enough that differentiation is implicit.
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. The description indicates a read-only listing operation ('Lists all saved checkpoints'), which implies non-destructive behavior. However, it doesn't disclose what fields are returned, pagination/limits, or whether this is a local or server-side query. Basic behavioral transparency is present but limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero wasted words. It states the action, scope, and ordering in a single efficient clause. Perfectly sized for a zero-parameter list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema, no nested objects), so the completeness bar is lower. The description adequately covers what the tool does. However, it doesn't mention what a checkpoint contains or how many are returned, which could matter given there's no output schema to fill that gap. Acceptable but could add return-format context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (vacuously). With no parameters to document, the description has nothing to add. Per the rubric, 0 params yields a baseline of 4. The description handles the no-parameter case appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lists all saved checkpoints sorted by recency' uses a specific verb (lists) with a clear resource (saved checkpoints) and adds scoping (all, sorted by recency). It clearly distinguishes from siblings like opencode_checkpoint (which presumably creates/manages a checkpoint). It doesn't over-specify but is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description doesn't explicitly state when to use this tool vs alternatives. However, given zero parameters and a read-only list operation, the usage context is reasonably implied. It doesn't name alternatives or exclusions, but the sibling set (opencode_checkpoint, opencode_status, opencode_list) offers some implicit differentiation.
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 behavioral disclosure burden. 'Dynamically switches... for subsequent prompts' conveys that changes apply going forward (not retroactively) and can apply to idle sessions. However, it doesn't disclose whether the change is persisted across restarts, requires authorization, or affects the session's existing state/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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It conveys purpose, target context, and scope in about 15 words. This is appropriately concise and front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with 100% schema coverage and no output schema, the description is fairly complete. It could benefit from noting what happens to the current session context or what response to expect, but given the tool's simplicity and thorough schema, the description covers the essentials well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (model, session_id) documented in the schema. The description itself doesn't add parameter-level detail beyond the schema, so the baseline of 3 applies. The schema already provides examples of valid model values which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('switches') with a clear resource ('the AI model') and scopes it to a session ('active or idle') for subsequent prompts. It clearly states what the tool does. However, it doesn't explicitly distinguish it from siblings like opencode_switch or opencode_mode, which might also relate to session/model changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that it applies to 'an active or idle session for subsequent prompts', implying it should be used when you want to change the model without restarting. The session_id param description notes 'defaults to active session', providing some usage context. However, it doesn't explicitly state when NOT to use it or name alternatives from the sibling list.
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 provided, so description carries the burden. It discloses that sessions emit events (running, idle, waiting_input, done, stale, contract_violated) and describes the notification-watcher pattern, which is good context. However, it doesn't disclose side effects (e.g., potential cost/session creation overhead, async behavior details, whether it blocks) beyond the event flow. Some behavioral detail is given but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key return values, then concise workflow. No wasted words. Slightly dense in sentence two (lists 7 event types inline) but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 params including a nested contract object and complex lifecycle, this is a complex tool. The description explains startup and event-driven flow but not the contract semantics, session continuation behavior, or contract_violated triggering conditions in detail. No output schema to fill gaps. Adequate but leaves room for more on the lifecycle/state machine.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 12 parameters have individual descriptions already. The description adds workflow context (events_log_path usage, follow-up calls) but doesn't explain parameter relationships or the contract object semantics beyond schema. Baseline 3 is appropriate given the high schema coverage; description adds minimal param value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states spawns a new OpenCode CLI session and starts the initial task, with specific verb (spawns/starts), resource (OpenCode CLI session), and returns session_id and events_log_path. It distinguishes from siblings like opencode_health, opencode_read, opencode_kill by its unique starting 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear workflow guidance: watch events_log_path for notifications, call opencode_read when notified, then opencode_kill when done. It names the follow-up tools by name. However, it doesn't explicitly state when NOT to use this tool or when to prefer an alternative like opencode_continue/switch, though the usage flow is well-clarified.
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 of behavioral disclosure. It discloses what fields are reported (pid, port, alive, HTTP-healthy, recovery-in-progress) which is informative, but it doesn't describe the response format, potential failure modes, or whether this is a safe read-only operation. The field enumeration adds value but doesn't fully characterize behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the purpose, enumerates the key output fields, and ends with the critical sibling distinction. Every element earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only reporting tool with no output schema, the description is largely complete: it names the output fields and disambiguates from the key sibling. It could theoretically note whether this operation has side effects (it does not appear to), but given the tool's simplicity and the strong field enumeration, it's close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters in the schema, the baseline is 4 per the rubric. The description's detailed field list (pid, port, alive, HTTP-healthy, recovery-in-progress) effectively communicates what the output contains, which is the most relevant semantic information for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reports') and names the resource (the opencode serve process itself), listing concrete output fields (pid, port, alive, HTTP-healthy, recovery-in-progress). It actively distinguishes itself from the sibling opencode_health, which reports a single session's state, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly distinguishes this tool from opencode_health by contrasting 'serve process itself' vs 'a single session's state', giving clear context for when to choose it. However, it doesn't name additional alternatives or explicitly say when NOT to use it, leaving a slight gap despite the strong differentiation.
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 full behavioral burden and largely delivers: it discloses disruptiveness ('every in-flight session on that process is interrupted') and that it's a forced operation. It doesn't detail timeout behavior or failure modes, a minor gap given no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Each sentence earns its place: what it does, its disruption, and when to use it. The caveat about auto-restart is front-loaded right after the purpose statement, which is ideal pacing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool the description is thorough: purpose, side effects, and usage conditions are all covered. It could mention what happens on success/failure or whether it blocks until restart completes, but given no output schema and trivial parameter surface, this is strong coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters and schema coverage is 100%, so the schema carries nothing heavy. The baseline for 0 params is 4, and the description doesn't detract from that — it correctly conveys there is nothing to configure and focuses on side effects instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Forcibly restarts the underlying opencode serve process') and clearly states its disruptive nature. It distinguishes this from siblings like opencode_kill (kill) and opencode_start (start) by framing it as a restart of the serve process specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent guidance: explicitly states when NOT to use it ('Normally unnecessary — the bridge restarts automatically'), the condition under which to avoid it (when auto-restart handles wedge/fail), and exactly when to use it ('right after fixing provider auth'). This is textbook when/when-not/alternatives coverage.
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 carries full responsibility. It clearly states the tool returns a guide and lists the topics covered, making the behavior transparent. There is no mention of side effects, which is appropriate for an informational tool, but the output format is not specified; still, this is sufficient given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the purpose, content, and usage instruction with zero fluff. The key phrase 'Returns the complete behavioral guide' is front-loaded, and the final sentence adds actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what the tool does, what it contains, and when to invoke it. The sibling tools are all operational commands; this guide's position as the first step is explicit. No significant information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, and the description does not need to explain any. With no parameters, the baseline is 4, and the description adds no irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' with a well-defined resource: 'the complete behavioral guide for using opencode-mcp-bridge correctly.' It enumerates the guide's contents (delegation, model selection, workflow, guardrails, diagnostics), which clearly distinguishes it from the many sibling operational tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this first before delegating a task through OpenCode,' providing a direct directive on when to use. This gives the agent a clear entry-point phrase and implies that other sibling tools should be used after consulting this guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dheerax/opencode_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server