Server Quality Checklist

Tool Scores

• snapshot_readC
  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 must expose behavioral traits. It reveals ordering and return content (paths) but does not state that the operation is read-only, mention any side effects, authentication needs, or error behaviors. The read-only nature is implied but not explicitly disclosed.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the key action and result details without waste. Every word contributes value.

  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?

  While the tool is simple with only optional parameters and no output schema, the lack of parameter explanations and absence of any behavioral caveats makes the description incomplete for safe and correct invocation. An agent would need to guess the semantics of 'limit' and 'session'.

  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?

  Schema description coverage is 0% for the two parameters (limit, session), and the description does not explain their meaning or format. The agent cannot infer what values to provide or how they affect results, leaving a significant gap.

  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 it lists captured screen snapshots for the meeting, with ordering (newest first) and content (paths). It implicitly distinguishes from sibling tool snapshot_request by focusing on reading existing snapshots rather than requesting new ones, but does not explicitly name the alternative.

  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 on when to use this tool versus alternatives like snapshot_request. The phrase 'for this meeting' implies meeting context but lacks explicit when-to-use or when-not-to-use instructions.

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

• summaryC
  2.9/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 behavioral disclosure. It mentions saving and a panel offering copy/download, but does not explain persistence, permissions, reversibility, or response behavior. 'Save' implies mutation but lacks important details.

  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 brief and front-loaded with the primary action. The second sentence about the panel adds useful context, though it is somewhat vague. Overall, it is concise without excessive fluff.

  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?

  This is a mutation tool with no annotations, no output schema, and incomplete parameter explanations. The description provides the core purpose but leaves significant gaps about usage, parameters, and side effects, making it incomplete for reliable tool invocation.

  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 coverage is 0%, so the description must compensate. It explains that 'markdown' is the content format, but the 'session' parameter is completely unaddressed. The description adds minimal meaning beyond the parameter names.

  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 saves the post-call wrap-up as markdown, specifying the verb 'save' and the resource ('post-call wrap-up') and format ('markdown'). However, it does not explicitly distinguish this from related sibling tools like 'transcript' or 'working'.

  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 'post-call wrap-up' implies this tool is used after a call, giving some usage context. However, there is no explicit guidance on when to choose this over alternatives or any exclusions.

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

• pollB
  3.2/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden. It discloses the key behavior of returning only new data and tracking offset server-side, which implies a non-idempotent, stateful operation. However, it does not mention side effects like consuming the updates or what happens if there is no new data. The transparency 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, front-loaded with the core purpose ('Everything new since your last poll'). It includes a concise list of return contents and a critical behavioral constraint. Every sentence earns its place with no waste.

  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 no output schema or annotations, so the description must explain the return format and usage context. It lists the three types of returned data (transcript batch, panel state, pending results) and notes the single-call-per-turn constraint. However, it leaves the 'session' parameter unexplained and does not clarify what to do with the returned data or how errors/empty states are handled. For a polling tool, this is a notable gap.

  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 one optional parameter 'session' with no description and 0% schema description coverage. The tool description completely ignores this parameter, offering no explanation of what 'session' represents or how it affects the call. The description adds zero semantic value beyond the raw schema, failing to compensate for the coverage gap.

  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 returns new updates since the last poll, listing specific content (transcript batch, panel state, pending results). It distinguishes itself from siblings by focusing on delta updates, though it does not explicitly name alternatives. The purpose is clear enough for an agent to understand what the tool does.

  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 provides usage guidance: 'One call per turn' and the note about server-side offset tracking imply a polling pattern. However, it lacks explicit exclusions or comparisons to sibling tools (e.g., 'use transcript instead for full history'). There is no clear 'when not to use' guidance, so the score is below a 4.

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

• adviceB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the content format and marker meanings but does not disclose side effects, return behavior, session semantics, or any limitations of the side-panel display, leaving significant behavioral gaps.

  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 highly efficient. It packs marker definitions into a compact, readable list without any 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?

  For a simple display tool with no output schema or annotations, the description covers the primary behavior and content semantics well. However, the unexplained `session` parameter and lack of details about side-panel interaction (e.g., persistence, replacement) leave gaps that an agent would need for fully correct invocation.

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

  Parameters3/5

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

  The description adds meaning to the `marker` parameter by defining each enum value and provides guidance for `text` (keep it one glanceable sentence). However, the `session` parameter is completely undocumented, and with 0% schema description coverage, the description only partially compensates for the missing parameter explanations.

  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's action and target ('Show a line in the side panel') and enumerates the marker categories, which clarifies its purpose. It does not explicitly distinguish from sibling tools, but the side-panel UI and marker semantics make it distinctive enough.

  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?

  Usage is implied through the marker definitions (e.g., use RISK for a problem, ACTION for a to-do), but the description does not explicitly say when to use this tool over siblings like `chat_reply` or `speak`, nor does it provide exclusions or prerequisites.

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

