Server Quality Checklist

Tool Scores

• shareA
  3.9/5.0
  Behavior3/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false, consistent with actions that modify shares. Description adds context about token link independence but could elaborate on side effects like immediate propagation or notification on invite.

  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 concise and informative, but the use of abbreviations like '/p' and '/s/<token>' may require prior knowledge. Structure is logical but could benefit from clearer separation of actions.

  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?

  With 6 parameters and 100% schema coverage, the description adequately covers the main use cases. No output schema, but the description hints at return for list action. It is complete enough for an agent to understand the tool's capabilities.

  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%, meaning each parameter already has a schema description. The description adds overall context and action purpose but does not add meaning beyond what the schema already provides for individual parameters.

  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 it's about identity sharing on a pane, enumerates all four actions (list, invite, set_access, revoke), and distinguishes it from sibling tools by mentioning layered on participant tokens and independent token links.

  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 explains when each action is appropriate (e.g., invite for inviting by email, set_access for setting mode, revoke for removing a grant). However, it does not explicitly state when not to use this tool or compare against specific sibling tools.

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

• update_recordA
  3.9/5.0
  Behavior4/5

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

  The description adds context beyond annotations: replaces data, optimistic locking behavior, and return value on mismatch. Annotations already indicate destructive and idempotent traits. No contradictions.

  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 with no wasted words, front-loading the core action and then explaining the locking mechanism concisely.

  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 5-parameter tool with no output schema, the description covers primary behavior, versioning, and return value. It lacks error handling details beyond version mismatch, but is sufficient for most use cases.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining if_match's role in optimistic locking and the replacement behavior of data, providing meaning beyond the schema.

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

  Purpose4/5

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

  The description clearly states the tool updates an existing row in a pane's record collection, using specific verbs and resource. It differentiates from create/delete but does not explicitly contrast with the sibling tool upsert_record.

  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 guidance on using if_match for optimistic locking and retry behavior, but lacks explicit instructions on when to use this tool versus alternative tools like upsert_record or delete_record.

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

• feedbackA
  4.1/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it notes that list returns the agent's own submissions (newest first) and is paginated by 'before'. Annotations include destructiveHint=true, which might be interpreted broadly, but the description does not contradict annotations and provides useful operation-specific details.

  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 efficiently packs details about sub-actions, parameters, and pagination. Every sentence serves a purpose without redundancy.

  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 description lacks explicit return value information for both create and list. For list, it says 'newest first, paginated by before' but does not state the structure of the return payload. For create, no mention of a confirmation or result. Since no output schema is provided, the description should compensate but partially fails to do so.

  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 groups parameters by action (e.g., mentioning that type is required for create) but largely repeats schema descriptions. It adds minimal new meaning beyond the schema, such as clarifying that list pagination uses 'before' from a prior response.

  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 that the tool sends or lists feedback, with a specific action enum distinguishing create and list. It identifies the resource (feedback) and the verbs (send/list), and the detail about categories (bug, feature, note) further clarifies the purpose. No sibling tool duplicates this functionality, so differentiation is not needed.

  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 explains when to use create (for submitting feedback) and list (for viewing own submissions), including pagination details. It does not explicitly state when not to use the tool or provide alternatives, but the context is sufficient for an agent to decide based on the action enum.

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

• template_recordsA
  4.1/5.0
  Behavior4/5

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

  Beyond the destructive hint annotation, the description explains that delete_collection requires a confirm parameter, and notes that the tool is owner-curated. This adds valuable behavioral context not present in annotations.

  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 relatively concise, packing essential information into two sentences. However, the second sentence is lengthy and could be split for better readability. It avoids unnecessary words.

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

  Completeness4/5

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

  Given the complexity of the tool (10 parameters, no output schema), the description provides key context: purpose, distinction from sibling tools, prerequisite, and action set. It could mention return behavior or error conditions, but overall it is sufficient for an experienced user.

  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 the schema fully documents each parameter. The description adds context about the action enum and that the tool has the same grammar as per-pane tools, but does not significantly enhance parameter understanding 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 clearly states that the tool performs CRUD operations on template-level record collections, distinguishing it from per-pane records. It specifies the resource (template-level records) and the action via an enum, providing a precise purpose.

  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 indicates when to use this tool (for template-level records) versus per-pane records, and notes a prerequisite (collection must be declared via the template tool). However, it does not explicitly list when not to use it or provide alternative tools.

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

