Server Quality Checklist

Tool Scores

• opencode_send_messageB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It only says 'send' and 'return the response,' omitting that the tool may be long-running (despite the timeout_seconds parameter), can trigger file changes or command execution, and may block until completion. The prompting rules hint at side effects like running commands and writing files, but they are not framed as behavioral warnings. This is a significant transparency 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The core purpose is stated in a single opening sentence, and the PROMPTING RULES are structured as a bullet list, making them scannable. Each rule is actionable and not fluff, though some rules overlap with the schema's parameter descriptions. It is appropriately sized for a tool that depends heavily on prompt quality, but the redundancy with schema prevents a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 100% schema coverage and an output schema present, the tool description is fairly complete for parameters and return expectations (it says 'return the response'). However, it lacks explicit usage context (e.g., it requires opencode_start_session) and fails to disclose potential side effects or error scenarios. The description gives a good starting point but leaves gaps that the agent must infer from siblings and schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Since schema description coverage is 100%, the baseline is 3. The description adds value beyond the schema by offering general prompting rules (exact paths, numbered steps, command execution instructions) that complement the schema's examples. It emphasizes not to say 'the config file' but the full path, and clarifies that commands require a directory, which is extra semantic guidance not present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool sends a detailed instruction to an active opencode session and returns the response. This distinguishes it from session lifecycle tools like opencode_start_session and other provider prompt tools (gemini_prompt, qwen_prompt) by naming 'opencode' specifically. However, it does not explicitly compare with siblings or mention when to prefer this over gemini_prompt, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for active opencode sessions and provides extensive PROMPTING RULES about how to craft the message, but it does not state when to use this tool versus alternatives or give exclusion criteria. There is no explicit 'use this when' or 'not for' guidance, so it relies on context rather than direct comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_end_sessionA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that the tool closes a session and frees resources, which implies a state change. However, it does not explain whether the session's history is preserved, whether the action is reversible, or what side effects occur beyond resource freeing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two concise sentences, both front-loaded with essential information. Every word adds value, and there is no unnecessary repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and an output schema, the description is largely complete. It defines the action, when to use it, and the resource affected. A minor gap is the lack of information about session lifecycle after closing (e.g., can it be reopened, does history remain), but this is not critical for a basic close operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides a clear description for the single parameter ('Session ID to close') with 100% coverage. The description adds no additional context about the parameter format or semantics, so it earns the baseline score for high schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Close' and names the resource 'opencode session', clearly distinguishing it from siblings like opencode_start_session and opencode_shutdown. It also indicates the action's outcome ('free its resources'), providing a complete purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use the tool ('Call this when a task is complete') and provides a caution ('Do not leave sessions open indefinitely'). However, it does not name alternative tools or explain when not to use it, such as distinguishing from opencode_shutdown.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_get_historyA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the 'tracked in-process' nature and describes the message fields (role, content, timestamp). However, it does not mention behavior for invalid/missing session_id, ordering of messages, or potential errors. For a read-only tool this is acceptable but not fully 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the core purpose. The second sentence adds the message structure and a usage hint without unnecessary detail. Every sentence is useful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one parameter), has an output schema (so return format is covered elsewhere), and the description provides the essential message structure and a practical usage cue. It does not explain the ordering of history or error cases, but this is not critical given the output schema and straightforward nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has 100% coverage; the only parameter session_id is described as 'Session ID to retrieve history for.' The description does not add further parameter-specific semantics, but the schema is sufficient, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Return the full message history for an opencode session', specifying the verb (return), resource (message history), and scope (per session). It distinguishes from siblings like opencode_list_sessions (which lists sessions) and opencode_send_message (which sends), by focusing on retrieving history.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear usage context: 'Use this to review what has been sent and received before sending the next message.' This implies the tool is for reviewing prior conversation context. It does not explicitly name alternatives, but the context is clear and sufficient for an AI agent to decide when to call this versus other opencode tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• gemini_list_sessionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It accurately conveys a non-mutating operation ('List', 'Returns') and adds context about project scoping and response contents. It does not mention edge cases (e.g., empty list) or authentication, but these are less critical for a simple listing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler. The first sentence states the primary purpose, the second describes the return value, and the third provides a usage scenario. Every sentence earns its place, and the text is front-loaded with the main action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple list tool with full schema coverage and an output schema, the description is largely complete. It covers what the tool does, what the response contains, and when to use it. It lacks mention of error handling or prerequisites, but these are not essential for this low-complexity tool and are not expected to be documented given the output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides 100% coverage for the two optional parameters (project_dir and timeout_seconds) with their own descriptions. The tool description only indirectly relates to project_dir via 'current project' and does not elaborate on timeout_seconds behavior. Since the schema already handles parameter explanations, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'List' with resource 'saved Gemini CLI sessions' and scope 'current project'. It clearly states the return output (index and first-message preview), and the inclusion of 'Gemini' in the name differentiates it from the sibling tool opencode_list_sessions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states 'Use this to find a session_id to resume a previous conversation,' which is a clear, actionable use case. It implies this is the tool for Gemini CLI sessions rather than opencode sessions, but it does not name any alternative tools or explicitly state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_set_modelA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses immediate effect and scoping to new sessions, which are meaningful behavioral traits. It omits details like persistence across restarts or permission requirements, but for a simple setter this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the purpose, and every sentence adds value. No redundancy or irrelevant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 1-parameter setter, the description explains both the immediate effect and the session scope, while the output schema covers return values. It doesn't mention persistence across restarts, but the tool's behavior is largely clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers the single 'model' parameter fully with format, examples, and reference to opencode_list_models. The description adds no parameter-specific detail, so a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Change the default model used for all new opencode sessions' which uses a specific verb and resource, clearly distinguishing it from sibling session commands like opencode_start_session or opencode_list_models.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states 'Takes effect immediately for all subsequent opencode_start_session calls. Does not affect already-open sessions,' giving clear timing and scope. However, it does not explicitly name alternative tools or when to prefer them for per-session model selection, so it falls 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.