• itemB
  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 disclose side effects, permissions, or persistence behavior beyond the implied 'add' action. It also doesn't describe what happens to existing items or whether duplicates are allowed, which is a significant gap for a mutating 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 highly concise, consisting of a single sentence with two clauses. It front-loads the core action ('Add to the decisions and action-items board') and immediately follows with a key constraint. Every word earns its place.

  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 has five parameters and no output schema, yet the description offers no context on parameter usage, expected outcomes, or integration with sibling tools. It barely covers the basic purpose, leaving the agent to infer field semantics and any board-specific behavior.

  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?

  Schema description coverage is 0%, and the description does not explain any of the five parameters (kind, text, owner, session, blocked_by). There is no compensation for the low schema coverage, so the agent has no semantic guidance 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 function: 'Add to the decisions and action-items board.' It also distinguishes scope by specifying 'Only for things actually decided or assigned, not for topics discussed.' This is a specific verb+resource and provides a clear boundary.

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

  Usage Guidelines4/5

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

  The description explicitly states when not to use it ('not for topics discussed'), providing a clear exclusion criterion. However, it does not name alternative tools, so it falls short of fully explicit alternatives, but the when-not guidance is strong.

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

• speakA
  3.5/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 the platform limitation and failure mode ('fails with an explanation elsewhere'), which is valuable. However, it does not explain the effect on the call (e.g., whether it interrupts, requires an active call, or is asynchronous), leaving behavioral uncertainty.

  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 short sentences, front-loaded with the action, no filler words. Perfectly 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?

  For a tool with 4 parameters, no annotations, and no output schema, the description is too sparse to be fully complete. It omits parameter meanings and deeper behavioral context, making it adequate only for a very simple use case.

  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 input schema has 0% description coverage and the description provides no elaboration on parameters like voice, device, or session. It only implies that 'text' is the content to speak. The description does not compensate for the schema's lack of 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 clearly states the tool's function with a specific verb ('Say') and resource ('something out loud into the call'), and the phrase 'out loud' differentiates it from text-based chat tools like chat_reply. It also adds a platform constraint. The only slight weakness is that 'something' is generic, but the intent is unambiguous.

  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 a clear context (speaking aloud into a call) and an explicit when-not constraint (only local macOS installs, fails elsewhere). However, it does not name alternative tools or provide explicit comparison criteria, so it stops short of a 5.

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

• call_chatA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses return behavior ('Returns the delivery result') and indicates failures are reported via polling ('poll reports failures too'). It does not mention safety, permissions, or rate limits, but for a simple send operation this is acceptable partial disclosure.

  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 and front-loaded with the primary purpose. The second sentence adds valuable behavioral details about the return value and failure reporting. No words are wasted.

  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 relatively simple, but the description leaves gaps: it does not clarify what 'session' refers to, what the 'delivery result' looks like, or how polling for failures works. Given no output schema and no annotations, a bit more detail would improve completeness.

  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?

  The input schema lists two parameters (text and session) with no descriptions (0% coverage). The description clarifies that 'text' is the message content ('Send a message'), but it does not explain the 'session' parameter at all, leaving users to infer its meaning.

  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: 'Send a message into the meeting chat, visible to everyone.' It uses a specific verb (send) and resource (meeting chat) and distinguishes from siblings like chat_reply by emphasizing visibility to everyone.

  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 'visible to everyone' implies the tool is for public messages, which provides some usage context. However, it does not explicitly state when to use it versus alternatives like chat_reply, nor does it mention any exclusions or prerequisites.

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

• chat_replyA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about the private side panel vs. meeting chat, but does not explain side effects, return values, permissions, or the session parameter. This is minimal but not misleading.

  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 main action (reply in side panel chat) and immediately clarifies the common confusion (not meeting chat). Every word earns its place.

  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, but the description lacks explanation of parameters and return behavior. Given no annotations and no output schema, the description is sufficient for purpose but incomplete for full invocation confidence.

  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 0% documentation coverage, and the description does not explain the 'text' or 'session' parameters at all. The description adds no semantic value beyond the raw schema, leaving the agent uninformed about parameter purpose.

  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: replying in the side panel chat. It explicitly distinguishes this from the meeting chat by naming call_chat as the alternative, making it easy to understand the tool's specific role.

  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 an explicit when-not-to-use and names the alternative tool (call_chat) for the meeting chat. However, it does not mention other sibling tools like speak or attach, so guidance is incomplete but adequate for the primary alternative.

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

• attachA
  3.8/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 the refusal behavior and the force condition, which is valuable. However, it doesn't explain what 'report its state' means, any permissions needed, or consequences of force beyond attaching.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the main action, then usage instruction, then a caveat. Every word earns its place.

  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 2-parameter tool with no output schema, the description covers purpose, timing, and a key edge case. It could clarify what 'report its state' entails, but overall it's 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?

  Schema coverage is 100%, so baseline is 3. The description mentions 'force' in context of refusal, but the schema already describes force as 'Attach even if another assistant is live,' so no significant added meaning. Session is not discussed in the description.

  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's action ('Pin the meeting to assist and report its state') with a specific verb and resource, making its purpose obvious. It doesn't explicitly differentiate from sibling tools, but the action of attaching/initializing a session is distinct from the listed 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 explicitly says 'Call once at the start,' providing a clear when-to-use instruction. It also describes the refusal condition and force bypass, but doesn't mention alternatives or when-not-to-use scenarios.

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

