Server Quality Checklist

Tool Scores

• claude_turnC
  2.9/5.0
  Behavior3/5

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

  Without annotations, the description carries the behavioral burden. It discloses that the tool returns structured statuses (pending/unknown/completed) and that it does not contain Observer-specific logic, which is useful. Still, it does not explain the side effects or durability semantics of 'issue' and 'recover' actions, or any preconditions.

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

  Conciseness3/5

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

  It is a single sentence, so it is compact, but the density of technical terms (aiterm, durable operation, Observer) without elaboration makes it less readable. It is not verbose, but borderline under-specified rather than genuinely concise.

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

  Completeness2/5

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

  Given no annotations, four parameters, and an output schema that is not referenced, the description leaves many gaps: what actions are available, what correlates with aiterm, what 'recover' means, and what the returned statuses imply. It gives only a vague overview without enough operational detail for an agent to confidently invoke the tool.

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

  Parameters1/5

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

  The description contains zero mention of the four parameters. Schema coverage is only 25% (only 'text' has a description), yet the description does nothing to compensate for the missing meaning of 'action', 'session_id', or 'operation_id'.

  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 a specific function: 'issue/recover durable operations on Claude sessions' for machine callers. It also notes the structured status returns (pending/unknown/completed) and the lack of Observer-specific logic, helping it stand apart from agent-focused sibling tools like claude_agent. However, the heavy use of jargon (aiterm, durable operation) slightly detracts from immediate clarity.

  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 phrase 'machine-caller dedicated surface' implies its intended audience, and the statement about returning pending/unknown/completed 'without parsing human-oriented error strings' suggests a use case. Yet there is no explicit 'when to use' or comparison with alternative tools, leaving guidance largely implicit.

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

• pty_listB
  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 full burden. It does not state if the operation is read-only, destructive, or requires authentication. The list nature implies a safe read, but this is not explicit.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently conveys the purpose and output fields. No unnecessary words.

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

  Completeness4/5

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

  Given the tool has no parameters and no output schema, the description is largely complete. It explains what is listed. It could potentially mention the return format, but it's adequate for a simple list.

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

  Parameters4/5

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

  There are no parameters, so the schema is trivial. The description adds value by listing the fields returned in the list, which is meaningful beyond the empty 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 that the tool lists sessions with specific fields (name, current command, attach status, size, agent info). It is a list operation, distinct from sibling tools like pty_open which likely opens sessions.

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

  Usage Guidelines2/5

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

  No usage context or when-to-use guidance is provided. It simply describes what the tool does without mentioning when it should be used versus alternatives like diagnostics or pty_open.

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

• claude_approvalA
  4.1/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. It discloses that inspect returns only the screen digest and safe single Yes/No, and that respond is conditional on matching operation and current digest. This provides meaningful behavioral context, though it does not cover all error cases or side effects of responding.

  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 a single dense sentence that efficiently conveys the main purpose, actions, and safety condition without wasted words. It is compact and front-loaded, though the multiple clauses make it slightly complex to parse.

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

  Completeness4/5

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

  An output schema exists, so return values need not be described. The description covers the two actions, what inspect returns, and the precondition for respond, which is sufficient for a specialized approval tool. It lacks details on mismatch handling or how to obtain session_id, but these are partially addressed by the schema hints.

  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 60%, and the schema already documents the optional parameters (operation_id, approval_choice, observed_prompt_digest) with useful descriptions. The tool description adds context for the action enum (inspect vs respond) but does not elaborate on individual parameters beyond what the schema provides. It adds some value but not extensive.

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

  Purpose5/5

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

  The description clearly states the tool's function as a dedicated surface for inspecting and responding to permission confirmation UI during an active Claude turn, preserving turn correlation. It distinguishes itself from sibling PTY tools by focusing on the approval context and the specific inspect/respond actions.

  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 specifies the intended scenario (permission UI during active Claude turn) and the safe usage pattern: inspect only retrieves a digest and simple Yes/No, while respond is only sent when the same operation and digest are still displayed. It implies this is the correct tool for approvals but does not explicitly name alternatives like pty_send or state exclusions.

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

