Server Quality Checklist

Tool Scores

• pollinations_check_balanceA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds critical context beyond that: the requirement for POLLINATIONS_API_KEY in the MCP client's env block, and detailed HTTP error semantics (401/403/402). This equips the agent for real-world deployment and troubleshooting.

  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 well-structured with clear sections for purpose, usage timing, auth, args, returns, and errors. Every sentence conveys necessary information without fluff or redundancy, making it dense yet easily parsed.

  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?

  Given the tool's simplicity (one optional parameter, read-only, no output schema), the description covers all relevant aspects: what it does, when to use it, required environment setup, what it returns, and error handling. An agent has everything needed to invoke it correctly and interpret results.

  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 input schema already fully describes response_format with enum values, default, and a description. The tool description's arg explanation ('markdown for readable balance output, json for raw account/budget response') essentially restates the schema's description without adding new meaning, so it meets the baseline but adds no extra semantic value.

  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') and names the exact resource ('Pollinations pollen balance or API key budget') plus the underlying endpoint ('/account/balance'). This clearly differentiates it from the sibling generation and model-listing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  Explicitly states when to use: 'Use this before expensive image/video generation when the user asks about available pollen, credits, budget, or why a generation may be failing with payment/balance errors.' This gives actionable, context-rich guidance that an agent can directly apply.

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

• pollinations_edit_imageA
  4.9/5.0
  Behavior5/5

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

  Annotations only signal readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context beyond these: it calls the Pollinations OpenAI-compatible endpoint, saves output to local files by default (save_output=true), explains response formats and revised_prompt, and documents error codes (401/402/403/400). This is rich, non-contradictory behavioral disclosure.

  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 long but well-structured with clear sections (usage, args, returns, examples, error handling). It front-loads the core purpose and usage guidance. A small amount of redundancy with the schema's parameter descriptions exists, but each sentence generally earns its place given the tool's complexity.

  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?

  With 19 parameters, no output schema, and a complex external API, the description still manages to cover when to use, how to invoke, parameter details, expected return values, examples, and error handling. The inclusion of a concrete example instruction ('keep the bee robot unchanged, replace the background...') and exact error semantics makes it exceptionally complete.

  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 coverage is 100%, but the description goes far beyond the schema by adding practical guidance for each parameter: recommended model candidates (kontext, gptimage, etc.), the relationship between size/width/height, preference for b64_json because Nectar can decode it directly, and explicit caveats like 'Local file paths are not supported in v1.' It significantly enriches parameter understanding.

  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 specific verb and resource: 'Edit or transform existing image URL(s) with Pollinations using a text instruction.' It explicitly names the underlying endpoint and clearly distinguishes itself from the sibling tool pollinations_generate_image by stating 'Do NOT use this for a brand-new image with no source image; use pollinations_generate_image instead.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance ('Use this when the user provides one or more source images and wants changes such as restyling, object/background changes, cleanup...'), a direct exclusion with an alternative tool, and even advises calling pollinations_list_models first if unsure about the model. This is exemplary usage guidance.

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

• pollinations_get_model_detailsA
  4.9/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent annotations, this description reveals important behavioral traits: the 15-minute in-memory cache behavior, the ability to bypass it with refresh=true, and that refresh refetches /image/models first. It also states the return value is full metadata, which adds transparency about what the agent will receive.

  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 well-organized: it opens with the core purpose, follows with usage context, then a structured args list, and closes with returns and fallback behavior. Every sentence carries necessary information, and the structure makes it easy to scan.

  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 read-only lookup tool, this description is complete. It covers purpose, usage timing, cache/refresh behavior, response format options, return value, and a failure fallback action. The lack of an output schema is acceptable because the description clarifies that full metadata is returned and gives examples of the fields involved.

  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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by giving concrete model examples (nanobanana, p-image-edit, ltx-2) and specifying that refresh refetches /image/models, which is a detail not present in the schema. This modestly elevates it above the baseline.

  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 this tool retrieves full metadata for a single Pollinations image or video model by name or alias, using the specific verb 'Get' and a specific resource. It differentiates itself from siblings by mentioning it is used after pollinations_list_models for detailed information, and it lists exact fields like pricing and capabilities.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  The description gives explicit usage guidance: 'Use this after pollinations_list_models when an agent needs exact pricing, capabilities...' It also provides a fallback instruction: 'If no model matches, call pollinations_list_models with a broader search.' This clearly indicates when to use this tool versus alternatives.

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

