Server Quality Checklist

Tool Scores

• kpi_chapterC
  2.6/5.0
  Behavior2/5

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

  No annotations provided, and description only mentions output type without details on computation, data source, latency, or side effects. For a tool with no annotations, this is insufficient.

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

  Conciseness3/5

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

  Single sentence is concise, but lacks structure and omits important details. Not every sentence earns its place because there is only one that does not cover all necessary aspects.

  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?

  Given 12 sibling tools and no output schema, the description is too sparse. It does not explain what aggregate or per-member breakdown means, nor provide any context for output. Users are left guessing.

  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 50%; quarter parameter has a format description, but chapter parameter only has enum. Description adds no extra meaning beyond the enum values, failing to compensate for low coverage.

  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?

  Description clearly states it provides chapter aggregate and per-member metric breakdown, with explicit enum values. However, it does not distinguish from sibling tools like kpi_overview or kpi_chapter_monthly.

  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 on when to use this tool versus alternatives such as kpi_overview or kpi_member_kpi. Missing context about preferred scenarios.

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

• kpi_alertsC
  2.9/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full burden. It states that alerts are 'derived' and lists types, but does not disclose if this is a read-only operation, any authentication needs, or what happens if quarter is omitted (though the input schema notes a default).

  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, concise sentence that front-loades key information (quarter scope) and lists alert examples. It is efficient with no 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?

  Given the tool has only one optional parameter and no output schema, the description adequately conveys the kind of alerts returned. However, it does not describe the structure or meaning of the return value, leaving some ambiguity.

  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 covers 100% of the parameters, including a description for 'quarter' that states defaults to current. The tool description adds no further semantic detail beyond naming the parameter.

  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 specifies the resource (alert signals for a quarter) and gives concrete examples (squad below revenue floor, bonus cap, sync staleness). It effectively distinguishes from sibling tools like kpi_health or kpi_overview, though it lacks an explicit verb (e.g., 'list' or 'get').

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives (e.g., other kpi tools). There is no mention of prerequisites, exclusions, or typical scenarios.

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

• kpi_scoring_coverageC
  2.9/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 carry the full behavioral burden. It states the output is a list of members lacking data, but does not disclose whether it is read-only, destructive, or any side effects. The phrase 'before lock' hints at a deadline but lacks specificity.

  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 concise sentence, directly conveying the core purpose. It is front-loaded and efficient, though slightly informal (e.g., 'so a Lead can be reminded'). No unnecessary 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?

  Given the tool has no output schema and simple parameters (month, chapter), the description is mostly adequate but lacks details on the output format (e.g., member identifiers, counts). It does not specify pagination or limits. Sibling tools like kpi_members suggest similar focus, so completeness is moderate.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for 'month' and 'chapter' (including enum values). The tool description adds context about 'remind a Lead' but does not enhance parameter semantics beyond the schema. Baseline 3 applies.

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

  Purpose4/5

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

  The description clearly indicates the tool identifies active members lacking scoring data for the month, hinting at a reminder function. It differentiates from sibling tools like kpi_members or kpi_alerts by specifying 'coverage' and 'before lock', but could be more explicit.

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

  Usage Guidelines2/5

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

  The description implies usage for checking coverage before a deadline, but provides no explicit guidance on when to use this tool versus alternatives. No mention of when not to use or recommended contexts.

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

• kpi_member_kpiA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden. It clearly states the tool returns a breakdown for a quarter, which implies a read-only query. However, it does not disclose potential restrictions (e.g., whether the user must be the member, data freshness, or any side effects). Additional context about auth or data recency would improve transparency.

  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?

  One concise sentence that immediately conveys the tool's function and output components. No wasted words, and the most critical information (what the tool returns) is front-loaded.

  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 outputs a detailed breakdown, the absence of an output schema is compensated by listing the exact components in the description. For a simple query tool with only two parameters, this is sufficient for an agent to understand what it will receive.

  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 input schema already describes both parameters ('Member UUID' and 'Quarter'). The description adds only the default behavior for quarter ('defaults to current'), which is a minor but useful addition. No further enrichment needed.

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

  Purpose5/5

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

  The description states exactly what the tool returns: 'Full KPI breakdown for a member (engine1 commission, engine2 squad-bonus, clawback, total payout) for a quarter.' The verb 'Full KPI breakdown' combined with the specifics clearly distinguishes it from siblings like kpi_overview (which likely provides summary stats) and kpi_members (which likely lists members).

  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 on when to use this tool vs alternatives. The description only explains what it does, not when to choose it over siblings like kpi_alerts, kpi_chapter, or kpi_members. Without context for decision-making, an agent may misuse it.

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