• grok_agentA
  4.1/5.0
  Behavior5/5

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

  The description is exceptionally transparent about behavior: it shares HOME/cwd/env, owns only completion-state, injects delegation metadata, sends turns via pty_send as non-blocking, does not wait, defines exit codes (0/3/4), states no polling needed, and explains how to collect results via pty_read. This goes far beyond any annotations, which are absent.

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

  Conciseness3/5

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

  The description is information-dense but long and sprawling, packed into one continuous paragraph with mixed Japanese and technical details. While every sentence carries meaningful behavioral info, the lack of clear segmentation or prioritization makes it harder for an agent to quickly extract the key points. Not concise enough nor well-structured for maximum clarity.

  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?

  With an output schema present and parameters fully documented in the schema, the description provides extensive behavioral context: lifecycle, delegation, completion signaling, exit codes, and result retrieval. It even addresses compatibility and alternatives. Nothing critical for a caller is missing, making this complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already fully documents all 9 parameters. The description mentions model/reasoning_effort can be specified and that env_vars are inherited, but this mostly restates schema info without adding deeper meaning, so a baseline 3 is appropriate.

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

  Purpose4/5

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

  The description explicitly states it launches Grok Build's Grok model conversational agent TUI into a persistent terminal, identifying the verb and resource. It also clearly differentiates itself as an old-compatibility alias for agent_launch, which helps distinguish it from siblings, though the alias framing adds a bit of ambiguity about its intended use.

  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 says '旧互換alias。新規連携は agent_launch(harness=grok-cli)' meaning new integrations should use agent_launch instead, which provides clear when-not-to-use guidance. It also describes how to interact with the launched agent (via pty_send, no waiting, completion notifications), though it does not contrast with other sibling agent tools beyond agent_launch.

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

• pty_readA
  4.1/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 and does substantial work: it discloses the token-reduction pipeline (control-character removal, repetition compression, head+tail folding, restoration hints), the incremental read-offset default, and agent_transcript source semantics with operation_id rejection. It does not explicitly flag side effects like advancing the read cursor, but it is far from opaque.

  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 one dense paragraph but stays focused: main action, default behavior, reduction details, and the special agent_transcript mode. Each clause earns its place, and the core read action is front-loaded. It could be broken into bullets for scannability, but there is no filler.

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

  Completeness4/5

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

  The tool has 13 parameters and an output schema, and the description supplies essential high-level context that the schema alone does not: the reduction pipeline, the default cursor behavior, and the recovery purpose of agent_transcript. It does not walk through every wait/until/timeout combination, but the schema's 92% coverage and existing output schema compensate.

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

  Parameters3/5

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

  Schema coverage is 92%, so the baseline is 3. The description reinforces the purpose of key parameters such as agent_transcript and the incremental-read default that clarifies full, but it mostly echoes what the detailed schema descriptions already state rather than adding new per-parameter semantics.

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

  Purpose5/5

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

  The description opens with 'セッションの出力をトークン削減して読む' – a clear verb (read), resource (session output), and qualifier (token-reduced). It goes on to define the default incremental behavior and the agent_transcript special mode, distinguishing it from pty_send/key/list which act on the session rather than read from it. The action–resource pairing is unambiguous even without naming a sibling.

  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 states a clear default (incremental from last read position) and names a concrete recovery scenario for agent_transcript: '長い回答が screen tail で切れた時の回収用'. It provides clear context without explicit exclusions or named alternatives, which fits the 'clear context, no exclusions' level.

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