• get_recordA
  4.3/5.0
  Behavior4/5

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

  Description adds that it 'scans the collection' and specifies the return format ({ record } or isError), going beyond the readOnlyHint annotation. No contradiction.

  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, each serving a purpose: first states the action, second adds behavioral context and return value. No wasted words.

  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 fetch tool with three required parameters, the description covers the return format and scanning behavior. No output schema exists, but the description compensates adequately.

  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 covers all three parameters with descriptions (100% coverage). The description does not add meaningful detail beyond the schema, so baseline score applies.

  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?

  Clearly states 'Fetch a single record row by its key', which distinguishes it from list_records and other siblings. The verb+resource is specific and 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?

  Explicitly says 'fine for a one-off lookup, not a hot loop', providing clear usage constraints. Does not name alternative tools but the guidance is sufficient.

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

• list_panesA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true. Description adds important behavior: participant tokens are not returned and how to obtain them (via participant tool). Also states return shape is { items, next_cursor }. No contradictions.

  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: first states core purpose and ordering, second adds use cases, behavioral note, filters, and return shape. No redundant words, front-loaded with essential info.

  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?

  Covers purpose, ordering, return shape, pagination cursor, security note about secrets, and filter options. For a list tool with well-described schema, this description is complete and self-contained.

  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 provides 100% coverage for all 4 parameters. Description only summarizes filters by status and template_id, adding minimal extra value beyond schema. Baseline score of 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 action ('enumerate') and resource ('panes'), with ordering ('newest first'). It lists specific use cases (find pane_id, audit, get pagination cursor), distinguishing the tool from siblings like get_pane_state (single pane) and create_pane.

  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?

  Describes when to use: to find lost pane IDs, audit open panes, get pagination cursor. Includes a caution about secrets and direction to use the participant tool for tokens. Could be more explicit about not using for single-pane details, but context with siblings makes it clear.

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

• templateA
  4.3/5.0
  Behavior5/5

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

  The description discloses behavioral traits such as the destructive nature of delete (requiring confirm:true) and the concept of versioning, going beyond annotations which only indicate destructiveHint=true.

  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 front-loaded with the core purpose and is structured with a clear action enum. It is slightly verbose but acceptable for the complexity.

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

  Completeness4/5

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

  Given the tool's complexity (21 params, multiple actions, no output schema), the description explains the conceptual model and defers to action parameter for details. It is fairly complete for an AI agent to understand the tool's domain.

  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 the schema already documents each parameter. The description adds overarching context and references the action parameter's documentation but does not add per-parameter meaning 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 clearly states 'Manage reusable, versioned UI templates' and explains the relationship to panes via create_pane's template_id, distinguishing it from pane creation tools. It provides a specific verb and resource.

  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 implicitly guides usage by stating templates are authored once and instantiated via create_pane, but does not explicitly state when not to use this tool. It leverages sibling context.

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

• delete_recordA
  4.4/5.0
  Behavior4/5

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

  Beyond annotations (destructiveHint=true), describes soft-delete behavior, tombstone in list_records, and return value. No major 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?

  Two efficient sentences, front-loaded with key action, no redundancy.

  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?

  Covers return value and behavioral aspects adequately for a simple delete tool; no output schema 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?

  Schema coverage is 100%, baseline 3. Description adds meaning to if_match parameter ('optimistic-locked delete'), enhancing clarity.

  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?

  Clearly states 'Soft-delete a row from a pane's record collection' with specific verb and resource, distinguishes from sibling tools like delete_pane and delete_record_collection.

  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?

  Provides guidance on when to use if_match for optimistic locking, but does not explicitly state when not to use this tool or compare to alternatives like update_record.

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

