Server Quality Checklist

Tool Scores

• get_originsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It does not explicitly state read-only status, authentication needs, rate limits, or return format. The 'Get' verb implies a read operation, but this is not stated.

  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 front-loaded with the purpose. The Args block is directly relevant and contains no filler.

  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 getter with one parameter, the description covers the core function correctly. However, without an output schema, it does not specify the structure of the returned list (e.g., strings vs objects), which would improve 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?

  The schema lacks descriptions, but the description's Args section explains the provider parameter with examples ('bus', 'mysafari', 'otapp') and its default value. This adds meaningful context beyond the schema's bare property definition.

  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 retrieves a list of available origin locations for bookings, using a specific verb ('Get') and resource. It is implicitly distinguished from sibling get_destinations via the origin/destination contrast, though not explicitly named.

  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 like get_destinations or search_trips. There is no mention of prerequisites, exclusions, or context beyond the general 'for bookings' phrase.

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

• generate_receiptB
  3.3/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 transparency burden. It discloses only the primary action without detailing system behavior such as dependencies (e.g., booking must exist), side effects, error handling, or whether it is a read-only operation. This is minimal disclosure.

  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 concise summary: a one-sentence purpose followed by a short Args list. It is front-loaded, contains no redundant content, and every sentence contributes meaning.

  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?

  An output schema exists, covering return format, but the description omits usage context such as when a receipt should be generated, whether the booking must already exist, and how provider affects the receipt. It is minimal but adequate for a simple tool, leaving room for improvement.

  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?

  With 0% schema description coverage, the 'Args' section adds brief definitions for booking_ref and provider. It clarifies that booking_ref is an ID and provider is the booking provider, but it does not explain provider's default value, valid options, or optionality beyond the schema's default. The added value is moderate.

  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 'Generate a formatted text receipt for a given booking reference,' which clearly identifies the action (generate) and the target (receipt for a booking). This is distinct from sibling tools like search_trips or create_booking, making it easy to differentiate.

  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 no guidance on when to use this tool versus alternatives such as get_booking_history or initiate_payment. It only states the action without mentioning prerequisites, conditions, or exclusions, leaving the agent without selection criteria.

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

• get_booking_historyB
  3.3/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 disclose behavior. It only says 'Get the agent's booking history,' implying a read operation, but does not mention whether it reads only the authenticated agent's bookings, whether pagination is required, if results are sorted, or any side effects. The lack of annotations and behavioral context leaves the agent with limited understanding of what will happen.

  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 extremely concise: one sentence plus an Args list. It front-loads the core purpose and uses a clear format for parameters. No redundant words or filler content, so every sentence earns its place.

  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 there is no output schema and no annotations, the description provides the basic idea and parameters but lacks details about return format, pagination behavior, or how to interpret results. It does not mention any prerequisites or limitations. It is minimally viable but could be enhanced with more context.

  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 descriptions, so the description adds useful clarifications: 'page: Page number (starts at 1)' and 'per_page: Items per page (max 100)'. It also labels status and provider as filters. However, it does not specify allowed values or format for status/provider, leaving ambiguity. The added meaning is helpful but incomplete.

  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 purpose: 'Get the agent's booking history.' The verb 'Get' and resource 'booking history' make it distinct from siblings like search_trips or create_booking. It also lists relevant arguments that reinforce its role as a 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 Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention that it is for past bookings vs. searching available trips, nor does it note any competition with sibling tools. The description only states what it does, not when to invoke it.

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

• initiate_paymentA
  3.5/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 of behavioral disclosure. It mentions 'push payment request' but does not describe side effects (e.g., customer receives a mobile money prompt, potential charge), success/failure behavior, return values, or any prerequisites. The agent is left without a clear model of what happens when the tool is invoked.

  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: a one-line summary followed by a clean Args list. Every sentence and parameter line adds value without redundancy. It is appropriately sized for the tool's complexity.

  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 4-parameter tool with no output schema and no annotations, the description covers the core purpose and parameter semantics reasonably well. However, it lacks critical behavioral context such as expected outputs, error conditions, or side effects, which an agent would need to invoke the tool confidently in a real scenario. The absence of any return value description is a notable gap.

  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 description coverage is 0%, so the description must compensate for the lack of parameter details. It does so effectively by explaining each parameter: booking_id is the booking to pay for, provider is the booking provider (e.g., mysafari), customer_phone is the customer's number for the push, and payment_provider is an optional mobile money provider (e.g., VODACOM, TIGO). This adds meaning beyond the raw parameter names and 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?

  The description clearly states the tool's function: 'Initiate a customer push payment request for a booking.' The verb 'initiate' and resource 'payment request' are specific, and the scope (for a booking) distinguishes it from sibling tools like generate_receipt or get_payment_providers.

  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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention any preconditions, when not to use it, or how it relates to sibling tools. The only implied usage is that it is for initiating payments, but no exclusions or alternative tools are named.

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

