Server Quality Checklist

Tool Scores

• gpu_statusB
  3.3/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. It mentions 'retrieve results' indicating output behavior, but omits critical async details: whether this blocks, if repeated polling is expected, result expiration, or what status values (e.g., running, completed, failed) are possible.

  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?

  Single efficient sentence with no filler. Information is front-loaded (action + subject + outcome). Every word 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?

  Adequate for a single-parameter tool, but lacking given the absence of an output schema. For a status retrieval tool, describing the possible status states or result payload structure would significantly improve 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 coverage is 100% with job_id well-documented. The description mentions 'GPU-Bridge job' which loosely contextualizes the parameter, but adds no syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 is appropriate given high schema 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?

  Clear verb ('Check') and resource ('GPU-Bridge job'), plus outcome ('retrieve results'). However, it does not explicitly differentiate from siblings like gpu_run or gpu_catalog within the description text, relying instead on the tool name to signal its polling/retrieval role.

  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?

  Provides no explicit guidance on when to use this tool versus alternatives, or that it requires a job_id from gpu_run first. The schema parameter description mentions it returns job IDs from gpu_run, but the main description lacks usage context.

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

• gpu_balanceA
  3.5/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Lists four specific data categories returned (good), but omits operational details: no mention of authentication requirements, rate limits, pagination for job history, or whether data is real-time vs cached.

  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?

  Single sentence, front-loaded with action verb. No filler words. Every clause specifies a distinct data category returned. Optimal density.

  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 account-query tool without output schema, listing the four return data categories provides adequate completeness. Missing only operational metadata (Auth, TTL) which would be nice-to-have but not critical for this complexity level.

  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?

  Zero parameters present per schema. With no parameters to document, baseline score 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?

  Specific verb 'Check' and concrete resources listed (credit balance, daily spend, volume discount tier, job history). While distinct from siblings (gpu_run, gpu_status, etc.) by nature of the data, the description does not explicitly differentiate usage scopes in text.

  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 explicit guidance on when to use this versus siblings (e.g., 'Check this before running jobs with gpu_run' or 'For current job status use gpu_status'). Lacks prerequisites or conditional logic.

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

• gpu_runA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Adds valuable performance context ('sub-second', '<1s', 'fast' vs 'cheap' routing) but omits critical operational details: authentication requirements, error handling patterns, cost implications, and whether operations are idempotent or destructive.

  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?

  Information-dense and front-loaded with main purpose. The exhaustive service list (30 items) is necessary given the tool's polymorphic nature. Ends with actionable sibling reference. Efficient sentence structure with minimal 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?

  Complex multi-service tool with nested input objects but no output schema. Description comprehensively covers input capabilities and service types but fails to describe return values, error formats, or rate limiting—critical gaps given the absence of structured output schema.

  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 detailed examples (especially for 'input' object's polymorphic structure). Description adds high-level categorization of services but largely overlaps with schema enumerations; does not significantly augment parameter understanding beyond schema 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?

  Clear specific verb (Run) + resource (GPU-Bridge AI service) with explicit scope (30 services). Distinguishes from siblings by directing users to gpu_catalog for discovery while this handles execution.

  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 directs users to 'use gpu_catalog to see all available services,' establishing clear workflow (catalog for discovery, run for execution). Could strengthen by noting gpu_estimate/balance for cost checking before execution.

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

• gpu_estimateA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It successfully adds the authentication requirement (no auth needed) which annotations would typically cover. However, missing: idempotency, rate limits, what the estimate returns (format/currency), and error behaviors for invalid service keys.

  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, zero waste. First establishes purpose and timing relative to execution; second states auth requirement. Every word earns its place. Well front-loaded with action verb leading.

  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?

  Tool has simple 2-parameter schema with full coverage, but no output schema exists. Description fails to specify what the estimate returns (numeric value? object? currency units?). Given no annotations and no output schema, the description should have disclosed return format. Adequate but with clear gaps.

  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 clear descriptions and examples (e.g., 'llm-4090'). Description does not need to repeat parameter definitions per calibration guidelines. Baseline 3 is appropriate as description adds no parameter syntax beyond 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 uses specific verb 'Estimate' with resource 'cost' and scope 'GPU-Bridge service'. The phrase 'before running it' clearly distinguishes this from sibling gpu_run, implying this is a pre-flight check.

  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?

  States 'before running it' implying workflow order (use this prior to gpu_run). Explicitly notes 'No authentication required' which is a critical usage constraint. However, does not explicitly name gpu_run as the alternative or describe when NOT to use it (e.g., when you need actual execution).

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

• gpu_catalogA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full disclosure burden. It successfully reveals authentication requirements and return data categories (pricing, model info). Missing operational details like rate limits, caching behavior, or pagination for large catalogs.

  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 total with zero waste. Front-loaded with primary purpose ('List all available...'), followed by critical behavioral constraint ('No authentication required'). Every word 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?

  Appropriately complete for a simple catalog tool. Mentions return data content (pricing/model info) to compensate for missing output schema. Could be improved by indicating return format (array vs object) or pagination behavior.

  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?

  Zero parameters present, meeting the baseline score of 4 per rubric. Description appropriately focuses on behavioral semantics and return data rather than inventing parameter documentation where none exist.

  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 specific verb 'List' with resource 'GPU-Bridge services' and scope details 'pricing and model info'. Effectively distinguishes from operational siblings (gpu_run, gpu_balance) by positioning as a catalog/browse function.

  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?

  States 'No authentication required' which provides a usage constraint, implying when it can be called safely. However, lacks explicit when-to-use guidance relative to siblings (e.g., 'use before gpu_run to select a model') or exclusion criteria.

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