• attachmentsA
  4.5/5.0
  Behavior4/5

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

  The description discloses behaviors such as absolute paths for upload/download, base64 fallback, soft-delete, and token self-deletion on first GET. Annotations indicate destructiveHint=true, which aligns with delete actions. No contradictions.

  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 paragraph that efficiently packs details without fluff. It front-loads the core purpose and action list. Could be broken into bullet points but is still concise.

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

  Completeness5/5

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

  Given 14 parameters, conditional requirements, and no output schema, the description covers all actions, parameter roles, and return behavior (base64 for download, token for mint_token). It is thorough.

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

  Parameters5/5

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

  Schema coverage is 100%, and the description adds meaningful context for each action and parameter (e.g., scope defaults to agent, token behavior). It significantly enhances understanding 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 clearly identifies the tool as managing binary attachments (images, PDFs, etc.) referenced from event payloads, and lists all actions. It is distinctive from sibling tools which focus on different entities like panes, records, or events.

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

  Usage Guidelines4/5

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

  The description specifies when to use the tool (for binary attachment operations) and explains each action's context. It lacks explicit comparisons to alternatives but the purpose is narrow enough that usage is clear.

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

• get_pane_stateA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value by specifying exact metadata fields and explicitly stating that the event log is excluded, which is not in 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?

  Two sentences, no redundancy. Front-loaded with purpose and immediately provides usage context. Every sentence earns its place.

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

  Completeness5/5

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

  Given the tool's simplicity (one parameter, no output schema, clear annotations), the description adequately covers purpose, usage, return content, and exclusions. No gaps.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema description fully documents the single parameter 'pane_id'. The description does not add extra semantic info beyond the schema, 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 verb 'Fetch', the resource 'pane's current metadata', and specifies the items included (status, title, template version, timestamps, expires_at). It distinguishes from the sibling tool 'get_events' by noting the exclusion of the event log.

  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: 'to check whether a pane is still open or has expired', and when not to use: 'To read what the human did, use get_events'. Provides a clear alternative.

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

• get_skillA
  4.5/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint true, and the description adds that the tool is unauthenticated, which is valuable context beyond the annotations. It also explains the behavior difference when version_only is passed.

  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 most important information. Every sentence provides distinct value with no redundancy.

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

  Completeness5/5

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

  For a simple read-only tool with one optional parameter and no output schema, the description covers what it returns and when to use it comprehensively.

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

  Parameters4/5

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

  Schema coverage is 100%, and the description adds practical context for the version_only parameter, explaining its use case (checking if a cached copy is stale), which goes beyond the schema description.

  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 it fetches the SKILL.md guide, is unauthenticated, and is intended for self-teaching before using other tools. It distinguishes itself from siblings by explaining its role as a learning resource.

  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 advises calling this tool to learn the workflow before driving other tools, and provides specific guidance for the version_only parameter to check cache staleness. It does not explicitly mention when not to use it, 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.

• list_recordsA
  4.5/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint=true. The description adds return value details (records, next_since, has_more), explains include_tombstones for deletions, and clarifies polling behavior. 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.

  Conciseness4/5

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

  The description is concise, front-loaded with main purpose, and efficiently adds polling and return info. No unnecessary sentences, though could be slightly more structured.

  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 5 parameters and no output schema, the description adequately covers return format, polling, and deletions. It is complete enough for an agent to use the tool correctly, though examples or edge cases could enhance.

  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 covers all 5 parameters with descriptions (100% coverage). The description adds context for the 'since' parameter as a polling handle and for 'include_tombstones' as surfacing deletions, adding value beyond 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 lists rows in a pane's mutable record collection. It differentiates from sibling tools like get_record by focusing on listing all records, and adds the polling/watch aspect.

  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 guidance on when to use records (when page shows mutable items and current state matters) and how to poll via the since parameter. It implicitly excludes uses where history matters more, but does not explicitly contrast with alternatives like get_record.

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