• pollinations_list_modelsA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent), the description discloses 15-minute in-memory caching, no API key requirement, refresh behavior, and error handling guidance. This adds meaningful operational context without contradicting the annotations.

  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 fairly long but organized into Args, Returns, Examples, and Error handling, with a clear first sentence. Minor redundancy exists (e.g., the 'prefer pollinations_get_model_details' advice appears twice), so it is not perfect, but it earns its detail.

  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?

  Given no output schema, the description explains return content ('Compact model names, category, pricing, input/output modalities, and key capability flags'), provides worked examples for common queries, and covers error handling. For a 12-parameter list tool with caching and various filters, this is fully sufficient.

  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 covers all 12 parameters, the description enriches them with practical guidance: e.g., 'Use sort_by=price and sort_order=asc to find cheaper models,' and warns against using 'cheap' as a search term. It also maps filters to use cases like reference-image support and end-frame videos.

  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 specific verb and resource: 'List currently available Pollinations image and video models from /image/models.' This clearly distinguishes it from sibling tools like pollinations_generate_image or pollinations_get_model_details.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  It explicitly states when to use: 'Use this before generation when model choice, pricing, modality, reference-image support, end-frame support, or audio support is unclear.' It also provides exclusions ('Do not use search='cheap'') and points to alternatives ('For one model, prefer pollinations_get_model_details').

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

• pollinations_generate_imageA
  5/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), the description discloses rich behavioral context: whether output is a URL or base64, local saving behavior with save_output, default output directory, model-specific support for features like transparent and negative_prompt, and a detailed error-handling section covering 400/401/402/403/429 responses. This far exceeds what annotations provide and contains no contradictions.

  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 long but every section earns its place given the tool's complexity. It is front-loaded with the core purpose, then moves through behavior, parameters, return format, examples, and error handling in a logical, scannable structure. No filler sentences; each part provides actionable detail.

  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?

  There is no output schema, so the description correctly covers return values ('Returns: Markdown or JSON with the generated URL, base64 length, and revised_prompt'). It also includes examples for common scenarios, error handling, and parameter interplay. For a tool of this complexity (19 params, multiple modes, network calls), the description is complete enough for an agent to select and invoke it correctly.

  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?

  Even though schema coverage is 100%, the description adds substantial meaning beyond the raw schema. It explains prompt specificity, the complete list of known model slugs, the rationale for choosing b64_json over url, how width/height interact with size, what Nectar sanitizes, what safe filter values mean, and which parameters are model-dependent. This is exemplary parameter guidance for a 19-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 opens with a specific verb+resource ('Generate an image from a text prompt using Pollinations image models') and clearly distinguishes from the sibling tool by stating 'Do NOT use this for editing an existing image... use pollinations_edit_image instead.' It also covers both text-to-image and image-to-image modes, leaving no ambiguity about its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  Explicitly states when to use: 'when the user wants a new image from text, optionally with reference images for image-to-image generation.' It gives exclusions and alternatives: 'Do NOT use this for editing an existing image with specific source-image transformation instructions; use pollinations_edit_image instead.' It also advises calling pollinations_list_models first for current capabilities, and gives practical examples for common use cases.

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

• pollinations_generate_videoA
  5/5.0
  Behavior5/5

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

  The description extensively discloses behavior beyond annotations: error handling (401/402/403/429/400), model-specific parameter support (e.g., veo durations, seed support), audio behavior for veo/wan, aspect ratio derivation, resolution mapping, end-frame handling, and save_output side effects. No contradictions with annotations.

  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?

  Despite its length, the description is well-structured and information-dense. It front-loads core functionality, then systematically covers parameters, return values, examples, and error handling. Every sentence adds unique value, particularly model compatibility details that are not in the schema.

  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 complex tool with 15 parameters and no output schema, the description is exceptionally complete. It explains return values (Markdown/JSON with URL and metadata), error semantics, parameter constraints, and usage patterns. It fully equips an agent to invoke the tool correctly without needing external lookups.

  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 schema coverage is 100%, the description adds substantial meaning beyond the schema: model-specific duration rules, supported models for seed, end-frame semantics, quality tiers, and practical examples (veo duration=8, aspectRatio=9:16 for TikTok). It clarifies parameter interactions and defaults like save_output and response_format.

  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 'Generate a video from a text prompt using Pollinations video models' and references the specific endpoint GET /video/{prompt}. It also differentiates from the sibling tool by saying 'For static images, use pollinations_generate_image instead.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

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

  Explicitly states when to use: 'Use this when the user wants text-to-video or image-to-video output.' It gives an alternative tool for static images and even recommends calling pollinations_list_models first for current capabilities, providing both when-to-use and when-not-to-use guidance.

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