• agent_configureA
  4.2/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 burden of behavioral disclosure. It explains that the operation is non-restarting, preserves conversation context, and mutates model/reasoning settings, with a useful Cursor-specific constraint. It does not mention failure modes or side effects, but the core behavior is 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 compact and front-loaded: it states the core behavior first, then the method, then the special Cursor caveat. Every sentence adds information and there is no filler.

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

  Completeness4/5

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

  Given three parameters and available output schema, the description is sufficiently complete. It explains the operation context, the non-restart behavior, and the key harness-specific coupling. It could add a bit more guidance on failure conditions or where to get valid model identifiers, but the essential calling context is present.

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

  Parameters3/5

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

  The schema already documents model and reasoning_effort with 'omit means no change' semantics, and 67% of parameters have descriptions. The description adds the cross-parameter Cursor caveat that reasoning_effort must be changed together with model, but it does not provide value formats or allowed model identifiers beyond what the schema implies.

  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 identifies the action (change model/reasoning effort), the resource (already-started agent sessions for multiple harnesses), and the key constraint (no restart, context preserved). This distinguishes it from agent_launch and other session-oriented siblings.

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

  Usage Guidelines4/5

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

  It gives clear usage context: target existing sessions, avoid restarting, and use each harness's standard CLI model operation. It does not explicitly name alternatives or state when not to use the tool, but '起動済み' and '再起動せず' effectively separate it from launch/restart flows.

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

• diagnosticsA
  4.3/5.0
  Behavior4/5

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

  The description discloses read-only nature and explicitly states what data is not returned (PTY content, credentials, paths, environment values). Given no annotations, this provides sufficient behavioral transparency for a zero-parameter diagnostic tool.

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

  Conciseness5/5

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

  The description is two concise sentences with no wasted words. The key point ('read-only diagnostics returning safe vocabulary') 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, no-output-schema tool with no annotations, the description is complete. It clearly defines scope, safety guarantees, and exclusions.

  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?

  No parameters exist (schema coverage 100%), so the description does not need to add parameter meaning. The baseline of 4 applies as it adds no confusion.

  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 'Factory 向け read-only 診断' (Factory-oriented read-only diagnostics) and specifies that it returns only safe vocabulary in machine-readable JSON, explicitly listing excluded data types. This distinguishes it from sibling tools like pty_open or pty_list.

  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 Factory contexts via '向け' but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. Usage context is implied but not fully elaborated.

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

• agent_launchA
  4.4/5.0
  Behavior5/5

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

  With no annotations present, the description carries full behavioral disclosure burden. It comprehensively details the asynchronous fire-and-forget behavior, the shared environment (HOME, cwd, MCP, plugins), the injection of sub-agent self-awareness and delegation_allowed=true, the exact meaning of exit codes (0, 3, 4), the default timeout of 600 seconds, no polling/no foreground execution, and the return value collection via pty_read(agent_transcript:true). No contradictions exist.

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

  Conciseness4/5

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

  The description is lengthy but information-dense; every sentence contributes to understanding the tool's behavior and architecture. The core purpose is front-loaded, followed by clarifying details. Some minor over-specification occurs (e.g., the PowerShell 7 Start-Process note) but it serves to clarify platform-specific behavior. Overall, it earns its length, though slightly more focus would improve conciseness.

  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 complexity, the description is remarkably complete. It covers the launch flow, async behavior, completion mechanisms, exit codes, environment sharing, permission injection, and result retrieval. Although there is a declared output schema (not shown), the description also explains the receipt outcome semantics, making the agent fully equipped to invoke and interpret results without gaps.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 11 parameters are documented in the input schema itself. The description adds conceptual context (e.g., model is a separate axis from harness), but does not provide per-parameter elaboration beyond what the schema already offers. The baseline of 3 is appropriate since the schema does the heavy lifting.

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

  Purpose5/5

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

  The description explicitly states the tool's action: 'エージェントを単一の標準入口から永続sessionへ起動する' (launch agents to persistent sessions from a single standard entry point). It clearly distinguishes the conceptual axes of harness vs model, and explains how Grok Composer is specified via harness=grok-cli, which differentiates it from potential sibling-specific launch tools.

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

  Usage Guidelines4/5

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

  The description provides clear usage context: this is the single standard entry point for launching any agent, including via specific harnesses like Cursor or Grok Composer. It details the fire-and-forget pattern (parent does not wait), how completion notifications are received via wait_process or dispatch receipt, and explains exit codes and result retrieval via pty_read. It does not explicitly name alternative tools, but the '単一の標準入口' phrasing strongly implies it is the primary launch tool.

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

