Server Quality Checklist

Tool Scores

• get_governing_documentB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only implies a read operation via 'Get' and lists return values, which are likely already covered by the output schema. It does not disclose error handling, prerequisites, or any other behavioral traits.

  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 and well-structured, with clear sections for description, args, and returns. Every line serves a purpose, and there is no extraneous information.

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

  Completeness3/5

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

  For a simple one-parameter get tool, the description covers the essential purpose and return values. However, with no annotations and no differentiation from sibling tools, there are gaps in usage guidance and behavioral transparency, making it just adequate.

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

  Parameters2/5

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

  The description merely restates the parameter name and adds 'The charity's registration number,' which provides minimal additional meaning beyond the schema's type and title. It does not clarify format, source, or validation rules for the registration_number.

  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 retrieves charitable objects and governing document for a charity, using a specific verb and resource. This distinguishes it from sibling tools like financials, trustees, and details, which cover different aspects of charity data.

  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 when governance-related information is needed, but it does not explicitly state when to choose this tool over siblings or provide exclusion criteria. No alternatives are mentioned, so guidance is only implicit.

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

• get_charity_financialsA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosure. It adds meaningful behavioral context by specifying 'Up to 5 years of financial data' and 'detailed income and spending breakdowns,' which goes beyond the bare operation name. However, it does not mention any error conditions or access requirements, though for a read-only lookup this is acceptable.

  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 compact, uses a clear Args/Returns structure, and every sentence earns its place. It avoids redundant filler and is appropriately sized for the tool's simple single-parameter signature.

  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 an output schema (though not shown), so the description need not fully explain returns, but it does anyway, noting the 5-year limit and breakdowns. With one parameter, no annotations, and a simple purpose, the description covers the essential context adequately. It lacks edge-case guidance (e.g., invalid registration number) but is otherwise complete for this level of complexity.

  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 has no per-parameter descriptions (0% coverage), so the description must compensate. It does provide a definition: 'registration_number: The charity's registration number.' This is essentially a restatement of the parameter name and adds little semantic value beyond confirming the obvious, but it is sufficient for a single well-named parameter.

  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 a specific verb+resource: 'Get detailed financial history for a charity.' This clearly distinguishes the tool from siblings like get_charity_details, get_charity_trustees, and get_governing_document, 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 intended usage is implied by the tool name and sibling context, but the description does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative use cases, so guidance is merely inferred rather than explicit.

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

• get_charity_trusteesA
  4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It does mention the return value (charity name and current trustees), which provides some context, but it omits behavior like error handling, ordering, or what happens if the charity is not found. This is minimal but not completely absent.

  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 a clear two-part structure of Args and Returns. Every sentence is useful and it is front-loaded with the main 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?

  For a simple read tool with one parameter and an output schema, the description is adequately complete. It specifies the return content, and given low complexity, the lack of edge-case details is acceptable.

  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 0%, so the description must compensate. It documents the registration_number parameter as 'The charity's registration number,' adding meaning beyond the bare integer type. However, it does not provide validation rules or format specifics.

  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 the list of trustees for a charity, using a specific verb and resource. It is distinct from sibling tools such as get_charity_details and get_charity_financials, which cover other aspects of charity data.

  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 usage is implied: if you need trustee information, use this tool. However, it does not explicitly mention when to use it over alternatives or provide any exclusions such as requiring a valid registration number. There is no comparison to sibling tools.

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

• get_charity_detailsA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It states the output scope (contact details, trustees, finances) and the read-only nature (via 'Get'), but does not disclose any potential limitations such as rate limits or data volume.

  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, front-loaded with the purpose, and uses clear Args and Returns sections without any fluff.

  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 one-parameter read tool, the description covers what it does, how to obtain the input, and what to expect in return, all in a few sentences. The presence of an output schema further completes the picture.

  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?

  Although the schema only defines an integer parameter, the description's Args section adds a concrete example (202918 for Oxfam) and a direct link for finding registration numbers, fully compensating for the 0% schema description coverage.

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

  Purpose5/5

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

  The description opens with a clear verb ('Get'), resource ('full details for a UK charity'), and required input (registration number), clearly distinguishing it from sibling tools that focus on specific aspects like financials or trustees.

  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 clearly indicates this is the comprehensive lookup tool ('full details'), implying when to use it over the more specific siblings, though it doesn't explicitly mention alternatives or exclusions.

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