• kpi_membersA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior. It states it returns an active roster with specific fields, implying a read-only list operation. However, it does not mention pagination, limits, sorting, or side effects. The description is adequate but minimal.

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

  Conciseness4/5

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

  The description is two sentences with key information front-loaded. It is concise and efficient, though it could be slightly more structured. No 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?

  For a simple list tool with two optional parameters and no output schema, the description covers what the tool returns and its filtering capability. It is sufficient for an agent to understand and invoke the tool correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must add meaning. It merely restates that chapter and squadId are optional filters, without explaining their format, behavior, or interaction. The enum values for chapter are already visible in 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 the tool returns an active roster of members and leads with specific fields (id, name, email, role, chapter, squad), and its purpose is to know whom to message. It distinguishes from siblings like kpi_member_kpi which probably focuses on individual KPIs.

  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 mentions optional filters and the context of messaging, but it does not explicitly state when to use this tool versus alternatives like kpi_alerts or kpi_health. No guidance on when not to use it is provided.

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

• kpi_rubricsA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the transparency burden. It describes the returned data (metric keys, thresholds, etc.) but does not disclose potential side effects, required permissions, or whether the operation is read-only. It is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the tool's return value and scope, followed by usage guidance. Every word is necessary, with no redundancy or filler.

  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 has 2 optional parameters, no output schema, and many siblings, the description covers the return structure and usage context well. It lacks explicit defaults for chapter and could be more specific about what 'current' quarter means, but overall it is adequate.

  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 schema already covers 100% of parameters with descriptions (chapter enum, quarter format/default). The description restates the scope but adds no new semantic details beyond what the schema provides.

  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 rubric thresholds and criteria for a chapter in a quarter, specifying the returned fields (metric keys, thresholds, multipliers, data sources). It also provides a usage context (before generating reports), which helps differentiate it from other tools, though it does not explicitly name alternatives.

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

  Usage Guidelines3/5

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

  The description gives a clear usage context ('Use to understand scoring rules before generating reports') but lacks explicit guidance on when not to use this tool or how it compares to siblings like kpi_chapter or kpi_member_kpi.

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

• kpi_chapter_monthlyA
  3.8/5.0
  Behavior3/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 discloses that SALES returns GTV, deal count, and customer count per person, while other chapters return revenue squad and metrics. However, it lacks detail on potential side effects, required permissions, or output structure.

  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 sentences that front-load the core purpose and provide a concrete example. Every sentence adds value without 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?

  Given no output schema or annotations, the description provides partial information about return values but lacks full structure (e.g., array vs. object, field names for 'metrics'). It is adequate for a simple query tool but could be more detailed.

  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 adds meaning beyond the schema by explaining how the chapter parameter affects output (SALES vs. other chapters). The month parameter is already described in the schema with format. Schema coverage is 50%, and the description compensates for the undocumented chapter enum values.

  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 chapter data per month, with specific behavior for SALES and other chapters. It provides an example use case but does not explicitly differentiate from sibling tools like kpi_chapter.

  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 a clear usage scenario (e.g., 'when you want to see how much Sales achieved in May'), guiding when to use this tool. However, it does not explicitly mention when not to use it or name alternatives.

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

• kpi_docs_listA
  3.8/5.0
  Behavior3/5

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

  No annotations provided; description only states the action and return value, omitting any side effects, permissions, or error handling.

  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 with no filler; each sentence adds value.

  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 parameterless tool, it covers purpose and return value adequately, though missing edge case details like empty directory.

  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?

  No parameters; description adds context by specifying the directory and purpose, going beyond the empty 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?

  Specifically states it lists document files in the mcp/docs/ directory and returns filenames, clearly distinguishing it from sibling KPI metric tools.

  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 on when to use this tool versus alternatives like kpi_rubric_doc, nor any exclusion criteria or prerequisites.

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