• trashA
  4.5/5.0
  Behavior5/5

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

  Annotations already mark destructiveHint=true, and the description adds critical nuance: 'purge bypasses the retention window and is permanent' and explains the lifecycle (soft-deleted rows live in trash until sweeper reclaims them). 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?

  Description is four sentences, front-loaded with purpose, and every sentence adds unique value: overall function, action enum breakdown, special behavior of purge, and lifecycle note. No wasted words.

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

  Completeness4/5

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

  Given the tool's complexity (5 actions, 2 params, no output schema), the description covers actions and id semantics well. However, it lacks explanation of what the 'list' action returns (e.g., format or structure), which would be helpful for an agent. Minor gap.

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

  Parameters5/5

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

  Schema coverage is 100%, giving a baseline of 3. The description adds significant meaning by explaining the action enum values in context (e.g., 'restore: un-trash a pane (id)') and clarifying that id is used specifically with restore/purge for panes or templates. This goes beyond the schema descriptions.

  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?

  Description clearly states 'Manage soft-deleted panes + templates' with a specific verb and resource. It distinguishes itself from sibling tools by being the single entry point for all trash operations via an action enum, unlike other tools like delete_pane which likely handle direct deletion.

  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?

  Description implies usage context by listing actions and noting purge is permanent, but does not explicitly state when to use this tool over alternatives like delete_pane or other sibling tools. No direct comparison or when-not guidance is provided.

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

• agentA
  4.6/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond annotations: it specifies that whoami involves no network or secrets, claim is one-way binding, and logout does not revoke on relay. This aligns with the destructiveHint annotation and provides clear safety information.

  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 concise and front-loaded with 'Agent identity + binding.' It uses a bullet-like structure with pipes for readability. While packed with information, it could be slightly more streamlined, but it remains clear and efficient.

  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 complexity of three actions and no output schema, the description lacks details about return values or expected outcomes (e.g., what whoami returns in detail). It provides enough context for usage but not full completeness for an agent to understand all outputs.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description enhances parameter semantics by explaining when the 'code' parameter is required (for claim) and by expanding on the meaning of each action enum value. This adds value beyond the schema descriptions.

  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 managing agent identity and binding with three distinct actions (whoami, claim, logout). Each action's purpose is specifically described, and it distinguishes from the sibling 'key' tool by noting that logout does not revoke on relay.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool (for agent identity management) and provides guidance for each action, including when not to use logout (revoke via key tool). It also clarifies that claim is one-way and requires a code from Settings UI.

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

• participantA
  4.6/5.0
  Behavior5/5

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

  The description adds significant behavioral details beyond annotations: the plaintext token is returned once and must be saved, tokens are hashed and unrecoverable, and the tool is used for leak containment. This aligns with the destructiveHint annotation without contradiction.

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

  Conciseness5/5

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

  The description is three sentences, front-loads the purpose, and provides essential behavioral context without any redundancy or fluff. Every sentence 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?

  Given no output schema, the description could be more complete about return values for list and revoke. However, it adequately covers the three actions and their critical behavioral nuance (token returned once). Missing output details slightly reduce completeness.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the enum actions' meanings (list for finding ID, new for minting with token warning, revoke for invalidation). However, pane_id and participant_id descriptions are not enhanced beyond 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 it manages a pane's participant URLs for recovery and leak-containment. It distinguishes three actions via an enum (list, new, revoke) with specific purposes. No sibling tool serves this exact function, making it uniquely identifiable.

  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 explicit guidance for each action, such as using 'new' when the original URL is lost. It implies usage contexts (e.g., 'list' to find participant_id) but does not explicitly state when not to use the tool or compare to alternative tools.

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