• create_bookingA
  3.7/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 of behavioral disclosure. The description only says 'Create a new booking' and lists arguments; it does not disclose side effects (e.g., whether a payment is initiated), permission requirements, reversibility, or what the response contains. For a mutation tool, this is a significant transparency gap.

  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 a one-sentence purpose, followed by a structured Args list. It is informative without excessive verbosity, though the Args block is somewhat long. No wasted sentences, but the formatting is mildly repetitive (parameter names repeated in descriptions).

  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 tool has 6 parameters including a nested structure, yet no output schema and no annotations. The description covers all parameters well, but it omits return value/response behavior, potential error conditions, and usage context. For a create action this is incomplete—an agent would not know what the tool returns or whether it can fail due to unavailability.

  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 description coverage is 0%, so the description must compensate, and it does thoroughly. It explains each parameter, including the nested passenger dictionary with all required fields (name, phone_number, etc.), provider examples, date format (YYYY-MM-DD), and optional nature of origin_id, destination_id, and travel_date. This adds substantial meaning beyond the bare 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 opens with a clear, specific verb+resource: 'Create a new booking.' This unambiguously distinguishes it from sibling tools like get_booking_history, search_trips, and initiate_payment. The purpose is immediately apparent.

  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 when to use the tool (when creating a booking) but offers no explicit guidance on alternatives, prerequisites, or when NOT to use it. For example, it doesn't mention that search_trips should be used first to obtain a trip_id, nor does it reference sibling tools for origins/destinations. The usage is implied rather than spelled out.

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

• get_destinationsA
  3.7/5.0
  Behavior2/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 behavioral disclosure. It only implies a read-only operation via the verb 'Get' but does not mention side effects, error conditions, authentication requirements, or return format. There is no added context about pagination, rate limits, or data source behavior.

  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 front-loaded with the purpose. The args section is standard and adds necessary parameter context without fluff. Every sentence earns its place, and there is no redundant repetition of schema information beyond the default value, which is already visible in the schema.

  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 tool is simple, but without an output schema, the description should at least indicate what the list contains (e.g., destination names, IDs) and any caveats like empty results or provider-specific behavior. It does not, leaving some gap for the agent. Still, for a straightforward list endpoint, this is a minimally viable description.

  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 description coverage is 0%, so the description must compensate. It provides meaningful explanations for both parameters: origin_id as 'The ID of the origin location' and provider as 'The booking provider name. Default is bus.' This goes beyond the schema's bare property names and titles, though provider could include allowed values or examples.

  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: 'Get a list of available destination locations for a given origin.' The verb 'Get' is specific, and the resource 'destination locations' is well-defined with the scoping condition 'for a given origin.' This distinguishes it from sibling tools like get_origins and search_trips.

  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 when to use the tool (when you need destinations for a known origin), but it offers no explicit guidance on alternatives or exclusions. It does not mention that get_origins should be used first to obtain the origin_id, nor does it contrast with search_trips. Usage context is present but not fully articulated.

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

• search_tripsA
  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 the full burden for behavioral disclosure. It communicates that this is a search operation (read-only by implication) and provides parameter details, but it does not disclose potential behaviors like result limits, pagination, error handling, or date validation nuances. This adds some value but lacks rich context.

  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: an opening sentence states the purpose, followed by a bulleted Args list. Every line provides useful information, with no redundant or vague content, and the parameter details are easy to scan.

  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 covers all parameters thoroughly and mentions defaults, but it does not describe the output format or behavior when no trips are found. There is also no mention of prerequisites like valid location names from get_origins/get_destinations. Given the lack of annotations and output schema, these gaps make the description adequate but not fully 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 schema has 0% description coverage, so the description must compensate. It provides clear meaning for each parameter: examples for origin_name and destination_name, a format for travel_date, and defaults for provider, adults, and children. It could add constraints like minimum values for adults, but overall it effectively explains all 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 'Search for available trips between an origin and destination on a specific date,' using a specific verb and resource. It distinguishes itself from siblings like get_origins/get_destinations by focusing on trip search, and from create_booking by being a search rather than a booking action.

  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 when to use the tool (when searching for trips) but does not explicitly state exclusions or mention alternative tools. There is no guidance on when not to use it or how it relates to other sibling tools like get_origins or create_booking, leaving the agent to infer the intended use case.

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

• get_payment_providersA
  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 of behavioral disclosure. It only states the action and scope, omitting potential side effects, authentication requirements, or response structure. This leaves gaps for a tool with zero annotation coverage.

  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 concise sentence that front-loads the verb and resource. It contains no redundant words and effectively communicates the tool's 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 zero-parameter read-only tool, the description is largely adequate. It could mention the nature of the list or response format, but given the tool's simplicity, it is complete enough for an agent to understand what to expect.

  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 and the schema is empty, so there are no parameter details to disclose. The baseline for 0 params is 4, and the description does not need to compensate for any missing parameter information.

  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 a list of mobile money payment providers for customer push payments. It uses a specific verb (Get) and resource (list of providers), and it distinguishes itself from siblings like get_origins/destinations and initiate_payment.

  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 clear context by specifying 'for customer push payments', implying when this tool should be used. It does not explicitly mention alternatives or exclusions, but the context is sufficient for agents to select it appropriately.

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

• get_health_statusA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It clearly presents a read-only health check with no side effects, which is transparent for this tool's simple nature. It could mention output format or potential errors, but that is not critical for a health check.

  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, concise sentence that front-loads the resource and purpose. Every word earns its place with zero 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?

  For a zero-parameter, no-output-schema health check tool, the description adequately communicates purpose and action. Minor gap: it does not describe the form or interpretation of 'health status', but this is not essential for a simple monitoring 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 schema has zero parameters, so there is nothing to explain. The baseline of 4 applies because the description does not need to compensate for missing parameter documentation.

  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 a specific verb 'check' with a clear resource 'health status of the Flowteller API'. This distinguishes it from sibling tools which focus on booking/payment operations.

  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?

  No explicit when-to-use or alternative guidance is given. However, the purpose inherently implies it is for API health monitoring, and the sibling names suggest they are unrelated, so usage is implied rather than explicitly stated.

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