Server Quality Checklist

Tool Scores

• send_chatC
  2.4/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 behavioral disclosure burden. It describes GUI automation steps (focus, open, paste, submit), implying it interacts with a desktop application, but doesn't disclose side effects (e.g., does the message persist in the input box if send=false? Does it overwrite the current draft?), timing/speed, or whether it can fail verification steps. The send/backend parameter behaviors are entirely unexplained.

  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 a single, reasonably short sentence and is front-loaded with the verb action. However, it compresses too much behavioral nuance into one clause and omits important clarifications about parameters, so brevity here sacrifices useful detail rather than achieving efficiency.

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

  Completeness2/5

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

  With an output schema present but zero description coverage of parameters and no annotations, this tool is underspecified for reliable autonomous invocation. The GUI-automation nature (focus window, paste, submit) carries real risks (wrong window focus, missed steps) that aren't disclosed. Sibling overlap with open_chat and type_text further complicates correct selection. There's enough written to guess at the intent but not to execute reliably.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but only the message content is implied by 'paste a message'. The send boolean and backend enum are completely unexplained—the agent can't know what 'backend' means functionally or what tradeoffs between pydirectinput/pyautogui/auto are. The maxLength=240 constraint on message is also not called out despite being a meaningful limit the agent should know.

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

  Purpose3/5

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

  The description states a clear action ('Focus Sky, open chat, paste a message, and optionally submit it') with a specific resource (Sky chat) and verb sequence. However, it's somewhat ambiguous—'Focus Sky' implies activating a window but doesn't clearly distinguish whether this creates a new message or replies to an existing thread. Sibling tools like open_chat and type_text overlap considerably, so it's unclear what unique job this performs vs those.

  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 guidance on when to use this vs alternatives. With siblings open_chat, type_text, press_key, and read_screen, the description doesn't clarify whether this is a combined convenience tool, when one would prefer it over calling open_chat + type_text individually, or any prerequisites (e.g., must a chat be already open?). The 'optionally submit it' phrasing hints at the send=false behavior but no explicit guidance is given.

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

• type_textC
  2.7/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 of behavioral disclosure. It discloses the prerequisite state (focused, open chat) but does not describe how 'paste' behaves vs typing, whether the text is submitted immediately, what the 'send' parameter controls behaviorally, or how backend variations (pydirectinput vs pyautogui) affect execution. For a tool with zero annotation coverage, this is a notable gap.

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

  Conciseness4/5

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

  The description is a single short sentence that front-loads the purpose and prerequisite. Every word earns its place, and there's zero padding. It doesn't overexplain or repeat schema content. While it could add more behavioral context, its brevity is appropriate for a one-line tool.

  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?

  Given the tool has 3 parameters (one with a behavior-affecting enum backend), no annotations, and 0% schema description coverage, the description is thin. An output schema exists, which covers return values, but the behavioral semantics of send and backend, the interaction between this tool and send_chat/press_key, and failure modes (unfocused chat) are all undocumented. Adequate but with clear gaps for an agent to operate reliably.

  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 0%, so the description should compensate for the three parameters. However, it adds no parameter-level detail beyond what the schema provides: 'message' has min/max length, 'send' has a default, and 'backend' has an enum in the schema. The description's mention of 'paste' hints at how the message is entered but doesn't elaborate on send or backend semantics. With 0% coverage and multiple parameters, the description only marginally helps.

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

  Purpose3/5

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

  The description states the verb+resource+context clearly ('paste into an already-focused, already-open Sky chat box'), which defines what it does and distinguishes it from open_chat (opens the chat) and send_chat. However, it doesn't explicitly clarify how it differs from send_chat — both seem to involve delivering a message to the Sky chat box, which could confuse an agent about which to use.

  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?

  The description implies the tool requires an already-focused and already-open chat box ('already-focused, already-open'), which conveys prerequisite context. However, it provides no when-to-use/when-not-to-use guidance and doesn't differentiate from siblings send_chat or press_key, leaving the agent to infer when this tool is the right choice.

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