• transcriptA
  3.8/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 adds the key behavioral trait that it returns the complete record, not just a recent slice. However, it does not disclose potential limitations like output format, rate limits, or how tail_lines interacts with the 'complete' claim. The disclosure is minimal but non-contradictory.

  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 every phrase earns its place. It succinctly conveys scope and usage without 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?

  The tool is simple, but the description leaves gaps: the session parameter is undocumented, and the relationship between 'complete record' and the tail_lines parameter (which limits to last N lines) is ambiguous. The phrase 'complete meeting record' might mislead an agent into thinking it always returns everything, while tail_lines suggests a limit. Given no output schema and no annotations, the description should clarify these points.

  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 only 50% (tail_lines is described, session is not). The description does not compensate: it never mentions session or tail_lines, leaving the required session parameter unexplained. The meaning of tail_lines as 'last N lines' is provided by the schema, but the description adds no additional semantic value.

  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 reads the complete meeting record, distinguishing it from other tools that provide only partial batches. The verb 'Read' and the resource 'meeting record' are specific, and the contrast with 'batches worth a turn' differentiates it from 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?

  The description explicitly states when to use: 'Use for wrap-up or to reconcile something you missed.' This gives clear usage context. While it does not explicitly name alternative tools, the phrase 'not just the batches worth a turn' implies when not to use it (when only recent context is needed).

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

• snapshot_requestA
  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 burden of behavioral disclosure. It reveals a key behavioral trait: 'Returns immediately,' indicating an asynchronous operation. It also implies the image is not immediately available, which is important context. However, it does not mention potential failure modes, session-specific behavior, or what the immediate return value signifies.

  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, front-loaded sentence that delivers all necessary information without fluff. Every phrase contributes: the action, the immediate return behavior, and the follow-up step. It is concise and well-structured.

  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's simplicity (one optional parameter, no output schema), the description covers the core workflow of capture-then-read. However, it lacks any explanation of the 'session' parameter and does not describe the immediate return value or success/failure signaling. The missing parameter semantics and return info leave gaps for an agent to make correct calls.

  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 one parameter 'session' with zero description coverage. The description does not mention this parameter at all, providing no semantic meaning beyond the type 'string.' An agent has no way to infer what 'session' should contain or how it affects the capture, making this a significant gap.

  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 a specific action: 'capture the shared screen.' It distinguishes itself from the sibling tool snapshot_read by explicitly noting the image must be read later via snapshot_read, making the purpose and relationship unambiguous.

  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 provides explicit usage guidance by stating 'read the image with snapshot_read on a later turn.' This tells the agent exactly when to use this tool (to request capture) and when to use the alternative (to retrieve the image), fulfilling the need for when-to-use vs alternatives.

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

• workingA
  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 behavioral disclosure burden. It explains the heartbeat behavior and how to use status, but does not mention the session parameter or any potential side effects, leaving some gaps.

  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 short, purposeful sentences with no repetition or fluff. The information is front-loaded and every sentence earns its place.

  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 the description covers the heartbeat purpose and usage, but the unexplained 'session' parameter and absence of any mention of return values or additional context make it only partially complete.

  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?

  The schema provides no descriptions for the two parameters (0% coverage). The description explains the 'status' param (e.g., 'checking Jira', empty when done), but completely omits the 'session' param, failing to compensate for the low 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 clearly identifies the tool as a heartbeat mechanism ('so the panel shows you are alive') and its specific action of passing status. This is a specific verb+resource that distinguishes it from siblings like chat_reply or snapshot_read.

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

  Usage Guidelines4/5

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

  It provides explicit usage instructions: pass a status to indicate activity, pass an empty status when done, and call every turn. While it gives clear context and the 'when', it lacks explicit when-not-to-use or alternative recommendations.

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

• wake_modeA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description fully bears the burden. It discloses that gated filters small talk, that the transcript always retains everything, and that 'all' consumes roughly four times the turns—critical behavioral implications.

  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?

  Efficient, front-loaded statement with no filler; each sentence adds distinct value.

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

  Completeness5/5

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

  For a simple two-parameter tool with no output schema, the description provides sufficient context for invocation: semantics of both modes, default behavior, cost, and relationship to transcript. No further detail is needed.

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

  Parameters4/5

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

  The description richly explains the 'mode' enum values ('all' with no gating, 'gated' as default with small talk held back), but does not mention the optional 'session' parameter. Since schema coverage is 0%, the description compensates for the key parameter but leaves session unexplained.

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

  Purpose5/5

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

  The description uses the verb 'Switch' with a clear object ('how much of the meeting reaches you') and explains the two modes ('all' and 'gated') with their intended use cases, distinguishing it from sibling tools like chat_reply or speak.

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

  Usage Guidelines5/5

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

  Explicitly states when to use 'all' (dense calls like interviews/negotiations) and that 'gated' is the default for holding back small talk; also notes the cost difference, giving clear selection criteria.

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