• kpi_overviewA
  3.8/5.0
  Behavior2/5

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

  No annotations provided, so description must disclose behavioral traits. It implies a read operation but does not explicitly state read-only, permissions, rate limits, or side effects. It lacks transparency about what the tool does beyond returning 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?

  Two concise sentences: the first summarizes contents, the second gives usage context. No redundant information, perfectly front-loaded.

  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 1-parameter tool with no output schema, the description adequately conveys the scope and use case. It doesn't cover error behavior or output format, but these are less critical for an overview 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% with a clear description of the quarter parameter. The description does not add any extra meaning beyond the schema, which meets the baseline expectation.

  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 specifies a specific verb+resource (overview of KPIs) and lists contents: per-squad performance, sales leaderboard, etc. It distinguishes from siblings by stating 'company-wide overview' and targets a specific audience (CEO/Finance).

  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?

  Clearly states when to use: 'Use for CEO/Finance digests.' However, it does not explicitly exclude alternatives or mention when not to use, given many sibling tools exist.

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

• kpi_scoring_periodA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the return type (state enum) and purpose, but lacks details on idempotency, side effects, or performance. Adequate for a simple read-like operation.

  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?

  Two sentences: one for purpose and one for usage. No unnecessary information, but could be slightly more structured. Still very concise and to the point.

  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 single-parameter tool with no output schema, the description covers the essential behavioral and usage aspects. It is sufficient for an agent to select and invoke correctly.

  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% with a clear description of the 'month' parameter format. The description adds usage context but no additional parameter semantics beyond what the schema 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 the tool retrieves the scoring-period state (OPEN or LOCKED) for a given month. It differentiates from sibling tools which focus on alerts, chapters, members, etc., making the purpose 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 explicitly tells when to use the tool: 'Use before nudging Leads or reading final numbers.' This gives clear context for invocation, though it lacks explicit exclusions or alternative names.

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

• kpi_sla_statusA
  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 must fully disclose behavior. It indicates the tool shows progress and identifies overdue leads, and mentions reminding or marking violations, implying possible write operations. However, it does not clarify if the tool is read-only or has side effects, leaving ambiguity.

  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 sentence in Vietnamese, yet it effectively communicates the tool's purpose and usage. It is concise and front-loaded without 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?

  The tool has only one parameter and its purpose is well explained. While there is no output schema, the description sufficiently covers the tool's functionality for its simple use case. However, a brief mention of the output format would enhance 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%, providing a baseline of 3. The description adds context that the month parameter is for the scoring period, but does not provide additional details beyond the schema's own 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 the tool's function: showing scoring progress of Leads by month, identifying who has finished and who is overdue. It also specifies usage for reminding Leads before a deadline or marking violations, which distinguishes it from sibling tools focusing on other KPI aspects.

  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 usage contexts: reminding Leads before the deadline (with exact date and time) or marking deadline violations. It does not explicitly state when not to use it, but the context is clear and differentiates from other KPI tools.

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

• kpi_rubric_docA
  4.1/5.0
  Behavior3/5

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

  No annotations provided, so description must cover behavioral aspects. It describes the return content but does not explicitly state that it is a read-only operation or mention any side effects, permissions, or limitations.

  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 two sentences, front-loaded with purpose, and every sentence adds value. No redundant information.

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

  Completeness5/5

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

  For a simple tool with one parameter and no output schema, the description adequately explains what the tool returns, its content, and usage context. No gaps given the tool's simplicity.

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

  Parameters3/5

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

  Schema coverage is 100% with one parameter (chapter) having an enum and description 'Chapter name'. The description repeats the enum values but adds no additional semantic 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?

  Description clearly states it returns a full rubric document in markdown for a chapter, listing contents (scoring criteria, thresholds, behavioral descriptions, data sources) and available chapters. Differentiates from siblings by specifying it's for a single chapter's detailed rubric.

  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 states when to use the tool ('when asked about rubric chapter X' or 'to understand how KPIs are scored'). Lists available chapters but does not explicitly exclude other uses or compare to sibling tools.

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

• kpi_healthA
  4.3/5.0
  Behavior4/5

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

  Without annotations, the description carries the burden. It clearly indicates the tool is a non-destructive probe that confirms token and dashboard state. However, it omits details like error behavior if the token fails.

  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?

  A single, direct sentence with no wasted words. The description is efficiently front-loaded and appropriate for the tool's simplicity.

  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 zero parameters and no output schema, the description fully captures the tool's purpose: a health check for token and dashboard. It is complete for its scope.

  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?

  No parameters exist, so the schema covers 100%. The description adds value by explaining the purpose beyond the schema, earning a baseline of 4.

  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 is a health/identity probe that confirms token validity and dashboard reachability. It uses specific verbs and identifies the resource, distinguishing it from sibling KPI tools.

  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 implies the tool is for checking connectivity and authentication but does not explicitly state when to use it versus alternatives like kpi_alerts. No guidance on when not to use it.

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