• agent_steerA
  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 the key behavior: it injects a message into the active turn and returns delivery=idle without sending characters when idle. It could add more detail about side effects or error conditions, but the core behavioral traits are covered.

  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 compact sentences in Japanese: the first states the purpose, the second adds the critical exclusions and idle behavior. No filler or redundant phrasing; each sentence carries essential information.

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

  Completeness4/5

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

  For a simple two-parameter tool with an output schema, the description covers purpose, usage constraints, and a specific return behavior (delivery=idle). It lacks details on session_id semantics and edge cases, but the core operational guidance is sufficient.

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

  Parameters3/5

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

  The schema already describes 'text' well (string to add to the current turn, UTF-8 max 64KiB), but 'session_id' is undocumented. The description's phrase 'additional message' aligns with 'text' but adds no new parameter-level meaning, and it does not compensate for the missing session_id documentation.

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

  Purpose5/5

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

  The description states a specific action: inserting an additional message into a running Codex/Grok agent to steer the current turn. It clearly distinguishes itself from starting an independent next turn, which separates it from launch/turn tools in the sibling list.

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

  Usage Guidelines5/5

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

  It explicitly says when to use (while an agent is running, to steer the current turn) and when not to use (when idle or wanting to start a new turn). The idle behavior with 'delivery=idle' further clarifies the intended usage window.

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

• pty_openA
  4.4/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, and it does well: it discloses that sessions persist across server/client restarts, that the backend is resident, and that platform-specific backends (tmux/psmux) are used. It does not mention cleanup, failure modes, or resource implications, but the main behavioral surprise—persistence—is clearly highlighted.

  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 dense, purposeful sentences: purpose and return value first, persistence semantics second, and a concrete usage example third. There is no filler or redundant restatement.

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

  Completeness4/5

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

  Given the low complexity, no annotations, and no output schema, the description covers the essential invocation contract: what is created, what is returned (session_id), why sessions persist, and how to interact with the terminal afterward. It could add exact response shape and failure conditions, but these are not critical for selecting and invoking the tool correctly.

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

  Parameters3/5

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

  The input schema already documents both parameters (name and shell) with 100% schema_description_coverage, so the baseline is 3. The description adds no additional semantic detail about the parameters themselves, which is acceptable given the 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 states the exact operation: opens one local persistent terminal (tmux on POSIX, psmux on Windows) and returns a session_id. It clearly stands apart from siblings like pty_read, pty_send, pty_list, and pty_close by describing the creation action.

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

  Usage Guidelines5/5

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

  The description explicitly tells the agent how to perform remote operations: do not use a dedicated tool; instead launch a terminal with pty_open and then run pty_send(session_id, "ssh host") inside it. This gives clear when-to-use and how-to-use guidance relative to the pty_* sibling tools.

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

• pty_closeA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that closing destroys logs and read position (destructive side effects), that retries are idempotent and safe, and that the tool returns a structured receipt with states 'closed' or 'already_closed'. This is rich, honest behavioral transparency.

  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 long, front-loaded with the core action, and every phrase earns its place. It covers purpose, side effects, retry behavior, and return type without any 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?

  Given the tool's simplicity (one required parameter) and the presence of an output schema (structured receipt), the description is sufficiently complete. It covers the action, the destructive side effect, the idempotency behavior, and the return format, leaving no major gaps.

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

  Parameters4/5

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

  The schema only defines session_id as a string with no description (0% coverage). The description compensates by explaining that session_id is used for retry safety, and that the same value will yield a receipt indicating whether it was newly closed or already closed. This adds meaningful semantics beyond 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 the tool's action: 'Close the session and discard logs/read position.' It uses a specific verb ('close') and resource ('session'), and distinguishes itself from sibling tools like pty_open, pty_send, pty_read, and pty_list by focusing solely on the closing lifecycle.

  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 when to use the tool (to close a PTY session) but does not explicitly contrast it with alternatives or provide exclusion criteria. It adds a safety note about retrying with the same session_id, but lacks explicit 'when to use vs. not use' guidance.

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

