opencode-cli-mcp
Server Quality Checklist
Latest release: v0.2.3
- Disambiguation1/5
The tool set has severe overlap: opencode_runs duplicates opencode_run_agent, opencode_list_runs, opencode_get_run_status, and opencode_cancel_run via action parameters; opencode_sessions duplicates opencode_list_sessions, opencode_get_session, opencode_send_message, opencode_get_messages, and opencode_session_diff; opencode_system duplicates opencode_launch_ui, opencode_server_status, opencode_list_providers, opencode_get_project, opencode_get_health, and opencode_get_config. These overlapping action-based and individual tools create ambiguity about which to call, despite descriptions.
Naming Consistency2/5Names mix conventions: many use opencode_verb_noun (e.g., opencode_list_sessions, opencode_get_config), but others use opencode_noun with action parameters (opencode_runs, opencode_sessions, opencode_depot, opencode_backups, opencode_system), and the show_*_app tools deviate entirely (show_status_app, show_runs_app). This inconsistency across the set makes it hard to predict tool names.
Tool Count3/5At 25 tools, the server is at the high end of the borderline range for its scope, and many tools are redundant counterparts to the action-based aggregators, inflating the count without adding surface area. However, the domain (opencode CLI management) is broad enough that 25 isn't extreme.
Completeness4/5The server covers the major workflows: installing bundles, running agents, inspecting sessions, backups, system status, and viewing rich UI cards. Minor gaps exist (no direct session creation, no config editing), but these can be worked around via existing actions like opencode_send_message or opencode_system.
Average 4/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.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?
The description only says 'Inspect and interact' and lists actions; it does not disclose that delete is permanent, requires confirmation, or that rename affects the live UI. The schema's action enum includes such notes, but the description itself omits these side effects. With annotations only providing readOnlyHint=false, the description leaves the agent under-equipped to understand destructive consequences, though the example does show confirm=True for delete.
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 well-structured: an opening purpose sentence, a Return Format block, and five concise examples. It front-loads the primary purpose and avoids unnecessary verbosity. The examples are tightly written, though the Return Format block is a minor extra.
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 tool with 9 actions and 9 parameters, the description provides a universal return shape and examples for common operations, but it does not elaborate on per-action edge cases or required parameter combinations beyond what the schema already specifies. The schema's action enum descriptions carry much of the detailed semantics, and the description is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the baseline is 3. The description's examples (e.g., action='rename' with session_id and title) illustrate parameter combinations but do not add meaning beyond the schema's per-parameter and per-action descriptions. It is helpful but not additive.
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 'Inspect and interact with opencode sessions: list, get, transcript, send, diff, grep, export, rename, or delete' which clearly identifies the resource and enumerates specific actions. However, it does not explicitly contrast with sibling tools like opencode_list_sessions or opencode_send_message, so it lacks sibling differentiation.
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 examples (e.g., opencode_sessions(action='send', session_id='sess_01', message='continue')) but gives no explicit guidance on when to use this multi-action tool versus the dedicated sibling tools. There is no 'use this when' or 'for single operations use the specific sibling' direction, leaving the agent to infer 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?
Annotations declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. The description adds the return format and an example, which provides some behavioral context beyond annotations. However, it does not describe any edge cases, pagination details, or error 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?
The description is very concise, with a one-sentence purpose, a return format block, and an example. Each section adds value and the structure is clear.
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 list tool with one optional parameter, the description covers the purpose, return format, and usage example. The existing annotations and schema fill in safety and parameter bounds. Minor details like the exact meaning of 'recent' are unspecified, but overall completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'limit' is fully described in the schema with default, min, max, and description. The description's example (opencode_list_runs(limit=20)) adds no additional semantic value. Baseline 3 applies since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all recent agent runs with status and exit codes, which is a specific action and resource. It does not explicitly differentiate from sibling tools like opencode_runs or opencode_get_run_status, but the name and description are clear enough.
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 explicit guidance on when to use this tool versus alternatives such as opencode_get_run_status or opencode_runs. The description and example imply it's for fetching a list, but no alternatives 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?
Annotations declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds session scope ('active and recent') and return format, but no further behavioral details like ordering or limits.
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?
Description is concise: two sentences plus a return-format block. All content is relevant and directly useful.
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 listing tool, the description covers purpose and return format. It lacks comparison to sibling tools, but is otherwise sufficient for simple usage.
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?
Tool has zero parameters, so schema coverage is effectively 100%. Baseline of 4 applies since no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all active and recent opencode sessions' – a specific verb and resource. However, it does not differentiate from the sibling tool opencode_sessions, leaving potential ambiguity.
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. There is no mention of use cases, exclusions, or comparisons to sibling tools like opencode_get_session or opencode_sessions.
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?
Annotations already indicate destructiveHint=true, so the tool's potential to cancel runs is known. The description adds the return format and explains that fire-and-forget starts return a job_id, which is useful operational context. However, it does not disclose specific side effects of start or cancel actions, such as resource consumption or state changes, which would be valuable beyond the annotations.
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 well-structured with a concise summary, a return format section, and three practical examples. It is front-loaded with the core purpose, and every sentence contributes to understanding the tool. There is no redundancy or unnecessary detail.
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?
The description provides the return format, covers all four actions in the header, and includes examples for start, status, and list. Since an output schema exists, return values are already documented. The only minor gap is the lack of mention of cancel behavior or error handling, but overall it is sufficiently complete for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including descriptions for each field. The description's examples (e.g., action='start', prompt='...', wait=False) reinforce parameter usage without adding new semantic meaning. Since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Manage opencode agent runs: start, poll status, list recent, or cancel.' This specifies the verb and resource, and the examples further clarify usage. However, it does not explicitly distinguish this composite tool from sibling tools like opencode_run_agent or opencode_cancel_run, so it loses a point for lack of differentiation.
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 when to use the tool by listing actions and providing examples, but it gives no explicit guidance on when to choose this tool over dedicated siblings. There are no exclusion criteria or alternative suggestions, so an agent may be uncertain which tool to invoke for a specific run operation (e.g., simply polling status).
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds context about the return payload but does not disclose potential side effects, authentication needs, or latency, though for a read-only status check this is less critical.
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 compact and well-structured, using headers for return format and example. Every sentence adds value, and the format is easy to scan.
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 no-argument tool with strong annotations, the description covers purpose, return format, and an example. It does not clarify how this tool relates to similar health/status tools, leaving some ambiguity, but overall it is 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?
The tool takes zero parameters, so the description does not need to explain parameter meanings. According to the rubric, a zero-parameter tool receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status and health of the opencode server, and lists specific return contents (health info, session count, config summary). It does not explicitly distinguish from sibling tools like opencode_get_health, but the unique return fields imply differentiation.
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 the tool is used to check server status, but provides no explicit guidance on when to use it versus alternatives. It does not mention exclusions or when to prefer a sibling tool like opencode_get_health.
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?
The description goes beyond the annotations by outlining what each action does (e.g., 'status: health + startup probe', 'mcp_pulse: probe all MCP servers for liveness') and specifying the unified return format. It also provides concrete examples that illustrate expected usage. While it doesn't detail side effects of launch_ui, the readOnlyHint: false already signals mutation, and the description adds useful context for a multi-action tool.
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 well-structured with a clear opening line, a return format section, and examples. It is concise enough to be scannable but includes all necessary context. The examples are useful and do not feel like filler, though the action descriptions are slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-action complexity and the presence of an output schema, the description sufficiently covers each action, return format, and example usage. It does not explain error handling or edge cases, but for a system status/control tool with a well-defined schema, this is adequate and complete enough for an agent to select and invoke it correctly.
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%, so all parameter meanings are already documented in the input schema. The description adds minor value by repeating action descriptions and giving examples, but it does not provide additional semantic depth beyond the schema. This aligns with the baseline for high schema coverage.
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 identifies the tool as a multi-action dispatcher for the opencode server environment, listing its specific capabilities (status, providers, project, launch UI, MCP pulse, config drift). It uses specific verbs and resources, and the examples reinforce usage. It distinguishes itself from more specialized siblings by presenting a consolidated system tool, though it doesn't explicitly contrast with 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 when to use this tool based on the listed actions, but it does not explicitly state when to prefer this tool over siblings like opencode_server_status or opencode_list_providers. Usage context is implied by the action list and examples, but there are no explicit exclusions or alternative recommendations.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the return format (success/message/data wrapper) and an example call, but it does not disclose error handling, pagination behavior, or what happens if the session does not exist. This is added value but not extensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear purpose, then a brief return format section, and a simple example. No wasted words or redundant elaboration.
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 read-only tool with two parameters and an output schema, the description covers the purpose, return format, and a usage example. It lacks edge-case discussion but is otherwise complete for typical usage, making it slightly above minimum viability.
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 descriptions cover both session_id and limit (including default), with 100% schema coverage. The description includes an example using both parameters but does not add semantic details beyond what the schema already documents. Baseline 3 applies.
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 states 'Retrieve message history from an opencode session' with a specific verb and resource, and further clarifies it returns the conversation transcript. This clearly distinguishes it from sibling tools like opencode_get_session (session metadata) and opencode_send_message (sending messages).
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 retrieving conversation transcripts but does not explicitly state when to use this tool versus alternatives or mention exclusions. It's clear context but lacks direct comparison to siblings like opencode_get_session or opencode_list_sessions.
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?
Annotations already declare readOnly and idempotent. Description adds the return format and example, but doesn't disclose any additional behavioral context such as error handling or performance. It adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear lead sentence, return format, and example. No redundant content.
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 getter with one parameter and an output format provided, the description is adequate. It could include error behavior, but it's not essential.
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 already describes session_id as 'Session ID to retrieve' with 100% coverage. Description adds an example value 'sess_01' but no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific opencode session' with a specific verb and resource, and clarifies it returns metadata and state, distinguishing it from list/session tools.
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?
No explicit guidance on when to use this vs alternatives like opencode_list_sessions, but the purpose and example imply it is for retrieving a single session by ID. Lacks exclusionary 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?
With no annotations, the description must disclose behavioral traits itself. It mentions the return format ('ToolResult with PrefabApp card and plain-text fallback') and implies read-only behavior via 'Show' and 'Lists,' but does not explicitly state read-only status, permissions, or edge-case behavior. This is minimally adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, followed by a clear alternative and return format. It includes only necessary information with no redundancy, achieving high impact in few words.
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 tool with one optional parameter, the description covers purpose, return format, and an alternative, but omits any explanation of the 'limit' parameter. Since there is no output schema, the return format mention is helpful, but the missing parameter semantics leave the description incomplete for full agent decision-making.
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?
The input schema has one parameter, 'limit,' with zero description, and schema description coverage is 0%. The description does not mention 'limit' at all, leaving its purpose, constraints, and optionality entirely up to inference from the name and default value. The description fails to compensate for the lack of schema coverage.
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 states 'Show opencode sessions as a rich Prefab card' and 'Lists recent opencode sessions,' clearly identifying the verb and resource. It also distinguishes from the sibling tool opencode_sessions by directing users to that tool for raw data, eliminating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative: 'Use opencode_sessions(action="list") for raw data instead,' which helps an agent decide between presentation and raw data access. However, it does not provide broader guidance for when to use this vs other session-related siblings like opencode_list_sessions, so it's not a full when/when-not set.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, providing safety context. The description adds the return format (success/message/data with diff dict) and states that it returns a summary with file paths and change types. This goes beyond annotations without contradiction, though it does not describe error cases or edge behaviors.
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 well-structured: purpose first, then return format, then example. Every sentence earns its place, though the return format block is slightly redundant given the output schema exists. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, read-only, annotated as safe), the description covers purpose, return format, and provides an example. It misses potential edge cases (e.g., nonexistent session) and detailed diff structure, but the output schema likely covers return values, so it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter (session_id with description 'Session ID to diff'). The description's example only demonstrates usage, adding no additional meaning or constraints beyond the schema. Baseline of 3 applies due to high schema coverage.
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 opens with a specific verb+resource: 'Show files created, modified, and deleted in a session.' This clearly distinguishes the tool from siblings like opencode_get_session (which likely retrieves session info) and opencode_send_message. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a diff of session changes) but does not explicitly state when to use it vs. alternatives like opencode_get_session or opencode_get_messages. There is no mention of exclusions or contexts where this tool is inappropriate. The example shows invocation but no guidance on selection.
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 annotations already declaring read-only and idempotent behavior, the description adds value by specifying that it returns basic connectivity status and uptime, and by providing the return format. No contradiction exists, though auth requirements and error behavior are not mentioned.
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 very concise and front-loaded. It provides the essential purpose, return format, and an example in a well-structured layout without redundant text. The example is trivial but does not detract.
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, read-only health check tool with an output schema, the description is complete. It states the purpose, return values, and example usage, covering all necessary aspects for an agent to invoke it correctly.
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 the description does not need to explain parameter semantics. The schema coverage is effectively 100% (vacuously), and the baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs a health check on the opencode server and returns connectivity status and uptime. However, it does not explicitly distinguish itself from the sibling tool 'opencode_server_status', so it lacks sibling differentiation.
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 use for health checking but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or conditions. The context is clear but lacks actionable usage direction.
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?
The description indicates a write operation ('Send') consistent with readOnlyHint=false, and adds return format details. However, it doesn't disclose potential errors, prerequisites (e.g., session must exist), or side effects beyond the basic send action. With minimal annotation coverage, this is a moderate disclosure.
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 succinct and front-loaded with the main purpose, followed by a usage note, return format, and example. Every sentence adds value without redundancy.
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 tool with two well-documented parameters and an output schema, the description covers the essential aspects: purpose, usage, return format, and an example. It lacks error handling details but is otherwise complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both session_id and message. The description adds no extra parameter semantics beyond the example, which mirrors the schema. Baseline 3 applies since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a message to an existing opencode session' and 'continue a conversation with a running agent.' This provides a specific verb and resource, distinguishing it from siblings like opencode_get_messages (reading) and opencode_run_agent (starting a new agent).
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 phrase 'Use this to continue a conversation with a running agent' gives clear context for when to use this tool. It implies that it is not for starting new sessions or reading messages, though it doesn't explicitly name alternatives or exclusions.
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?
Annotations already declare destructiveHint=true, and the description adds meaningful context: the shutdown is 'graceful,' returns a structured result, and requires confirm=True to execute. The return format and examples are additional behavioral disclosures beyond the annotations, though it doesn't detail side effects on active sessions or operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose, return format, and two examples. Every element is useful and directly supports invocation, with no redundant text or unnecessary detail.
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 shutdown tool with two parameters and an explicit output schema, the description covers the essential aspects: purpose, return format, and parameter usage. It lacks explicit handling of edge cases (e.g., what happens if confirm=False), but the schema already states that, making the tool adequately complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description reinforces this with examples (opencode_shutdown(confirm=True, reason="maintenance window")) but does not add significant new semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Shut down this MCP server process gracefully.' It uses a specific verb ('shut down') and resource ('MCP server process'), making the function unambiguous and distinct from sibling tools like opencode_server_status or opencode_get_health.
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 the tool is for terminating the server but does not explicitly state when to use it versus alternatives or provide exclusion criteria. The example with confirm=True/False hints at the safety mechanism, but no direct guidance on context or prerequisites is given.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds the return format and contents, which is useful but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction.
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?
Description is highly concise and well-structured: a one-line purpose statement, a bullet list of return contents, the return format in a code block, and a usage example. Every element earns its place, with no redundancy.
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 simple 0-parameter read-only tool with annotations and an output schema, the description is complete. It explains what the tool does, what it returns, and provides an example invocation. No significant gaps remain.
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, so baseline is 4. The description properly refers to the operation without needing parameter details. Schema coverage is 100% (empty schema), so no parameter information is missing.
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 'Read the full opencode configuration' with a specific verb and resource. It further specifies what the config includes (model, provider, MCP server settings, instructions), making it distinct from sibling get_* tools like get_session or get_project.
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?
Usage is implied by the description: use this tool to read the full opencode configuration. However, there are no explicit when-to-use or when-not-to-use guidelines, nor any mention of alternative tools for similar purposes.
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?
The description goes beyond the annotation (readOnlyHint: false) by detailing the actual modification of the config file, the dry_run option to preview changes, and the return format. It does not disclose edge-case behavior like overwriting existing server definitions, but the provided context is substantive.
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 well-structured with a purpose statement, return format, and examples. It is appropriately sized for the tool's complexity, though the first line repeats the tool name in all caps, which adds slight redundancy. Overall, it is efficient and front-loaded.
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 an install tool, the description covers the essential aspects: what it does, how it does it (unpack, extract manifest, merge), return values, and example invocations. It lacks explicit handling of conflict or error cases, but given the presence of an output schema and safe dry_run option, the information is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, so the description does not need to explain them further. The examples minimally illustrate usage (e.g., source path and name_override), but no extra semantic detail beyond the schema is provided, which aligns with the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and the resource ('MCPB bundle') with a specific target ('into opencode config'). It differentiates itself from the sibling tools, none of which perform installation, by explaining the unpacking and merging process.
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 context is clear: this tool is used for installing MCPB bundles, with no need for alternatives among the listed siblings. There is no explicit 'when not to use' or mention of alternative tools, but the uniqueness of the task makes the usage context sufficiently clear.
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?
Annotations (readOnlyHint, idempotentHint) already convey the safety profile. The description adds behavioral context by specifying the exact return envelope (success, message, data.project) and the nature of the output (project path and metadata), going beyond the annotations without contradicting them.
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 concise and front-loaded with a purpose statement, followed by a structured return format and an example. The example is largely redundant for a zero-argument call, but the overall layout is clean and every substantive part serves the agent's understanding.
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 simple, zero-parameter, read-only getter with strong annotations and an explicit return format, the description provides all needed context. It states the tool's purpose, its output structure, and an example invocation. Error cases are not documented but are not critical for this safe, idempotent operation.
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 the description does not need to explain parameter semantics. Schema coverage is 100% by default, and the baseline for zero-parameter tools is 4. The description appropriately avoids inventing unnecessary 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 states a clear verb-object pair ('Get the current project context') and further specifies the resource ('active project path and metadata'). This distinguishes it from sibling tools like opencode_get_session or opencode_get_config, which target different resources.
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?
Usage is implied by the phrase 'current project context' and the tool's zero-parameter signature, but there is no explicit guidance about when to use this tool versus alternatives or when not to use it. The description lacks exclusions or references to sibling tools.
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?
Annotations already mark this as destructive, but the description adds useful behavioral context: it only works on running or queued runs, and it specifies the return format. This goes beyond the annotations without contradicting them.
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 concise and well-structured: one sentence stating purpose, then a clearly labeled return format and example. Every section earns its place with no wasted words.
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?
This is a simple one-parameter tool with an output schema already providing return structure. The description adequately covers the purpose, scope, and usage, making it complete for the tool's 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?
The input schema fully describes the only parameter (job_id) as a string with description 'Job ID to cancel.' The description includes an example invocation that reinforces usage but does not add substantial semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Cancel a running or queued agent run.' It uses a specific verb (cancel) and resource (agent run), and distinguishes it from sibling tools like run_agent, get_run_status, and list_runs by specifying the action and applicable states.
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 indicates the tool is for running or queued runs, which gives clear context for when to use it. However, it does not explicitly mention alternatives or when not to use it, falling short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context by noting it returns accumulated stdout/stderr, status, and exit code, and can be polled repeatedly. No contradictions with annotations.
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 succinct and well-structured: a one-line purpose, a brief note on return content, a return format block, and an example. Every sentence earns its place without unnecessary verbosity.
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 single-parameter polling tool with output schema and annotations, the description is complete. It explains what the tool returns, provides an example, and references the source of job_id. No missing essential 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 job_id is described as 'Job ID from opencode_run_agent'. The description's example shows usage but does not add extra semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Poll' with a clear resource 'status of a background agent run'. It distinguishes from siblings like opencode_list_runs (listing runs) and opencode_cancel_run (canceling) by focusing on status polling for a single job. The example and return format further clarify its unique 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?
The description implies usage after launching a background agent, and the parameter schema references opencode_run_agent. However, it does not explicitly state alternatives or exclusions, such as using opencode_list_runs for batch status. The context is clear but lacks direct comparison to siblings.
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?
The description adds transparency beyond the minimal annotation (readOnlyHint=false) by disclosing the return format ('{success, message, data}') and explicitly labeling 'serve' as a background API server. However, it does not mention potential side effects such as long-running processes or how to stop them, which would be useful.
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 concise and well-structured: a one-line purpose, a usage sentence, return format, and examples. Every section earns its place with no redundant information.
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?
The tool is simple (2 optional parameters, one enum, output schema). The description includes return format and examples, and the schema covers parameter semantics. Combined with the usage guidance, it is fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description reiterates the enum meanings ('TUI, web UI, or background API server') and provides examples, but does not add additional constraints or formatting details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Launch opencode interactively') and distinguishes the three modes (TUI, web UI, background API server). It also states the intended use case ('manual work'), which differentiates it from sibling tools like opencode_run_agent.
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 phrase 'Use this to open the opencode interface for manual work' provides clear context for when to invoke this tool. It implies it is for human interaction rather than automated runs, but it does not explicitly name alternative tools or exclusions, so it falls short of a 5.
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?
Annotations already declare readOnlyHint and idempotentHint, so the safe read-only behavior is covered. The description adds the expected return format and a usage example, providing useful behavioral context beyond the annotations.
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 minimal and well-structured with clear sections for return format and example. Every line serves a purpose, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter readonly tool, the description fully covers purpose, return format, and usage example. The output schema is documented, and annotations provide safety context, making the tool complete for an agent.
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 and the schema has 100% coverage (empty properties). The baseline for no parameters is 4; the description doesn't need to explain parameters and instead focuses on return format, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List configured LLM providers in opencode' — a specific verb and resource. It clearly distinguishes from sibling tools like opencode_list_sessions and opencode_get_config.
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 by stating its purpose, but gives no explicit when-to-use guidance or alternatives. There are no exclusions or compared tools, so it's adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden but does well by disclosing the rich Prefab card format, status badges, and the plain-text fallback return format. It does not mention any side effects or auth, but for a read-only display tool this is sufficient.
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 brief and well-organized: first sentence states purpose, second provides an alternative, and a 'Return Format' section clarifies output. Every sentence adds value without redundancy.
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?
The description is largely complete for a simple tool: it gives purpose, alternative, and return format. The only gap is the unmentioned 'limit' parameter, which is a minor omission given the tool's simplicity and the parameter's self-descriptive name.
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?
The input schema has one param 'limit' with a default but no description, and the description does not mention it. Schema description coverage is 0%, so the description fails to compensate. The parameter name is somewhat intuitive, but the agent is left guessing about its exact semantics.
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 states 'Show recent agent runs as a rich Prefab card' with a specific verb, resource, and output format, effectively distinguishing it from the sibling opencode_runs tool. It also explicitly names the alternative for raw data, reinforcing its unique purpose.
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 gives explicit guidance: 'Use the plain opencode_runs(action="list") tool when you need raw data instead.' This clearly states when to use this tool versus the alternative, covering the primary decision point.
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?
The annotation readOnlyHint=false already indicates the tool is not read-only. The description adds valuable behavioral context by explaining that it launches a background job, returns a job_id, and can optionally block with wait=true. It also shows the return format. However, it does not mention potential side effects of running an agent (e.g., file modifications), which could be relevant for an agent-executing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a one-line purpose, a brief behavior note, a return format section, and two examples. Every section is purposeful and there is no wasted text. The use of a code block for the return format and examples improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema), the description covers the purpose, behavioral model, return format, and usage examples. It is mostly complete. Minor gaps include not explaining how to use the returned job_id with sibling polling tools, and not explicitly describing the 'status' values in the return format. However, the output schema and examples mitigate these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds value through examples that illustrate parameter usage (e.g., setting wait=False, format='json', timeout=120). The examples clarify how parameters interact, such as using timeout only when wait=true. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run an opencode agent with a prompt.' This is a specific verb+resource pairing that distinguishes it from sibling tools like opencode_list_runs (listing), opencode_get_run_status (status), and opencode_cancel_run (cancellation). The additional detail about launching as a background job further clarifies the unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: it returns a job_id for polling, and set wait=true to block until done. Examples demonstrate typical usage with wait and timeout. However, it does not explicitly exclude alternatives or mention when to use a sibling tool instead, such as opencode_get_run_status for checking job progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the return format (ToolResult with PrefabApp card and plain-text fallback), which is valuable behavioral context. It does not describe error handling or side effects, but for a read-only status tool the fallback behavior is a meaningful disclosure.
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 concise and front-loaded, with a clear main sentence, an alternative usage note, and a structured return format section. Every sentence adds value without redundancy, and the length is appropriate for the tool's simplicity.
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 status tool, the description covers the main purpose, displayed content, alternative raw-data tool, and return format. It could optionally mention it is read-only or contrast with the sibling opencode_server_status, but overall it provides sufficient information for an agent to select and invoke the tool correctly.
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 the schema requires no documentation. The baseline of 4 applies because no parameter descriptions are needed, and the description does not need to explain any input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Show') and resource ('opencode server status as a rich Prefab card'), and lists the exact content displayed (reachability, startup probe result, job counts). It distinguishes itself from raw data tools by explicitly naming opencode_system as an alternative.
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 advises using opencode_system(action="status") for raw data, which clarifies when not to use this tool. It does not provide extended scenario guidance, but the alternative is clearly stated and the context implies this tool is for rich UI presentation.
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?
Annotations already mark this as destructive (destructiveHint=true, readOnlyHint=false). The description adds context about rotation and disk guard, indicating automatic retention and disk-space checks. Examples show confirm=True for restore, hinting at overwrite semantics, though the schema provides the full safety details.
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 well-structured: a one-sentence summary, a return format block, and four concise examples. All elements are purposeful and front-loaded, with no filler.
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?
Given the rich input schema, output schema, and annotations, the description is complete enough. It covers the high-level purpose, provides usage examples, and the schema fills in action-specific details like restore safety and confirm requirement.
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?
Input schema coverage is 100% with detailed descriptions for all five parameters. The description's examples demonstrate valid parameter combinations and the 'rotation + disk guard' phrase adds meaning to the prune action beyond the schema's retention mention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it backs up the opencode database and config with rotation and disk guard, and supports restore. This distinct purpose is not covered by any sibling tools, which focus on runs, sessions, and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete examples for status, create, list, and restore, showing typical use cases. It says 'restore when needed' as a trigger, but does not explicitly state when not to use the tool or alternatives, though no natural alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds critical behavioral detail: 'Archive/unarchive/rename are reversible; delete is permanent (FK cascade).' It also explains the semantic differences between search, rag, and code, and the indexing prerequisites. This is substantial context that annotations alone do not provide.
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 dense but well-structured: a one-line action summary, focused bullet points on behavior, a clear return format block, and practical examples. Every line earns its place without redundancy or fluff.
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?
Given the tool's complexity (14 actions, 12 parameters), the description covers all main usage modes, dependencies (e.g., `uv sync --extra rag`), side effects (permanent delete), and a return format. The output schema already exists, so detailed return fields are unnecessary in the description. This is complete for a tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by showing concrete example parameter combinations (e.g., opencode_depot(action='code', query='extracted the auth module', path_filter='src')) and by explaining how parameters like `path_filter` and `query` are used differently in the code action. This goes beyond the schema descriptions.
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 opens with a clear enumeration of actions: 'list, inspect, archive/unarchive, rename, delete, search transcripts, semantic RAG search, code-recall search, or stats.' It also distinguishes the tool from siblings by stating 'Reads opencode's SQLite depot directly - works without `opencode serve`.' This makes the resource and scope 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 provides strong usage context: direct DB access without the server, and ample guidance on choosing between actions (search vs rag vs code). It also flags setup requirements: 'rag/code need `uv sync --extra rag` and an index pass.' However, it does not explicitly name alternative sibling tools or state when NOT to use this tool, so it stops short of a 5.
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/sandraschi/opencode-cli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server