Server Quality Checklist

Tool Scores

• day_recapC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states the output format (JSON) and content categories, but does not disclose behavior regarding the optional 'day' parameter, default behavior, or what the recap actually covers. This is insufficient for an agent to understand tool behavior beyond the basic output.

  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 sentence with no wasted words, clearly front-loaded with the core purpose. It lacks structural breakdown of the output fields, but that is not strictly required for conciseness. It earns a strong score for brevity.

  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?

  The tool is relatively simple with one optional parameter and an output schema, but the description lacks essential context: what 'day' expects, what happens if omitted, and how this differs from related tools. Given the output schema exists, not explaining return values is acceptable, but the usage context is missing.

  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 schema has zero parameter descriptions (0% coverage), and the description does not explain the 'day' parameter's format, allowed values, or default behavior. With only one parameter and no compensation in the description, an agent has no idea what to pass.

  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 indicates the tool produces a compiled day recap with specific categories (apps, away, meetings, agents) and notes the JSON output. It distinguishes from sibling tools that focus on current status or specific sessions, though it lacks an explicit verb like 'get' or 'retrieve'.

  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 is provided about when to use this tool instead of alternatives like active_now or what_was_i_doing. The description does not mention typical use cases, prerequisites, or exclusions.

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

• agent_sessionsC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden, but it only mentions the day scoping. It does not explain what 'sessions seen' means, how a local calendar day is interpreted (e.g., timezone), or what the response contains. This is minimal behavioral 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 a single sentence with no unnecessary words, making it concise and easy to parse. It is slightly under-specified but not padded, so it earns a high score for structure.

  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?

  Although the tool is simple with one optional parameter, the description omits critical context such as the output structure (even though an output schema exists, the description should clarify what sessions are listed), the meaning of 'seen', and how 'local calendar day' is determined. This is incomplete for an agent deciding to invoke it.

  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 for the undocumented 'day' parameter. It mentions 'local calendar day' but does not specify the day's format, accepted values, or the meaning of null default, leaving the parameter ambiguous.

  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 states that the tool shows Claude/Grok sessions seen during a local calendar day, which conveys the resource (sessions) and scope (a day). However, the verb 'seen' is vague and does not explicitly say 'list' or 'retrieve', and it does not distinguish this from sibling tools like day_recap.

  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 is given about when to use this tool versus alternatives like active_now or what_was_i_doing. It neither mentions appropriate conditions nor provides exclusions, so an agent has no basis for choosing it over siblings.

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

• sense_statusC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavioral traits. It does not explicitly state that this is a read-only status check, nor does it mention side effects, permissions, or rate limits. The phrase 'Daemon health, presence, last collect meta' implies informational use but does not clearly disclose behavior beyond that.

  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 extremely terse, at five words, which makes it efficient but under-specified. It lacks a subject-verb structure and reads as a fragment rather than a clear sentence. While it is front-loaded, its brevity sacrifices clarity, making it only partially effective.

  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 the tool has no parameters and an output schema exists, the description does not need to detail return values. However, the description is still cryptic, leaving terms like 'presence' and 'last collect meta' undefined. It provides minimal context for an agent to understand the tool's role, though it is adequate for a very simple status endpoint.

  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 are no parameter semantics to explain. The schema coverage is vacuously 100%, and the description does not need to elaborate on input. The baseline score of 4 is appropriate because no parameters exist and the description doesn't introduce confusion.

  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 is a noun phrase listing 'Daemon health, presence, last collect meta,' which hints at the tool's purpose but lacks an explicit verb such as 'get' or 'return.' It does not clearly state what the tool does with these items, making the purpose somewhat vague. It also does not differentiate itself from sibling tools beyond the implied system status subject.

  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 provides no guidance on when to use this tool versus alternatives. It neither states conditions for use nor mentions any exclusions or sibling tools. The context signals show sibling tools like 'active_now' and 'agent_sessions,' but the description does not help the agent decide between them.

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

• active_nowB
  3.1/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden for behavioral disclosure. It only lists content categories and does not mention return format, refresh semantics, permissions, side effects, or data source. All behavioral traits must be inferred from the tool name and content list.

  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 front-loaded noun phrase with no filler words, making it very compact. However, the absence of a main verb makes it slightly less effective as a complete tool description.

  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 an output schema, listing the three content areas is minimally adequate. But without annotations or usage guidance, the description leaves behavioral and contextual details unstated and does not resolve overlap with sibling tools.

  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 are no parameter semantics to document. The baseline of 4 applies because no parameter information is needed.

  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 identifies the three data areas returned: current presence, latest focus app, and open agent sessions. It lacks a main verb, making it a noun phrase rather than an explicit action statement, but the intent is readable. It does not explicitly differentiate from sibling tools that cover subsets of this data.

  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 is provided about when to use this tool versus alternatives. Sibling names like sense_status, what_was_i_doing, and agent_sessions suggest overlapping functionality, but the description offers no exclusion or preference cues.

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

• what_was_i_doingB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that events are summarized and coarse by default, and that limit caps event count. However, it does not explain what 'coarse' means, timezone handling, or whether it includes all-day events. It adds some behavioral context but is not comprehensive.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose and defaults. Every sentence earns its place without redundancy or filler. It is appropriately concise for the tool's simplicity.

  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 is simple and has an output schema (not shown), so the description does not need to detail return values. However, it lacks guidance on semantics of 'coarse' events, interactions with limit, and fit within the sibling toolset. The description is adequate for basic use but leaves ambiguity that could lead to incorrect invocation.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It does: it specifies day uses YYYY-MM-DD format and defaults to today, and limit caps event count. This adds clear meaning to both parameters beyond the bare schema, though it omits details like limit bounds or behavior when omitted.

  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 states the tool provides a timeline for a local calendar day, returning summarized events. The verb is implicit but the resource and action are clear: it retrieves what you were doing on a given day. It does not explicitly distinguish from sibling tools like day_recap, so it is clear but lacks differentiation.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives such as day_recap or active_now. It mentions default behavior (today, coarse) but does not specify use cases, exclusions, or preferability. This is a clear gap for a tool with several siblings.

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