Server Quality Checklist

Tool Scores

• clarity_usa_clienteA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears the full burden. It explains that the token does not pass through the chat and that the server uses a registry token, but lacks details on side effects like overriding previous client settings.

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

  Conciseness5/5

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

  Two concise sentences front-load the purpose and usage context, with every phrase earning its place. No unnecessary detail.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description covers purpose, usage timing, and a security aspect. It is mostly complete, though it could mention error behavior if the client name is invalid.

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

  Parameters3/5

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

  The input schema already fully describes the parameter (name as configured in CLARITY_TOKENS). The description adds minimal extra meaning, just reiterating that only the name is passed and token security. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool sets the active Clarity client by passing only the name, which distinguishes it from sibling tools like 'clarity_clienti' that likely list clients.

  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 says to call this tool before reading data when working on a specific client, providing clear context for when to use it, though it does not name alternatives or when not to use.

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

• query-analytics-dashboardA
  4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint true and destructiveHint false, so safety is clear. The description adds behavioral context about natural language querying and prompting for time ranges, which goes beyond the structured 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 very concise with two focused sentences plus a short note. Information is front-loaded and every sentence adds value without 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?

  Given the tool's simplicity (one parameter, no output schema), the description covers the core behavior and usage guidance adequately. It does not detail return format or error handling, but these are less critical for a natural language query tool.

  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 parameter description in the schema largely mirrors the tool description. The description adds minimal extra meaning beyond what the schema already provides, so it meets but does not exceed the baseline of 3.

  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 fetches Microsoft Clarity analytics data using a natural language query. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like clarity_clienti or list-session-recordings.

  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 to focus on one task, avoid complex multi-purpose queries, and specify time ranges. It also instructs to prompt the user if no time range is provided, indicating appropriate usage context. However, it does not 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.

• query-documentation-resourcesA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about the content returned (snippets, screenshots) but does not disclose additional behavioral traits like pagination, rate limits, or response structure beyond what annotations imply.

  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, well-structured sentence that front-loads the core purpose and immediately follows with usage guidance. Every word earns its place, with no redundancy or unnecessary detail.

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

  Completeness4/5

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

  For a simple, read-only tool with one parameter and no output schema, the description adequately covers purpose, query guidance, and safety. It could optionally mention the expected return format (e.g., text snippets), but given the annotations and simplicity, 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?

  The single parameter 'query' has 100% schema description coverage with a detailed description including examples and guidance for temporal constraints. The description adds value by providing concrete examples and instructing the user to prompt for missing time ranges, exceeding what the schema alone provides.

  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 retrieves Microsoft Clarity documentation snippets for answering user questions, including specific content types like step-by-step screenshots for setup, features, and troubleshooting. It distinguishes well from sibling tools like query-analytics-dashboard and list-session-recordings, which serve different purposes.

  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 some guidance: queries should be focused on one specific topic and avoid complexity. However, it does not explicitly state when to use this tool versus alternatives, nor does it specify prerequisites or cases where the tool is not appropriate.

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

• list-session-recordingsA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context by detailing that it lists recordings based on filters and specifies the required date filter format. No contradiction with annotations. Could mention pagination or rate limits, but the schema covers return structure partially.

  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, concise and front-loaded with the core purpose. No wasted words, and it efficiently communicates the tool's function and key constraint (date format).

  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 complexity (many filters, nested objects) and the absence of an output schema, the description should explain what the listing returns. It does not mention return format or pagination details beyond the count parameter. This gap reduces completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already provides detailed parameter meanings. The description adds minimal extra value beyond a brief overview of filter capabilities. For a tool with such rich schema descriptions, this is adequate but not exceptional.

  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 'List' and the resource 'Microsoft Clarity session recordings', with explicit mention of filtering. The tool name and description distinguish it from sibling tools like 'clarity_clienti' and 'query-analytics-dashboard'.

  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 the tool (to list recordings with filters) and highlights the required date filter format. However, it does not provide explicit guidance on when not to use it or mention alternatives, which would improve score further.

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

• clarity_clientiA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses that only names are returned, the active one is indicated, and no tokens are exposed. For a simple read-only list, this is transparent, though it could mention behavior if no clients configured.

  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 unnecessary words, action verb upfront, and all information is relevant. Highly efficient.

  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 zero parameters and no output schema, the description provides sufficient information: it lists names and active client, with a safety note. It could be slightly more explicit about the output format, but is adequate for a simple tool.

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

  Parameters4/5

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

  The tool has zero parameters, so baseline is 4. No additional parameter information is needed, and the description does not need to compensate for schema gaps.

  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 configured Clarity clients (only names) and indicates which is active, with a safety note about no token exposure. It distinguishes from sibling tools like 'clarity_usa_cliente' (likely for selecting a client) by focusing on listing.

  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 implies use for checking active client and all configured clients, but does not explicitly state when to use versus alternatives like 'clarity_usa_cliente' or when not to use. Context is clear but lacks explicit exclusions.

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