• claude_agentA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full behavioral burden and does so thoroughly: fire-and-forget launch, shared HOME/cwd/settings/MCP/plugin/permissions, injected delegation metadata, Stop-hook additions, pre-launch auth verification, and exact exit codes 0/3/4 with the rule that only exit 0 means done. This is unusually complete operational disclosure.

  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 long but dense; every sentence carries operationally relevant information and the alias/redirect note is front-loaded. Some parenthetical chains could be formatted more cleanly, but there is little redundancy for a tool with this level of behavioral complexity.

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

  Completeness5/5

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

  Given 9 parameters, no required parameters, and an output schema, the description still covers launch semantics, async handoff, completion receipts, auth preconditions, result collection, and sibling routing. With the output schema covering return structure, almost nothing an agent needs to invoke this correctly is missing.

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

  Parameters3/5

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

  Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds general context such as cwd/HOME/settings inheritance but does not attach new meaning to individual parameters like throughline_source_session or launch_operation_id. Baseline 3 is appropriate given that the schema does the heavy lifting.

  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 by identifying itself as an old-compatibility alias and redirects new integrations to agent_launch(harness=claude-code), then states it launches the Claude Code interactive-agent TUI on a persistent terminal. This is a specific verb+resource+scope framing that clearly distinguishes it from siblings and from claude -p.

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

  Usage Guidelines5/5

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

  It gives explicit when/when-not guidance: not claude -p, not a blocking wait, no polling, no foreground execution; continue input via pty_send, retrieve results via pty_read(agent_transcript:true) or claude_turn, and use agent_launch for new integrations. It also explains the async completion path and exit-code meanings.

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

• pty_keyA
  4.6/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 of behavioral disclosure. It reveals a significant behavioral trait: in Claude sessions, only C-c is permitted to preserve turn correlation, and that approval actions should be routed to claude_approval. However, it does not discuss error handling or consequences of sending disallowed keys, though the restriction itself is valuable transparency.

  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 core action and immediately followed by a key usage rule. Every word serves a purpose: examples clarify the key parameter, and the restriction clarifies boundary conditions. No redundancy or filler.

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

  Completeness4/5

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

  For a simple tool with no output schema and no annotations, the description covers purpose, parameter examples, and usage restrictions, and relates it to sibling tools. It does not explain session_id or return behavior, but these are less critical given the tool's straightforward nature and the presence of sibling tools like pty_list and pty_open that likely establish session context.

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

  Parameters4/5

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

  The schema covers only 50% of parameters (key has a description, session_id does not). The description adds meaning to the key parameter by listing acceptable aliases (C-c, C-d, Enter, Tab, Up, Down) and specifying a contextual restriction (only C-c in Claude sessions), compensating for the schema gap. session_id remains undocumented in both, but its purpose is implied as a session identifier.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('送る' / send) and resource ('制御キー' / control keys), and provides concrete examples (C-c, C-d, Enter, Tab, Up, Down) that distinguish it from sibling tools like pty_send (which likely sends arbitrary text) and claude_approval (which handles approval UI).

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool and provides an exclusion: 'In aiterm-correlated Claude sessions, only C-c is allowed to maintain turn correlation, and the approval UI is operated with claude_approval.' This names an alternative tool (claude_approval) and clarifies a key restriction, giving clear usage guidance.

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

• codex_agentA
  4.8/5.0
  Behavior5/5

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

  没有annotations，描述承担了全部行为披露责任。描述详尽展示了工具的行为模式：TUI启动方式、共享配置、注入的自我认知与委托权限、turn发送机制、完成通知的退出码（0/3/4）、结果获取路径、模型参数继承规则等。这些远超基本要求，没有任何隐藏行为。

  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?

  描述较长，但信息密度高，结构层次分明：先身份，再功能，然后共享配置、行为细节、调用示例、退出码、结果接收。开头即点明新老替代关系，有前置性。虽篇幅偏长，但对一个复杂交互式代理启动工具而言，每句都有实际价值。

  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?

  工具复杂度高（9参数、有输出schema），描述覆盖了启动、配置共享、委托链、退出码、结果获取、模型指定方式、调用示例，甚至包含了与pty_send/pty_read的交互模式。唯一未提的可能需要预先pty_open，但可通过兄弟工具推断。对于该工具，上下文已相当齐全。

  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覆盖100%，每个参数都有基础描述。描述额外增加了重要语义：prompt发送后即返、write_scope的read-only实际强制方式、model/reasoning_effort的继承及实効値确认、throughline注入等。虽然描述没有逐个重复参数，但补充了关键行为细节，超越了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?

  描述第一句即明确该工具是旧兼容alias，新集成应使用agent_launch，随后说明其核心功能是启动Codex对话代理TUI到持久终端，并用于实现、审查、调查。动词（起動）、资源（Codex TUI）和用途清晰，且与兄弟工具agent_launch的区分直接点明，不存在混淆。

  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?

  描述明确指出新規連携は agent_launch(harness=codex-cli)，给出了当not-to-use的条件和替代方案。同时通过调用示例和说明其适用场景（実装・レビュー・調査），提供了何时使用的上下文。使用指南完整且无歧义。

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