• qwen_check_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the return structure (authenticated bool, method, detail, suggestion) and the conditional behavior (if false, read the suggestion field with the exact command). This is transparent and useful, though it doesn't mention any side effects (likely none for a check).

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each serving a distinct purpose: purpose, usage, return values, and conditional guidance. It is front-loaded and contains zero fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple check tool with one parameter and an output schema, the description is complete. It covers what the tool does, when to use it, what it returns, and how to respond to a negative result. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema fully describes the single parameter (timeout_seconds with its own description), so schema coverage is 100%. The tool description adds no extra meaning about the parameter, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: 'Check whether the Qwen Code CLI is authenticated before making any qwen_prompt calls.' It identifies the specific resource (Qwen Code CLI) and the action (check auth), and distinguishes it from sibling tools like gemini_check_auth and opencode tools by referencing 'qwen_prompt' and Qwen-specific setup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: 'Always call this first if you are unsure whether Qwen is set up.' It also ties usage to qwen_prompt calls, giving clear context for when to invoke the tool. It doesn't mention when-not-to-use or alternatives, but for a check tool this is nearly complete.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• gemini_promptA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It discloses key behavioral traits: output contents, session_id creation, disk persistence, and context preservation across calls. It does not mention authentication or rate limits, but the disclosed session behavior and return format go beyond a vague 'sends a prompt'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections (MODEL SELECTION, SESSION CONTINUITY) and a front-loaded one-sentence summary. It is longer than average but every section serves a purpose, and the formatting makes it scannable. Minor redundancy with the schema prevents a 5.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 5 parameters, an output schema, and no annotations. The description covers purpose, model selection, session continuity, and prompt requirements comprehensively. It does not need to explain return values because an output schema exists. This is a complete, self-sufficient description for an agent to successfully invoke the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by summarizing model-choice semantics in a dedicated section and emphasizing the prompt-writing rules, even though the schema also details these. It also adds the output contract ('Returns response text, model used, and session_id') which is not in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Send a detailed prompt to the Gemini CLI. Returns response text, model used, and session_id.' This clearly identifies the tool's function and distinguishes it from siblings like opencode_send_message and qwen_prompt.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides detailed context for model selection by task complexity (default, complex, bulk) and explains session continuity, which serves as practical usage guidance. However, it does not explicitly compare against sibling tools like qwen_prompt or opencode_send_message, so it stops short of a full when/when-not explanation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• gemini_check_authA
  4.5/5.0
  Behavior4/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 return fields (authenticated, method, detail, suggestion) and instructs reading the suggestion when false. It implies a read-only check but could be more explicit about side effects or subprocess 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/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences with front-loaded purpose, clear usage directive, and useful return behavior. No filler or redundant content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple check tool with one optional parameter and an output schema, the description is complete. It covers purpose, usage, return values, and next-step behavior, making it adequate for agent decision-making.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% coverage for the single timeout_seconds parameter, which is fully described. The description adds no extra parameter detail, but the baseline of 3 applies since the schema handles it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Check whether the Gemini CLI is authenticated' before gemini_prompt calls. It distinguishes itself from sibling tools like qwen_check_auth by specifying Gemini 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/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is given: 'Always call this first if you are unsure whether Gemini is set up' and 'before making any gemini_prompt calls.' This provides clear when-to-use context relative to the prompt tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_list_sessionsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. The verb 'List' implies a read-only operation, and the qualifier 'currently active' clarifies the scope. It does not discuss auth or rate limits, but for a simple read-only list tool, the behavior is adequately disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: the first states the action and fields, the second gives a practical use case. No wasted words and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter listing tool with an output schema, the description is complete. It names the result fields, clarifies 'active' sessions, and explains a common usage scenario. No significant gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has no parameters, and the input schema is empty. According to the rubric, 0 parameters baseline is 4. The description adds no parameter details because none exist, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and the resource 'currently active opencode sessions', including the specific fields returned. This distinguishes it from sibling tools like opencode_get_history or opencode_start_session, which have different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly provides a use case: 'Use this to find a session_id if you have lost track of it.' While it does not name alternatives or exclusions, the guidance is clear and practical for a simple listing tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_shutdownA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden for behavioral disclosure. It explains the primary effect (closing all active sessions), the manner ('gracefully'), and a key non-effect: Gemini and Qwen are unaffected because they are stateless subprocesses. This adds meaningful context beyond the tool name, though it could mention consequences like unsaved work loss or idempotency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately concise: two sentences (or three clauses) front-load the core purpose and usage condition. Every sentence contributes: the first defines the action, the second specifies when to use it, and the third clarifies the scope of impact. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, straightforward shutdown action), the description covers all essential aspects: what it does, when to call it, and its non-effect on other tools. The presence of an output schema means return values don't need to be described. The description is complete for an AI agent to correctly select and invoke this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter-specific details, but none are needed. The schema is empty, and the description sufficiently describes when to invoke the tool without requiring parameter explanation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: 'Gracefully stop the opencode server and close all active sessions.' It uses specific verbs (stop, close) and names the resource (opencode server, active sessions), and the phrase 'all active sessions' distinguishes it from the sibling tool opencode_end_session, which likely ends only a single session.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The tool provides an explicit usage condition: 'Call this when you are done with all opencode work in the current session.' It also clarifies that Gemini and Qwen are not affected, helping the agent understand when this tool is not relevant. However, it does not explicitly name alternative tools for ending individual sessions, 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.