• take_screenshotB
  3.1/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It reveals no behavior whatsoever beyond being an alias - no mention of what the screenshot captures, dimensions, return format, or side effects. For a tool with zero annotation coverage, this is a significant 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 description is a single short sentence that front-loads the key information ('Compatibility alias') and names the canonical counterpart. It is appropriately terse given the tool's trivial nature, with no wasted words.

  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?

  Given that this is a compatibility alias with zero parameters and no output schema, the contextual burden is low. However, it fails to disclose the actual behavior (what the screenshot captures, return format), deferring entirely to the sibling 'screenshot'. For a trivial alias, this may be acceptable, but it relies on the agent already understanding the screenshot 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 0 parameters, and schema coverage is 100%, so there is nothing for the description to add about parameters. With no parameters to document, the baseline of 4 is appropriate - the description and schema are complete on this dimension.

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

  Purpose3/5

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

  The description states 'Compatibility alias for screenshot,' which tells the agent this tool is effectively the same as screenshot. It identifies the intended resource (screenshot) but provides no verb or direct purpose; the actual function must be inferred from the sibling 'screenshot.' It does implicitly distinguish itself from siblings by naming screenshot as the canonical tool.

  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 the tool is a compatibility alias rather than a primary tool, suggesting users/agents should prefer 'screenshot'. It names the canonical alternative but doesn't explicitly state 'use screenshot instead of this' or describe any conditions for when this alias is preferable.

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

• screenshotB
  3.2/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 of behavioral disclosure. The description states it captures a screenshot and returns a PNG, but does not disclose behaviors like whether it waits for the window to be ready, what happens if no verified Sky window exists, the resolution/output size, or whether it scrolls/captures the full page. The 'verified' qualifier hints at validation behavior but is never explained.

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

  Conciseness5/5

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

  A single concise sentence conveys purpose and output format with zero wasted words. The qualifier 'only the verified Sky window' is meaningful scoping rather than filler.

  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?

  For a zero-parameter tool with no output schema, the description is reasonably complete on inputs and format. However, the 'verified' qualifier creates ambiguity about behavioral prerequisites (when is the Sky window considered verified?), and with siblings like 'take_screenshot' and 'read_screen' present, the lack of differentiation leaves the agent unsure which screenshot tool to pick. The tool is simple enough that a 3 is fair, but it could do more to resolve sibling ambiguity.

  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 100% schema coverage (vacuously, since there are no params). With 0 params, the baseline is 4. The description adds the PNG return format detail, which is useful since there is no output schema to convey it.

  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 captures a screenshot and returns a PNG image. The qualification 'only the verified Sky window' adds specificity about scope. However, given the existence of sibling tools 'take_screenshot' and 'read_screen', the description does not explicitly distinguish itself from these alternative screenshot-related tools.

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

  Usage Guidelines2/5

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

  The description mentions 'verified Sky window' but does not explain when to use this tool versus the siblings 'take_screenshot' or 'read_screen'. There is no guidance on prerequisites (what does 'verified' mean, when is a Sky window considered verified) or when an alternative should be preferred.

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

• open_chatB
  3.3/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 full burden of behavioral disclosure. It mentions a permission precondition, which is useful, but doesn't disclose any behavioral side effects (e.g., does it focus a window, create a UI state, require a status check first?). The prerequisite note adds some value beyond what structured fields provide.

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

  Conciseness5/5

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

  A single concise sentence, zero waste, front-loaded with the core action. This is appropriately minimal for a simple tool.

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

  Completeness3/5

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

  The output schema exists but isn't shown in detail, so the description needn't explain return values. The permission precondition is mentioned, but for a tool with no annotations and a critical prerequisite, the description could go further—e.g., how to verify permissions or what error behavior occurs when they're absent. It's adequate but leaves meaningful gaps for a state-dependent UI action.

  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 0%, but there's a single optional 'backend' parameter with an enum (auto/pydirectinput/pyautogui). The description doesn't add context about what 'backend' means or how the choice affects behavior, which would help. However, with one optional parameter with a clear enum, the schema largely speaks for itself, keeping the gap small.

  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 verb+resource construct 'Open Sky chat' clearly states what the tool does, and the constraint 'when both input and chat permissions are enabled' indicates a precondition. However, it doesn't clearly distinguish from siblings like send_chat (though the distinction is implied by 'open' vs 'send').

  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?

  The description mentions a precondition ('when both input and chat permissions are enabled') but doesn't tell the agent how to check those permissions or what to do if they aren't enabled. There's no guidance on when to use open_chat vs send_chat, and no mention of alternatives or exclusions.

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

