Server Quality Checklist

Tool Scores

• extract_batch_metadataC
  2.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 bears the full burden. It mentions a price range and 'via x402' but does not explain the payment mechanism, what happens without payment, or any side effects. The max 50 limit is noted, but other behavioral traits (e.g., idempotency, error handling) are missing.

  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 short and front-loads the core purpose. It is efficient with one sentence plus pricing. However, it could be slightly more structured to include behavior or parameter hints, but overall it is concise and not verbose.

  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 the tool has 4 parameters, nested objects, no output schema, and no annotations, the description is incomplete. It omits details about return values, error handling, authentication (beyond payment hint), and concurrency for batch processing. Significant gaps remain.

  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?

  Schema coverage is 50% (only paymentHeader and payer have descriptions). The description does not add any parameter-level detail beyond what is in the schema. For example, options is not explained, and imageUrls' limit is already in schema. No additional semantics are provided.

  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 extracts metadata from multiple images with a max of 50, which is a specific verb+resource+limit. The name and sibling tools (extract_image_metadata) imply differentiation between batch and single, but the description does not explicitly distinguish, though it is still clear.

  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 on when to use this tool versus alternatives like extract_image_metadata or detect_image_manipulation. The pricing mention hints at a payment requirement but does not explain prerequisites or when to choose batch over single image extraction.

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

• detect_image_manipulationC
  2.9/5.0
  Behavior2/5

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

  With no annotations, description should fully disclose behavior. Only mentions pricing ($0.002-0.015 USDC) but not what the analysis entails, side effects, or limitations.

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

  Conciseness3/5

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

  Extremely brief (single sentence) but lacks essential details. Adequate conciseness but under-specified.

  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?

  No output schema, 4 parameters including payment and freemium fields. Description does not explain return values, error handling, or behavior changes with different analysis levels.

  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?

  Schema coverage is 50%, but description adds no parameter-specific meaning. Parameters like 'analysisLevel' (with enum) are not elaborated 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 clearly states verb 'Analyze' and resource 'image' with specific purpose 'for manipulation signs'. Distinct from siblings (extract_batch_metadata, extract_image_metadata, get_pricing) which focus on metadata or pricing.

  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 on when to use this tool versus alternatives. Mentions pricing and payment parameters but does not specify context or exclude cases.

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

• extract_image_metadataA
  3.5/5.0
  Behavior3/5

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

  The description mentions a cost ($0.002 USDC via x402), which is a behavioral trait not in annotations (none provided). However, it does not clarify if payment is mandatory, what happens without paymentHeader, or any side effects. No annotations exist, so description carries burden but adds limited transparency beyond cost.

  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?

  Two sentences, front-loaded with purpose ('Extract metadata from image (EXIF, GPS, IPTC, XMP).'), then pricing. No redundancy. Could be slightly more informative about payment flow, but overall efficient and well-structured.

  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?

  The tool has nested input schema (includeOptions), optional payment parameters, and no output schema. The description does not explain the return format, the meaning of includeOptions, or how payment works (x402). Given the complexity and missing output schema, the description is incomplete.

  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 75% (all parameters have descriptions, nested options have defaults). The tool description adds no additional parameter-level information beyond what the schema provides. At high coverage, baseline 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 'Extract' and resource 'metadata from image', and lists specific metadata types (EXIF, GPS, IPTC, XMP). It distinguishes from siblings like detect_image_manipulation (manipulation detection) and extract_batch_metadata (batch operation) by implying single image focus.

  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 guidance on when to use vs alternatives like batch extraction or pricing tool. The description implies single image use but does not address when to choose this over extract_batch_metadata or detect_image_manipulation. The pricing info is a usage hint but not a guideline.

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

• get_pricingA
  4/5.0
  Behavior3/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 indicates a read operation but does not disclose any behavioral traits such as data freshness, rate limits, or caching behavior. For a simple no-parameter tool, this minimal disclosure is adequate but not rich.

  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, clear sentence with no unnecessary words. It is front-loaded with the key information and 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 no parameters, no output schema, and no annotations, the description covers the basic functionality. However, it lacks details on the output structure or what constitutes 'pricing tiers,' which could be improved for 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 tool has zero parameters, and schema coverage is 100% (vacuously). The description adds no param information because none is needed. Per guidelines, 0 parameters earns a baseline of 4.

  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: retrieving current pricing for image metadata extraction tiers. It uses a specific verb ('get') and resource ('pricing'), and distinguishes itself from siblings like detect_image_manipulation and extract_image_metadata.

  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 does not provide explicit when-to-use or when-not-to-use guidance. While it is clear that the tool is for pricing queries, no alternatives or conditions are mentioned, which is acceptable given the lack of similar sibling tools in this domain.

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