• run_queryA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds important behavioral details: scoping to user's data, 10,000 row cap, 10-second timeout, and output format details. This goes beyond 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 concise (three sentences) and front-loaded with the key verb 'Run read-only SQL'. Every sentence adds essential information with no redundancy.

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

  Completeness5/5

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

  Given the tool's complexity (SQL query with multiple options), the description fully covers purpose, parameters, limits, scoping, and output format. With complete schema coverage and annotations, no gaps remain.

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

  Parameters5/5

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

  Despite 100% schema coverage, the description adds significant value for each parameter: sql parameter lists available tables and columns, explains JSON operators; format parameter describes output behavior; pane_id explains conflict resolution. All three are well explained.

  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 it runs read-only SQL over scoped data, with explicit use cases (summarise activity, find panes/records, build a report). It distinguishes itself from sibling tools as the only SQL query tool.

  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 clear context on when to use (summarising, finding, reporting) and implies read-only nature. However, it does not explicitly state when not to use or point to alternatives, though no alternatives exist among siblings.

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

• send_to_paneA
  4.6/5.0
  Behavior4/5

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

  Adds context beyond annotations: explains it updates live UI, requires event type constraints, and mentions return value { event, deduped }. Idempotency_key dedup behavior is noted. No contradiction with annotations (readOnlyHint=false, destructiveHint=true).

  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 sentences, each essential: first states action, second gives constraint, third provides usage guidance and return format. No wasted words.

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

  Completeness4/5

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

  Covers main behavior, constraints, dedup, and return. For a tool with 4 params and no output schema, this is sufficient. Could mention error cases but not necessary for typical use.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. Description adds meaning: explains data as payload valid against schema, idempotency_key for dedup, and type must match pane's event_schema. This adds value beyond schema descriptions.

  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 specific verb ('push an event INTO') and resource ('open pane'), clearly stating it updates live UI. It distinguishes from sibling tools by mentioning preference for record tools on mutable collections.

  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 (push events into pane for live UI updates) and when not (prefer record tools for mutable collections). Also provides constraint on event type: must be declared in pane's event_schema with 'agent' in emittedBy.

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

• tasteA
  4.6/5.0
  Behavior5/5

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

  The description provides detailed behavioral context: it is a read/write/clear tool, `set` replaces the entire document, and entries should be UI-only. The annotations only indicate destructiveHint=true, so the description adds significant value beyond the structured data.

  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 concise (two sentences plus a short instruction) and front-loaded with the purpose. Every sentence adds necessary information without redundancy or waste.

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

  Completeness4/5

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

  Given the absence of an output schema, the description covers the behavior of all actions (get, set, clear) and provides usage guidance. It could have explicitly stated that `get` returns the markdown string, but the context implies it. Overall, it is sufficiently complete.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that `taste` is required for `set` and that `set` does a whole-document replace, which goes beyond the schema's property descriptions.

  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 'Read / write / clear the agent's freeform UI taste notes', specifying the verb and resource. It distinguishes from siblings by focusing on UI/presentation preferences only, and the action enum (get/set/clear) further clarifies the scope.

  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 instructs to 'Call `get` BEFORE generating a pane' and explains that `set` does whole-document replace, not append. It also advises to 'Keep entries about UI/presentation only.' However, it does not explicitly mention when to use this tool versus alternative tools like 'feedback'.

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

• delete_paneA
  4.7/5.0
  Behavior4/5

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

  Annotations already cover idempotent and destructive behaviors. Description adds valuable context: 'The human's URL stops working.' Extends transparency beyond 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?

  Two sentences, no wasted words. Every sentence adds unique information: idempotency, URL effect, and sibling tool guidance.

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

  Completeness5/5

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

  Given single param, annotations, and no output schema, description fully covers behavior, consequences, and related tools. No gaps.

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

  Parameters4/5

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

  Schema covers 100% of parameters. Description adds idempotent context for pane_id, clarifying that it's safe to resend. Adds value beyond 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?

  Clearly states the action (close/delete) and resource (pane). Distinguishes from siblings like update_pane and trash, ensuring no ambiguity.

  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 provides when-to-use and alternatives: edit uses update_pane, recovery uses trash. No ambiguity about appropriate context.

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

