Server Quality Checklist

Tool Scores

• community_pool_calculatorA
  3.7/5.0
  Behavior4/5

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

  The description declares it as a 'DEMO educational tool — not a licensed insurance product,' which goes beyond the readOnlyHint annotation to warn about non-production use. It also provides parallel examples, adding context about its educational nature.

  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 one sentence of core purpose, followed by two sentences of useful context and a warning. It is front-loaded and efficient, though the parallel examples could be trimmed without losing key information.

  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 description covers the tool's purpose, educational nature, and regulatory context. With an output schema available, it does not need to detail return values. It is sufficiently complete for a calculation tool with well-documented parameters.

  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 provides 100% coverage with descriptions for all three parameters. The description adds no new meaning beyond the schema, so it scores the baseline of 3.

  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 'Calculate parameters for a community group (chama) pooled insurance arrangement.' It uses a specific verb and resource, and the mention of Western and Kenya parallels helps distinguish it from sibling tools like premium_estimate or compare_microinsurance, which focus on different aspects.

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

  Usage Guidelines2/5

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

  The description provides cultural context but no explicit guidance on when to use this tool versus its siblings. It does not specify scenarios where other tools are more appropriate or caution against misuse.

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

• kenya_insurance_productsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds important context that the data is DEMO synthetic and not real, which is beyond what annotations provide.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main action, and contains no unnecessary words. Every sentence serves a purpose.

  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 simple schema, output schema existence, and one parameter, the description covers the core purpose and data nature. It is complete enough for this straightforward 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%, so the parameter description is already fully defined in the schema. The tool's description adds no additional meaning or usage context for the filter options.

  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 'Kenya insurance product categories and representative products', which is specific and distinguishes it from sibling tools like compare_microinsurance or premium_estimate that perform different actions.

  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 for educational/research purposes by noting it returns synthetic data, but lacks explicit guidance on when to use this tool against siblings or 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.

• premium_estimateA
  4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true. Description adds that it is a 'demo estimation — not a binding quote', clarifying the non-binding nature. 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?

  The description is concise (4 sentences) with no fluff. It front-loads the core purpose, then adds coverage scope, a parallel for context, and a critical caveat. Every 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?

  Given the presence of an output schema (not shown) and full schema parameter coverage, the description adequately covers the tool's purpose, scope, and limitations. It could mention the fallback defaults (e.g., county) but the schema already handles that.

  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 itself explains all parameters. The description does not add new meaning beyond what the schema provides; it only reasserts the scope of insurance types.

  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 'Estimate monthly insurance premium for a Kenya individual', specifying verb (estimate) and resource (insurance premium). It lists covered insurance types (health, life, crop, device) and distinguishes itself from siblings via the 'Western parallel' and 'demo estimation' note.

  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 usage for demo estimation and lists covered types, but lacks explicit guidance on when not to use or how it compares with sibling tools. No direct mention of alternatives or exclusions.

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

• nhif_coverage_queryA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, description adds behavioral context: data is demo, verification required at nhif.or.ke. No contradiction, valuable beyond annotation.

  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 purpose, second adds analogies and data warning. No wasted words, 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?

  Simple tool with two parameters, output schema present, annotations declare read-only. Description adds demo data context. Complete for this complexity level.

  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 parameter descriptions. Description mentions 'by hospital tier and procedure' but does not add significant new meaning beyond schema. Baseline 3 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?

  Clear verb 'Query', resource 'NHIF coverage details', and scope 'by hospital tier and procedure'. Additional context about NHIF as state insurer and demo data distinguishes from siblings.

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

  Usage Guidelines3/5

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

  Description indicates when to use (query coverage), but lacks explicit exclusions or alternatives to sibling tools. The demo data warning implies caution but is not a strong usage guideline.

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

• compare_microinsuranceA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the description adds value by warning that data is DEMO and advising verification at ira.go.ke, which informs the agent about data reliability beyond the annotation's safety flag.

  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 concise sentences, front-loaded with the core purpose, followed by helpful context. No redundant words, 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 the tool has 2 parameters, full schema coverage, and an output schema, the description adequately covers purpose, target audience, and data source. It is fairly complete, though could briefly mention how to interpret results.

  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 already describes both parameters (target_group and max_monthly_budget_kes) with defaults. The description adds no additional parameter-specific meaning, 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 tool compares microinsurance options for low-income Kenyans. It distinguishes itself from sibling tools like community_pool_calculator and kenya_insurance_products by specifying its focus on microinsurance comparison.

  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 context (Western parallel, East Africa context) indicating when to use: for comparing microinsurance for low-income Kenyans. It does not explicitly exclude cases or mention alternatives, but the context is clear enough.

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

• parametric_crop_riskA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so no destructive behavior. The description adds context about the methodology (NDVI satellite index, NDMA drought history) and clarifies the demo nature, which goes beyond the annotation. 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?

  Four sentences with no wasted words. The first sentence states the purpose, followed by methodology and a critical limitation. Front-loaded and easy to parse.

  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 description covers purpose, methodology, and the demo limitation. With an output schema present, it does not need to describe return values. It could mention what happens with invalid inputs or missing seasons, but overall it is adequate for a non-trivial 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 each parameter having a description. The tool description provides context about Kenya farming and satellite indexes but does not elaborate on the individual parameters beyond what the schema already gives. 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 verb 'Calculate' and the resource 'parametric crop insurance risk' for a specific user (Kenya smallholder farmer). It distinguishes from sibling tools that deal with community pools, microinsurance comparisons, products, NHIF, and premium estimates.

  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 notes that the tool uses DEMO data and actual payouts require enrollment, which helps set expectations. However, it does not explicitly tell the agent when to use this tool versus alternatives like 'premium_estimate' or 'community_pool_calculator', though the purpose is sufficiently distinct.

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