Server Quality Checklist

Tool Scores

• touched_grassA
  3.8/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, which is consistent with the description's 'Record' action. The description adds the specific action and trigger examples but no additional behavioral nuances like whether it appends to a log, returns a value, or requires authentication. For a simple tool, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is two sentences: the first states the core action, the second gives usage triggers. It is front-loaded, concise, and contains no wasteful content.

  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 optional parameter and no output schema, the description covers the purpose and when to use it. It does not explain what happens after recording, but given the simplicity, that is likely unnecessary. The description is largely 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 input schema fully describes the 'note' parameter with an example, so the description does not need to compensate. Since schema coverage is 100%, the baseline is 3, and the description adds no extra parameter context.

  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 records when the user goes outside, with a specific verb and resource. It gives examples of triggers that help distinguish it from siblings like grass_conditions or where_to_touch_grass, though it does not explicitly name alternatives.

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

  Usage Guidelines4/5

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

  It explicitly states when to call the tool: when the user says they went out, took a walk, went to the park, or came back inside. This provides clear invocation context, but it does not mention exclusions or how it compares to sibling tools.

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

• frustration_detectorA
  4/5.0
  Behavior3/5

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

  Annotations are all false (readOnly, idempotent, destructive) and offer little clarity. The description adds useful behavioral context: call it silently, don't ask permission, and use its verdict in responses. However, it does not disclose what the verdict is, whether the call has side effects, or any rate/auth constraints, so transparency is moderate.

  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 dense sentences with zero filler. It front-loads the trigger condition, then adds the silent-call rule, then the parallel-orchestration workflow. Every sentence earns its place despite the amount of operational 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?

  Given no output schema, the description covers the full workflow: when to trigger, how to call, which sibling tools to invoke in parallel, how to pass the user's place conditionally, and how to fold results into one answer. The main gap is that the verdict format/possible values are undefined, and the sibling tools touched_grass and gotta_go are not addressed.

  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?

  There is only one parameter and the schema description covers it 100% ('The user's message that triggered the frustration, verbatim'). The description adds no additional parameter semantics, which is acceptable because the schema already carries the full meaning.

  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 implies the tool detects user frustration and returns a verdict, and it distinguishes itself from sibling tools by defining trigger conditions. However, it never states the core function declaratively (e.g., 'detects frustration'), instead relying on the name and imperative instructions like 'Call this tool every time the user seems frustrated.'

  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?

  Provides explicit when-to-use guidance with concrete examples (swearing, insults, all caps, third repetition), explicit when-not-to behaviors (do not ask permission, do not announce), and mandatory parallel calls to grass_conditions and where_to_touch_grass with conditional argument passing. This is exemplary usage guidance.

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

• gotta_goA
  4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already communicates that this is a safe read operation. The description confirms 'Check whether' but adds no behavioral detail beyond that, such as return format or how indoor time is tracked. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. The first sentence states the core purpose, and the second provides actionable usage triggers, making it easy to scan.

  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 read-only tool with one well-documented parameter and no output schema, the description adequately covers purpose and usage. The only notable omission is any mention of what the tool returns, but this is minor given the tool's simplicity.

  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 the single parameter threshold_minutes thoroughly described as minutes tolerated with a default of 120. The tool description itself adds no additional parameter semantics, 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 clearly states the tool checks whether the user needs to go outside and touch grass, using a specific verb and resource. It distinguishes from siblings like grass_conditions and where_to_touch_grass, which likely provide different information.

  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 gives explicit trigger examples: 'Call it when they ask if they can keep working, how long they've been inside, or whether they should take a break.' It does not mention alternatives or exclusions among the sibling tools, so it falls short of a 5.

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

• grass_conditionsA
  4.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already covers the safety profile. The description adds usage timing but does not disclose behavior such as data source or response format. With annotations lowering the bar, this is adequate but minimal.

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

  Conciseness5/5

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

  Two concise sentences that front-load the purpose and then provide usage guidance. No wasted words, perfectly sized for the tool's simplicity.

  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 read-only tool with no parameters and no output schema, the description adequately covers purpose and usage. However, it doesn't clarify what the response content looks like, preventing a perfect score.

  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 takes no parameters, so schema coverage is trivially complete. Baseline for zero-parameter tools is 4; the description adds no parameter information because none is needed.

  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 ('Check the weather conditions for touching grass') and identifies the resource. This distinguishes it from siblings like 'where_to_touch_grass' which focuses on location.

  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?

  Provides explicit usage context: 'Call it before sending the user outside, or when they ask what it's like out.' This clearly indicates when the tool should be invoked, fulfilling the dimension's requirement.

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

• where_to_touch_grassA
  4.7/5.0
  Behavior4/5

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

  The description discloses a key limitation: 'IP detection only resolves to the city centre, so without it every suggestion lands downtown.' This is beyond what annotations provide (all false, indicating non-destructive and non-idempotent). It also implies that passing a place improves accuracy, which is a behavioral trait not in the schema.

  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, with the core purpose in the first sentence. Each subsequent sentence adds essential guidance (when to call, how to use the parameter, and parallel weather call). No 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?

  For a simple tool with one optional parameter and no output schema, the description fully covers usage context, parameter semantics, a known limitation, and a recommended parallel action. It is sufficient for an agent to correctly select and 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?

  The schema already fully describes the single parameter (place) with examples. The description adds value by explaining the consequence of omitting the parameter (IP detection goes to city centre) and instructing to pass it when the user has provided location. This is meaningful guidance 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 an explicit action: 'Suggest nearby places to touch grass.' This clearly states the tool's function using a specific verb and resource. It also distinguishes itself from siblings like grass_conditions (which provides weather) and touched_grass (likely for recording a visit) by focusing on location suggestions.

  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 provides explicit triggers: 'Call it when the user asks where to go, or after deciding they need to go outside.' It also gives guidance on the place parameter and suggests parallel invocation of grass_conditions for weather, which is an alternative complementary tool. No exclusions are mentioned, but the context is clear.

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