• opencode_start_sessionA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so the description carries the full burden. It discloses return values (session_id, model, project_dir) and the critical dependency that session_id is needed for opencode_send_message. This adds useful stateful context beyond the input schema, though it omits side effects like session lifetime or cleanup.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. Each sentence serves a purpose: stating the action, giving a prerequisite, noting return values, and providing usage context. No filler words or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema exists (which likely documents detailed return values) and no annotations are present, the description covers the essential contextual aspects: when to call, what it returns, dependency on session_id, and when to choose alternative tools. This is sufficient for correct tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with both parameters fully described in the input schema (format, defaults, examples). The tool description adds no additional parameter details beyond what the schema already provides, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Start a new opencode session,' which is a specific verb+resource. It clearly distinguishes from sibling tools by stating it must be called before opencode_send_message and by contrasting opencode with gemini_prompt/qwen_prompt for different task types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use ('Call this before opencode_send_message') and when to prefer alternatives ('For tasks requiring reasoning or research, prefer gemini_prompt or qwen_prompt instead'). This satisfies both positive and negative usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• qwen_promptA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses session persistence to disk ('Qwen persists session history to disk'), the session_id lifecycle, and the output components (response text, model, session_id). While it doesn't cover auth or errors, it covers the key behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with clear sections for purpose, model selection, session continuity, and prompt best practices. It is appropriately sized for a 5-parameter tool, with every sentence providing value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema exists and parameter descriptions are thorough, the description covers all essential aspects: purpose, model selection rules, session management, and prompt-writing guidelines. It is sufficiently complete for correct tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions. The tool description adds practical meaning by categorizing model choices (default, complex, etc.) and explaining the session_id continuity pattern, enhancing the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Send a detailed prompt to the Qwen Code CLI. Returns response text, model used, and session_id.' This identifies the verb, resource, and output. It also distinguishes from siblings like gemini_prompt by specifying the Qwen CLI.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit model selection guidance for different task types (default, complex, standard, bulk) and explains session continuation. However, it does not explicitly contrast with alternative tools, relying on the tool name to imply when to use Qwen vs. other models.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• opencode_list_modelsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It discloses that unauthenticated providers are excluded and explains the return structure (flat list, by_provider dict, total count, default_model). This adds meaningful behavioral context beyond the tool name, though it does not cover every possible edge case like error handling.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the primary function, followed by a behavioral note and a usage recommendation. Every sentence adds useful information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter listing tool with an output schema, the description is sufficiently complete. It tells what the tool returns, how to use it in the broader workflow, and a key filtering condition. No additional context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100% (empty schema). Per instructions, the baseline for 0 params is 4. The description adds value by explaining the purpose and return structure, but there are no parameter semantics to elaborate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states 'List all models available in opencode across all connected providers, grouped by provider.' The verb 'list' is specific, the resource is models, and the scope is explicit. It also distinguishes from sibling tools by noting its use before opencode_start_session.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Use this before opencode_start_session to pick the right model for the task,' which directly guides when to use it. Also notes that only authenticated providers return models, providing clear usage context and an implicit prerequisite.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.