Server Quality Checklist

Tool Scores

• create_parcelB
  3.4/5.0
  Behavior2/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. It discloses that the response is 'normalized' and that booking spans multiple couriers, but it does not describe side effects such as external shipment creation, possible charges, idempotency, failure modes, or authentication needs. This is thin for a mutating tool.

  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 front-loaded sentence that states the action, scope, and couriers with no filler. Every phrase contributes context, and the 'normalized response' clause is a useful compact hint about the output.

  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 eight parameters, five required fields, no output schema, and no annotations, a one-sentence description leaves several operational gaps: it does not say which fields are required, how 'auto' courier routing works, what the normalized response contains, or what happens if booking fails. The schema covers parameter format, but the description is incomplete for real invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents every parameter, including defaults, enum choices, and the Bangladeshi phone format. The description adds regional context and repeats courier names from the enum, so it adds only marginal value beyond the parameter 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 the action verb 'Book' and identifies the exact resource: 'a new parcel delivery across Bangladesh.' It also names the supported couriers, which clearly distinguishes this creation tool from sibling tools like list_couriers, track_parcel, and get_balance.

  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 phrase 'Book a new parcel' implies this tool is for creating deliveries, and the sibling names make tracking/listing alternatives apparent. However, the description does not explicitly say when to use it vs alternatives or state exclusions, such as using track_parcel for existing shipments.

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

• track_parcelA
  3.7/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 full burden of behavioral disclosure. It communicates the supported couriers and input type, and 'Track' implies a read-only operation. However, it does not describe what the response contains, failure behavior, or whether courier detection is automatic.

  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, well-structured sentence front-loads the action, resource, supported couriers, and required input. There is no superfluous text, and the description earns its place without bloating the tool definition.

  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 tracking tool with two parameters, the description is adequate, but it lacks details an agent might need, such as expected output shape, behavior for invalid tracking codes, or whether the courier field is needed for all providers. Since there is no output schema, a little more context about what is returned would make this fully complete.

  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 both parameters are already documented. The description adds marginal value by restating that the tracking code is the Consignment ID and listing the courier enum values, but it does not provide any 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?

  The description uses a specific action ('Track shipment delivery status') with a clear resource (parcel shipments), and names the supported couriers. It is immediately distinguishable from sibling tools like create_parcel, get_balance, and check_fraud_risk, even without opening the schema.

  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 purpose is clear enough that an agent can infer this tool is for delivery-status lookups, but there is no explicit guidance about when not to use it or which alternative should be chosen instead. No sibling alternatives are mentioned, so usage context is implied rather than stated.

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

• check_fraud_riskA
  3.8/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 full burden of behavioral disclosure. It implies a non-destructive analysis by saying 'Analyze ... and return/fraud risk score', but it does not explicitly state whether the operation is read-only, whether it blocks anything, or what data sources it consults. The core behavior is clear, but the safety profile is left to inference.

  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 with the action and timing front-loaded. There is no filler. The only minor flaw is the slightly awkward phrase 'return/fraud risk score,' which momentarily suggests 'return' might be a verb, but overall the structure is efficient and scannable.

  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 single-parameter tool with no output schema and no annotations, the description covers what the tool does and when to use it, but it omits essential interpretation of the returned 'return/fraud risk score'—there is no indication of range, direction (higher vs. lower risk), or units. Since there is no output schema to compensate, this is a meaningful gap.

  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 fully documents the only parameter 'phone' ('11-digit Bangladeshi phone number to evaluate'), giving 100% coverage. The description adds context that the phone relates to delivery history, but it doesn't add new semantic detail beyond what the schema provides, so the baseline score of 3 applies.

  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 names a specific verb ('Analyze'), a concrete resource ('Bangladeshi customer phone number delivery history'), and a clear output ('return/fraud risk score'), all tied to a distinct moment ('before dispatching'). This clearly differentiates it from siblings like list_couriers, create_parcel, track_parcel, and get_balance, which have entirely 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 Guidelines4/5

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

  The phrase 'before dispatching' provides clear, actionable context for when to use the tool. It doesn't explicitly mention alternatives or exclusion conditions, but the sibling tools are so functionally distinct that no ambiguity exists. This fits 'clear context, no exclusions'.

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

• get_balanceA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description must carry the burden of explaining behavior. The verb 'Retrieve' clearly signals a read-only operation, and 'current' indicates the balance is fetched live rather than from a cache. It does not mention authentication or rate limits, but for a simple read-only balance tool, the core behavioral traits are disclosed.

  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, focused sentence with no filler. It front-loads the action ('Retrieve') and follows with the exact object and scope, making it easy to parse quickly.

  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 is simple: one required parameter, no nested objects, no output schema. The description adequately conveys what is returned ('balance and payout details') and the source ('a courier'). It stops short of describing the exact response shape, but given the low complexity, this is complete enough for an agent to invoke the tool 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 description coverage is 100%, so the schema already fully documents the only parameter ('courier', including its enum values and description). The tool description adds no extra meaning beyond the schema, so the 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 uses a specific verb ('Retrieve') and clearly identifies the resource: 'merchant account balance and payout details'. This distinguishes it immediately from sibling tools like create_parcel, track_parcel, and check_fraud_risk, which have obviously 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 use is implied by the function name and description: call this when you need a merchant account balance or payout details for a courier. However, it does not explicitly state when not to use it or mention any alternative/companion tool, so usage guidance is present only by implication.

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

• list_couriersA
  4/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 behavioral burden. 'Show' and 'check' clearly imply a read-only operation with no destructive side effects, which adds transparency. However, it does not disclose whether the credential check calls external courier APIs or what happens when credentials are missing/expired, leaving some behavioral 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 entire description is a single, focused sentence with the main action up front, courier examples in parentheses, and no filler or redundant wording. Every phrase 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?

  For a low-complexity, zero-parameter tool, the description covers the core information an agent needs: what is listed and that credentials are validated. It lacks only a precise statement of the output shape, such as a list of couriers with active/expired credential status, which is a modest gap given that no output schema is present.

  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 an empty input schema, so there is no parameter gap for the description to fill. The description appropriately focuses on what the tool returns rather than inputs, meeting the baseline for a no-parameter tool.

  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 starts with a concrete verb ('Show') and a specific resource ('supported Bangladeshi couriers'), then enumerates the exact couriers and adds the credential-checking function. This makes the tool's purpose immediately obvious and distinguishable from create_parcel, track_parcel, get_balance, and check_fraud_risk without needing to inspect any schema.

  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 intended use: check which couriers are supported and whether credentials are active, likely before creating a parcel. It does not explicitly state when to prefer this tool over its siblings or mention any exclusion cases, so the when-to-use 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.