Server Quality Checklist

Tool Scores

• bulk_lookup_ipA
  4.4/5.0
  Behavior5/5

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

  Adds significant behavioral context beyond annotations: billing rules (not billed for private/bogon IPs), auto-inference of include modules, behavior of fields/excludes/lang similar to lookup_ip, and caching behavior of force_refresh. No contradiction with readOnlyHint or openWorldHint.

  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?

  Organized into three paragraphs with front-loaded key info (read-only, paid, limits). Could be slightly more concise, but each sentence adds unique value. No redundant or vague sentences.

  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?

  Covers billing, limits, parameter interactions, and alternative tool. Lacks detailed return format (no output schema) and only vaguely describes response as 'location data or mixed IP data domains'. Adequate but gaps remain.

  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 covers descriptions for all 6 parameters (100% coverage). Description adds extra semantics: auto-inference of include from fields, credit costs for include options, default lang, and force_refresh caching effect. Adds value 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?

  Specifies 'Read-only bulk IP lookup' with verb and resource, distinguishes from sibling lookup_ip (single IP), and mentions HTTP method and credit costs. Clearly states what the tool does and sets expectations for bulk usage.

  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?

  Provides context on paid nature, credit costs, and limits (up to 1,000 IPs). Mentions alternative tool bulk_security_check for security-only. However, does not explicitly contrast with single IP lookup (lookup_ip) or specify when not to use.

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

• get_my_ipA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint; description adds that no auth or credits are needed and that response is a plain IP string (not geolocation), adding useful context without contradiction.

  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, front-loaded with purpose, then usage and comparison. Every sentence adds value with no wasted words.

  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 parameters, no output schema, and simple functionality, the description fully covers purpose, usage, and differentiation from siblings.

  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?

  With zero parameters and 100% schema coverage, the description confirms no inputs, which is sufficient; no additional semantics needed.

  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 returns the public IP address of the machine running the MCP server, specifies the endpoint GET /v3/getip, and distinguishes itself from sibling tool lookup_ip by contrasting the response type.

  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 it takes no input parameters, requires no API key/account/credits, and contrasts with lookup_ip for geolocation data, providing clear 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.

• lookup_ipA
  4.7/5.0
  Behavior5/5

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

  Adds substantial behavioral context beyond annotations: credit costs per module, plan restrictions, auto-adds include modules, fields/excludes handling, force_refresh bypasses cache, ip always returned, unknown excludes do not error. Annotations only state readOnlyHint and openWorldHint, so description enriches understanding.

  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?

  Description is detailed and somewhat lengthy with multiple paragraphs. While it front-loads the essential purpose and cost structure, some details could be more compact. Still, every sentence adds necessary information for a complex tool.

  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 adequately explains return values (root data plus selected objects) and lists possible fields. It covers credit costs, plan restrictions, parameter interactions, and default behaviors. The tool is complex, but the description is comprehensive.

  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 covers all 6 parameters with descriptions (100% coverage), but description adds significant value: credit costs for include modules, plan restrictions (free vs paid), auto-add behavior for fields, default for ip (caller's IP), and interaction between fields/excludes and include. This justifies a score above baseline 3.

  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?

  Clearly states it is a read-only unified IP lookup via GET /v3/ipgeo. Distinguishes from siblings like lookup_company, bulk_lookup_ip, get_my_ip, lookup_currency by focusing on IP geolocation and mentioning alternatives for ASN, security, and abuse.

  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 (IP geolocation, credit costs, plan limitations) and when not to use (mentions lookup_asn, check_security, get_abuse_contact as alternatives for specific purposes). Also explains default behavior (omit ip for caller's IP).

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

• lookup_currencyA
  4.8/5.0
  Behavior5/5

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

  Discloses HTTP method, credit cost, caching behavior, and response structure (currency and country_metadata). Annotations already declare readOnly and openWorld, but description adds operational details beyond that.

  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?

  Description is clear and front-loaded with purpose, but could be slightly more concise. Some redundancy in explaining force_refresh credit consumption, but overall well-structured.

  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 no output schema, the description adequately explains returned fields and behavior under different parameter usage. Also references sibling tools, providing complete context for an agent.

  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 coverage is 100% with descriptions, so baseline is 3. The description adds context: ip selects the IP used to derive country and currency, force_refresh bypasses cached data and can consume credits. This extra value warrants a 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 is a read-only lookup for currency and country metadata via GET /v3/ipgeo. It distinguishes from sibling tool lookup_ip by noting that lookup_ip returns these fields plus other IP data.

  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 guidance: works on free/paid plans, costs 1 credit per lookup, when to omit ip for caller IP, when to use force_refresh, and contrasts with lookup_ip for broader data needs.

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

• lookup_companyA
  4.9/5.0
  Behavior5/5

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

  Consistent with readOnlyHint = true. Discloses cost, credit consumption, data caching behavior, and the effect of force_refresh. All behavioral traits are transparently described.

  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?

  Concise at about 5 sentences, front-loaded with purpose, then usage, then return format. Every sentence adds value without redundancy.

  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?

  Covers purpose, parameters, return structure (company, asn), cost, alternatives, and caching. No missing information for this simple 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?

  Adds context beyond the schema, e.g., 'ip omitted means caller IP' and explains force_refresh behavior. Schema already describes both parameters well, but the description provides useful additional usage detail.

  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?

  Clearly states 'Read-only ownership lookup via GET /v3/ipgeo' and specifies the limited scope to company and ASN ownership, distinguishing it from the sibling lookup_ip which returns more fields.

  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 mentions 'Paid only. Cost: 1 credit' and explains when to use force_refresh. Contrasts with lookup_ip, providing guidance on when to choose this tool over alternatives.

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