• composer_agentA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden and delivers thoroughly. It discloses non-blocking dispatch, that the parent does not wait, completion semantics with exit codes (0/3/4), no polling, no fallback to Grok, and environment/settings sharing. It also covers agent injection details and read-only sandbox support, leaving little behavior implicit.

  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 long and dense, but it is front-loaded with the most important routing information and every sentence adds operational value. Some points are reiterated for emphasis, and the density makes it harder to parse quickly, but the length is justified by the tool's complexity and the absence of annotations.

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

  Completeness5/5

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

  The description covers the full lifecycle: launch, parameter handling, async dispatch, completion notification via another process API, exit-code interpretation, result retrieval through pty_read, and error behavior. Since an output schema exists, return-value details need not be in the description. Nothing essential for correct invocation is missing.

  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 meaningful semantic context beyond the schema, especially for model (validated against live catalog with explicit error, no fallback), reasoning_effort (CLI/model-dependent), and the async dispatch relationship between prompt and pty_send. It does not elaborate on every parameter, but the schema already covers those adequately.

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

  Purpose5/5

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

  The description clearly states the tool's function: launching the Grok Build Composer model on a persistent terminal. It also explicitly identifies itself as a legacy-compatibility alias and names agent_launch as the replacement, distinguishing it from sibling tools without requiring schema inspection.

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

  Usage Guidelines5/5

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

  The description explicitly says to use agent_launch for new integrations, reserving composer_agent for legacy compatibility. It further explains the full usage flow: send turns via pty_send, receive completion via wait_process, retrieve results via pty_read, and avoid polling or foreground execution. This gives an agent clear when-to-use and when-not-to-use guidance.

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

• pty_sendA
  4.8/5.0
  Behavior5/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it explains send-only semantics, dispatch behavior with event_cursor receipt, fire-and-forget semantics, exit codes (0/3/4), no polling needed, foreground non-blocking execution, and the force:true caveat. This is far beyond what schema or annotations could convey.

  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 a dense single paragraph rather than a structured output, which hurts scannability. However, nearly every clause carries actionable information — alternatives, exit codes, constraints — so the length is earned. It starts with the core purpose and then layers on detail, but a bulleted structure would improve readability.

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

  Completeness5/5

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

  The description covers the full calling context: normal PTY vs agent dispatch, output retrieval, completion semantics, exit codes, sibling routing, and caveats like foreground execution and force mode. Since an output schema exists, return values don't need to be explained in prose. Nothing critical is missing for an agent to invoke this tool correctly.

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

  Parameters4/5

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

  The schema already covers 86% of parameters, so the baseline is 3. The description adds cross-parameter context that the schema does not: the mark+enter interplay for completion detection, force:true being restricted to non-Claude agent sessions and incompatible with active turns, and the relationship between receipt fields and process API usage. These are meaningful semantics beyond the schema.

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

  Purpose5/5

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

  The description opens with a clear statement of what the tool does: sends text to a session. It also explicitly differentiates itself from siblings by stating that output must be retrieved via pty_read, and that agent-session sends become automated dispatch, distinguishing it from pty_key, claude_turn, and claude_approval.

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

  Usage Guidelines5/5

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

  The description gives concrete routing guidance: use pty_read for result collection, use claude_turn for durable turns, use claude_approval for the approval UI, and do not use wait_command across process boundaries. It also clarifies when force:true is appropriate, which tells the agent exactly when this tool is or isn't the right choice.

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