• press_keyA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal that the tool verifies and focuses the Sky process before pressing, which is useful behavior. However, it doesn't disclose what happens if the key isn't allowlisted, what 'verifying and focusing' entails in failure terms, or side effects like whether focus is retained after pressing.

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

  Conciseness5/5

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

  A single, information-dense sentence that conveys the action, scope, and preconditions. Zero wasted words. The key behavioral facts (game context, verification, focusing) are all packed efficiently.

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

  Completeness3/5

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

  The tool has 3 parameters with 0% schema coverage and no annotations, so the description carries heavy burden. It explains the tool's core behavior well but leaves the backend enum, duration range, and valid key formats unexplained. An output schema exists which helps, but with zero param documentation elsewhere, more detail on allowed key values would materially improve completeness.

  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 0%, so the description must compensate for the three parameters. It names the game key concept but doesn't explain valid key string formats, what the backend enum values mean, or what duration_ms controls. The description's mention of the game provides some context for the key parameter but nothing for backend or duration_ms beyond what defaults suggest.

  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 verb (press) and resource (one allowlisted game key) plus adds the important qualifier 'after verifying and focusing the Sky process.' This distinguishes it from text entry tools like type_text/send_chat. However, it doesn't explicitly distinguish from screenshot/read_screen siblings, though those are clearly different. The context about 'allowlisted' and 'Sky process' adds meaningful specificity.

  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 says the tool presses keys only within the Sky game context, implying it should not be used for general typing (which belongs to type_text). 'Allowlisted' implies only certain keys are accepted. However, there's no explicit when/when-not guidance or reference to alternative tools like type_text or send_chat for text entry tasks.

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

• read_screenA
  3.6/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'verified Sky window' and that OCR output is produced, but doesn't disclose details like whether the window must be focused, whether OCR fails gracefully, or what the raw screenshot is retained or discarded. Some useful context but not rich.

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

  Conciseness4/5

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

  The description is a single efficient sentence: 'Capture the verified Sky window and run local OCR.' Zero waste, action-oriented, front-loaded with the verb. Could arguably mention alternatives or output format, but the brevity is appropriate for a simple zero-parameter tool.

  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 zero parameters but an output schema exists, which presumably documents the OCR results. The phrase 'verified Sky window' hints at a prerequisite (the window must be verified first, likely by a status/open_chat sibling). For a simple, zero-input capture-and-OCR tool, the description is reasonably complete given the output schema covers return values.

  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 there's nothing for the schema to document and nothing for the description to explain. A baseline 4 is appropriate for a no-parameter tool since parameter ambiguity cannot exist.

  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 verb (capture + run OCR) and the resource (the verified Sky window). It names two related sibling tools (screenshot, take_screenshot) but doesn't explicitly distinguish from them beyond mentioning OCR and the Sky window. Purpose is fairly clear with specific scope.

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

  Usage Guidelines3/5

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

  The description implies this is used when you need OCR text from the Sky window rather than a raw image. However, it doesn't explicitly say when to use this vs screenshot/take_screenshot, nor does it state exclusions. The 'verified Sky window' phrase implies a prerequisite state, which is helpful context.

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

• statusA
  3.7/5.0
  Behavior3/5

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

  The description discloses that the tool reports on three specific areas: permissions, OCR availability, and game-window status. Since this is a report/read-only style tool and no annotations exist to contradict it, the main risk is mitigated. However, it doesn't clarify whether the tool is purely non-destructive, what 'verified game-window status' precisely entails, or whether it might trigger side effects (e.g., launching/attaching to a game). With no annotations, the description carries the burden but only partially fulfills it.

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

  Conciseness5/5

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

  A single, focused sentence that enumerates exactly what the tool reports. Zero waste, front-loaded with the verb, and covers the three key outputs (permissions, OCR, game-window). This is exemplary economy for a no-argument status tool.

  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 takes no parameters and has an output schema (which presumably documents return values), so the description only needs to explain what the tool reports on. It does that concisely. Given zero complexity in inputs, the description is adequate and slightly above baseline since it teases out the three distinct report areas, but it could be more complete about the resolved status semantics (e.g., 'verified' meaning).

  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 with 100% schema coverage (empty schema is fully captured). Baseline for 0 params is 4, and the description adds value by explaining what the status output covers. There's nothing more to document about parameters, so this is appropriately handled.

  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 uses a clear verb ('report') with a specific resource focus: permissions, OCR availability, and game-window status. It distinguishes itself from sibling tools which are action-oriented (screenshot, type_text, press_key), making it clearly a state-inspection tool. However, it doesn't explicitly contrast with siblings that could overlap, like read_screen.

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

  Usage Guidelines3/5

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

  The description implies this is a status/health-check tool (check permissions, OCR, game-window), giving usable context for when to invoke it. However, it doesn't provide explicit when-to-use vs when-not-to-use guidance or mention alternatives for related inspection tasks. The usage context is reasonably clear but lacks explicit exclusions or alternatives.

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