• delete_record_collectionA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false; description adds owner-only constraint, confirm:true requirement, and return format { deleted: true, collection }, providing full behavioral context beyond 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?

  Four sentences, front-loaded with the core action, followed by usage guidance, behavioral notes, and return format. No wasted words.

  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 tool with 3 required parameters, no output schema, and clear annotations, the description covers purpose, usage, constraints, and return value, leaving no ambiguity for an agent.

  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%, and the description does not add new parameter-level detail beyond what the schema already provides, but it reinforces the confirm parameter's role in the context of the tool's destructive nature.

  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?

  Clearly states the verb (drop/delete) and resource (whole per-pane record collection), and explicitly distinguishes from sibling 'delete_record' by noting it removes the entire collection at once rather than rows one by one.

  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 (reset/remove a collection) and when not to (instead of delete_record), provides rename workaround, and notes owner-only and confirm requirement.

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

• keyA
  4.7/5.0
  Behavior5/5

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

  Description discloses all behavioral traits: destructive hint is confirmed with 'self-destruct' and 'irreversible'; scoping to caller is added context not in annotations. 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?

  Two sentences, front-loaded with purpose, and includes essential details without extraneous text. Efficient and clear.

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

  Completeness5/5

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

  Given no output schema, description adequately covers return info for list and effect of revoke. Completeness is high for a simple 2-parameter 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?

  Schema coverage is 100%, so baseline is 3. Description adds value by explaining the conditional requirement of 'confirm' for revoke and listing the output of 'list', going beyond schema descriptions.

  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?

  Description explicitly states 'Inspect or revoke the calling agent's API key' with specific actions (list and revoke). Clearly distinguishes from sibling tools which do not involve key management.

  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?

  Provides context for when to use each action, including that revoke is irreversible and requires confirm:true. Lacks explicit mention of when not to use, but given no direct sibling overlap, the guidance is sufficient.

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

• upsert_recordA
  4.7/5.0
  Behavior5/5

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

  Beyond annotations (idempotent, destructive), the description reveals the deduped return flag, the prerequisite of collection write permission, and the exact return shape { record, deduped }. No contradictions 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?

  Four sentences with no superfluous words. First sentence states core behavior, second lists use cases, third gives prerequisite call, fourth specifies return value. Front-loaded and efficient.

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

  Completeness5/5

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

  Given no output schema, the description fully covers input requirements, dedup logic, preconditions (get_skill, collection write permission), and return shape. Siblings are many, but the description sufficiently differentiates the upsert behavior.

  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 covers all parameters (100% coverage), so baseline is 3. The description adds value by explaining record_key's deduplication role and the data parameter as 'record body', providing context not explicit in schema descriptions.

  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 defines the tool as an upsert operation: create a row or return existing if record_key is present (deduped:true). This distinguishes it from sibling tools like create_record (plain insert) and delete_record (removal).

  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 advises when to use (add a todo, line item, comment) and when not to (if still designing, call get_skill first for records-vs-events decisions). It could explicitly contrast with create_record or delete_record, but the guidance is clear and helpful.

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

• create_paneA
  4.8/5.0
  Behavior4/5

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

  The description discloses key behaviors: it creates a pane (destructive), returns a URL, expires after a time, and can be idempotent with context_key. It does not contradict the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false). However, it does not mention rate limits or cost, missing a bit of transparency. Overall, it adds substantial context beyond the 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 appropriately detailed without being verbose. It starts with the core purpose and an actionable instruction ('ALWAYS give the returned url to the human'), then logically flows through usage, prerequisites, and technical details. Every sentence serves a purpose, making it efficient and well-structured.

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

  Completeness5/5

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

  Given the tool's high complexity (18 parameters, no output schema), the description is remarkably complete. It explains the return object shape, pre-requisites (get_skill, taste), edge cases (idempotency, event schema for read-only), and how it relates to sibling tools. No essential information is missing.

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

  Parameters5/5

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

  Schema coverage is 100%, so baseline is 3. However, the description adds extensive context for each parameter: mutual exclusivity of html/template_id, required name when html provided, reserved tags, callback opt-in, seed data usage, and more. This goes well beyond the schema definitions, earning top marks.

  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 creates a rich interactive UI by URL, with options for inline HTML or saved template. It distinguishes from siblings by listing specific use cases and instructing the agent to always return the URL to the human. The description also references related tools like get_events, making its role clear.

  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 guidance on when to use this tool ('Reach for this whenever a text reply is the wrong shape'), lists many use cases, and advises when not to use it by mentioning alternatives (poll events with get_events or use record tools). It also instructs to call get_skill and taste before authoring, which is valuable context.

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

• get_eventsA
  4.8/5.0
  Behavior5/5

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

  Discloses append-only nature, polling behavior, absence of push/streaming, long-poll mechanism with wait_seconds, and response format { events, next_cursor }. No contradiction with annotations (readOnlyHint: true, openWorldHint: false).

  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?

  Description is moderately sized and well-structured, with each sentence providing essential guidance. Slightly verbose but every part adds value. Could be tightened slightly.

  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 complexity (polling loop, cursor, long-poll) and lack of output schema, description covers core usage, response structure, and intent well. Minor gaps: no error handling or rate limits, but still highly complete.

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

  Parameters5/5

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

  Schema coverage is 100% with parameter descriptions, but the description adds crucial context: explains 'since' as a cursor from previous call, 'wait_seconds' for waiting on human action, and the overall polling pattern that ties parameters together.

  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?

  Clearly states the tool polls a pane's append-only event log for human actions like form submissions, approvals, and picks. Distinguishes from sibling tool 'get_pane_state' which deals with state, not events.

  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 describes the poll loop with and without 'since' parameter, and how to use 'wait_seconds' for long-polling. Also notes there is no push/streaming in MCP, so this is the only way to get round-trip results.

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

• upgrade_paneA
  4.8/5.0
  Behavior5/5

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

  Discloses key behaviors: schema-compatibility gate with optional force override, return value structure, and the relay appending a version. Consistent with annotations (destructiveHint=true) and adds significant context beyond them.

  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?

  Well-structured and front-loaded, with clear separation of usage modes. Each sentence adds value, though slightly verbose in places. Efficient for the complexity of the tool.

  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?

  Comprehensive for a tool with 9 parameters, no output schema, and nested objects. Covers return value, error case (schema_incompatible_upgrade), and force option. No missing critical information.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context for multiple parameters (e.g., html inline edit behavior, schema inheritance, mutual exclusivity, force override). Enhances understanding beyond schema names alone.

  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?

  Clearly states the tool re-pins a LIVE pane to swap HTML and schemas in place. Specifically distinguishes two usage modes and contrasts with sibling tools like create_pane and template.

  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 describes two ways to use the tool (html for inline edit, template_version for reusable templates) with mutual exclusivity. Provides clear guidance on when to use each and when not to, mentioning that named/reusable templates must go through the template tool.

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

• update_paneA
  5/5.0
  Behavior5/5

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

  Annotations provide destructiveHint and idempotentHint; description adds concrete behavior: pane keeps id, URL, event log, template pin; returns full state + updated_fields array, with no contradictions.

  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?

  Description is concise and front-loaded: core action first, then settable fields with constraints, return info, and alternative tool – every sentence adds 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?

  Given no output schema, description mentions return format; covers all constraints (mutual exclusions, at least one field) and provides clear instructions, fully compensating for structured gaps.

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

  Parameters5/5

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

  100% schema coverage is already strong; description adds mutual exclusion (ttl_seconds vs expires_at), explains input_data revalidation, and clarifies clear_* fields for dropping overrides, exceeding baseline.

  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?

  Description clearly states it edits a live pane in place via PATCH, listing specific fields that can be set, and explicitly distinguishes from upgrade_pane for swapping HTML/schemas.

  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 tells when to use this tool (edit instance-level fields) and when to use upgrade_pane instead (for swapping HTML/schemas), plus instructs to pass at least one field.

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