HackMyIP — no-key IP intelligence

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

With no annotations, the description carries the full burden. It discloses the output fields (AS number, network name, holder, description, RIR, announced status) and implies a read-only lookup. It does not explicitly state side effects or permissions, but the nature of a lookup is well conveyed.

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

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

Two concise sentences. The first states the function and outputs; the second gives concrete use cases. No filler words, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description lists all essential return fields. The examples cover the three query types. For a single-parameter lookup tool, this description is complete and self-sufficient.

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

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

Schema coverage is 100% and the parameter description already explains the accepted formats (IP, ASN, org name). The description adds example queries but no additional semantic context beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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: 'Resolve an Autonomous System by IP address, AS number, or organization name.' It clearly distinguishes this tool from siblings like ip_lookup or whois_domain by focusing on AS-level data and the specific output fields. No ambiguity about what the tool does.

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

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

Explicit usage examples are provided: 'which network is this IP on', 'who is AS15169', 'find the ASNs belonging to a company.' This clearly signals when to use the tool. It does not name alternative tools or mention when not to use it, so it falls just short of a 5.

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

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 goes beyond a simple mutation statement by revealing performance characteristics (much faster, kinder to rate limits), the batch limit of 50, and the returned data fields. It does not mention error handling for invalid IPs, but for a lookup tool this is sufficient.

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

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

The description is two sentences, front-loaded with the primary action, then adds rationale and examples. Every sentence earns its place with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward lookup tool with one parameter and no output schema, the description covers the purpose, the input format, the use cases, and the return fields. It is complete enough for an agent to select and invoke the tool correctly without ambiguity.

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

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

The schema fully describes the single 'ips' parameter with a clear description ('Array of 1-50 public IPv4/IPv6 addresses'), so the description does not need to add more. The description implicitly references the parameter but adds no additional semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool looks up country, city, ISP, organization, and coordinates for up to 50 IP addresses in a single request. It uses a specific verb ('look up') and resource ('IP addresses'), and distinguishes itself from the sibling tool 'ip_lookup' by explicitly mentioning batching.

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

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

The description explicitly says to prefer this tool over ip_lookup when handling more than a couple of addresses, and provides concrete use cases like access logs or firewall exports. It also explains performance and rate-limit benefits, making the decision of when to use it versus alternatives clear.

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

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

No annotations exist, so the description carries the burden. It discloses the 'live' and 'public resolvers' behavioral traits, and the verb 'query' implies a non-destructive read operation. It could explicitly state that no changes are made or discuss rate limits, but the essentials are covered.

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

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

The description is two sentences, front-loaded with the core function and then supported details. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not explain return values or error conditions, but for a read-only DNS lookup with well-defined input parameters, the description covers the tool's purpose, supported types, and common use cases sufficiently.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by linking record types to real-world checks (e.g., MX/SPF/DKIM/DMARC TXT records, nameserver delegation), enriching what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: 'Query live DNS records for a domain over public resolvers.' It lists all supported record types and provides concrete use cases, clearly distinguishing it from siblings like reverse_dns or whois_domain.

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

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

The description provides explicit use cases: 'verify a deployment's DNS, inspect MX/SPF/DKIM/DMARC TXT records, check nameserver delegation, or confirm propagation after a change.' It does not explicitly mention when not to use it or alternatives, but the context is clear.

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

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

With no annotations provided, the description carries the full burden. It discloses the output format (verdicts and overall grade) and what mechanisms are checked, but does not mention live DNS behavior, rate limits, permissions, or edge cases. It is adequate but not deeply transparent about operational details.

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

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

The description is two sentences: the first states the tool's function and outputs, the second lists concrete use cases. It is front-loaded and every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema). The description covers the purpose, the items inspected, the output verdict format, and intended scenarios. It lacks details on error cases or live lookup behavior, but for a straightforward audit tool, this is reasonably complete.

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

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

Schema coverage is 100% because the only parameter, 'domain', has a description with an example. The tool description adds minimal semantic value beyond the schema, as it only implies the domain is used for email auth checks. This matches the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool audits a domain's email authentication setup, specifically MX, SPF, and DMARC, and provides pass/warn/fail verdicts with an overall grade. This is a specific verb+resource, and it distinguishes itself from sibling tools like dns_lookup and email_breach_check.

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

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

The description gives explicit use cases: diagnosing deliverability, hardening against spoofing, and reviewing vendor email posture. It does not state when not to use it or mention alternative tools, but the provided context is clear and actionable.

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

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

With no annotations provided, the description carries the full burden. It discloses return behavior (number of breaches and involved services) and privacy handling (address partially masked). This is meaningful behavioral context, though it does not cover all aspects like rate limits or error states.

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

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

The description is three sentences long, front-loads the core action, and every sentence earns its place: what it does, what it returns, positioning, and privacy note. No redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter lookup tool, the description covers the key aspects: purpose, return values, data source, and masking. It doesn't enumerate failure modes or response structures, but given no output schema and low complexity, it is adequately complete, just missing a few edge-case details.

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

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

Schema description coverage is 100% for the single 'email' parameter, including an example. The description adds no extra parameter details, so the baseline of 3 applies. It doesn't compensate further but doesn't need to given the schema is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Check whether an email address appears in known data breaches, using the XposedOrNot breach database.' This provides a specific verb, resource, and context, and it distinguishes the tool from siblings like email_auth_check by focusing on breach data.

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

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

The description gives clear context for use—checking an email against known breaches—and positions it as a 'free alternative to paid breach-lookup APIs.' However, it does not explicitly state when not to use it or contrast it with sibling tools (e.g., email_auth_check), so it lacks explicit alternatives or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: lists refusing public queries are reported as 'unavailable' rather than falsely clean, and warns to read total_checked alongside listed_count. This is valuable transparency beyond a basic flag check.

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

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

The description is two sentences, front-loaded with the action and scope, then providing usage guidance and a critical caveat. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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, the description provides adequate context: the use case, the blacklist count, the breakdown format, and a caution about interpreting results. It could further clarify the exact output structure, but the essentials are covered.

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

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

Schema coverage is 100% for the single 'ip' parameter, with a clear description and pattern. The tool description adds the context that DNSBLs are IPv4-only and the purpose, but this mostly reinforces the schema without adding new semantic detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Check') and resource ('IPv4 address against 12 major spam and abuse blacklists'), listing example blacklists and the per-list breakdown. This clearly distinguishes it from sibling tools like ip_lookup or vpn_proxy_check.

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

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

The description gives an explicit use case: 'Run this before sending bulk email from a new IP, or when mail is being rejected.' This provides clear context for when to use the tool, though it does not mention alternatives or when not to use it.

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

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

With no annotations, the description carries the transparency burden. It discloses that the tool only works for public addresses and lists exactly what data it returns, providing insight into expected behavior. It does not mention potential errors or rate limits, but for a simple lookup tool this is sufficient.

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

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

The description is two sentences, each earning its place: the first specifies the exact data returned, and the second provides use cases. It is front-loaded, with the primary action and object in the first sentence, and contains no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a single-parameter tool with no output schema, the description is complete: it explains what the tool does, what data it returns, and when to use it. The lack of an output schema is compensated by enumerating the return fields clearly.

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

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

The schema already fully describes the 'ip' parameter with a pattern and example, and the description adds little beyond the schema. Since schema coverage is 100%, a baseline of 3 applies, and the description does not provide additional parameter semantics beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool performs a lookup of geolocation data (city, region, country, lat/lon, timezone, postal code) plus ISP, ASN, organization, and AS name for public IPv4/IPv6 addresses. It also positions itself as the 'workhorse tool' for IP-related questions, clearly distinguishing it from more specialized siblings like asn_lookup or dns_lookup.

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

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

The description gives clear context for when to use the tool: triaging log entries, identifying IP ownership, or answering 'where is this IP'. It does not explicitly mention alternatives, but the 'workhorse' phrasing implies it is the default choice, and no exclusions are needed for a basic lookup tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It provides valuable context about the IP being the egress IP of the MCP request and the caveat about corporate proxies/remote hosts. It does not mention any potential rate limits or data sources, but for a simple read-only lookup, the transparency is adequate.

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

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

The description is three sentences, each serving a distinct purpose: stating the core function, listing use cases, and explaining an important edge case. There is no wasted wording, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description covers all essential aspects: what it returns (enriched IP details), when to use it, and the proxy caveat. It is sufficiently complete for an AI agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, and the schema coverage is trivially 100%. The description correctly adds no parameter documentation because there are none, aligning with the baseline score of 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Get the public IP address of the machine that opened this MCP connection', clearly distinguishing it from sibling tools like ip_lookup or bulk_ip_lookup. It also lists the enrichment data (city/country, coordinates, timezone, ISP, ASN, hosting/proxy classification), making its scope unmistakable.

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

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

The description explicitly states when to use the tool: for 'what is my IP', 'where does the internet think I am', or a quick VPN sanity check. It does not explicitly mention when not to use it or name alternatives, but the use cases are clearly scoped, so this is 'clear context' without exclusions.

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

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

With no annotations, the description fully takes on the transparency burden. It discloses the real TCP connect nature, each result state with meaning, the default catalog behavior, address restrictions, authorization requirements, rate limits, and expected duration. This is rich behavioral disclosure beyond mere intent.

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

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

The description is three sentences, each earning its place: the first states the core action, the second explains result categories and default behavior, the third covers restrictions and operational limits. It is front-loaded with the main verb and resource, and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 what results the user will see (open/closed/filtered/blocked) and the meaning of each. It also addresses constraints, rate limiting, and duration, making the tool's behavior fully understood without needing extra documentation.

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

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

Schema coverage is 100%, so both parameters are already described. The description adds value by explaining the default behavior when the optional `ports` parameter is omitted ('curated common-port catalog is scanned') and by emphasizing the public host requirement, reinforcing the schema's 'do not scan third parties' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Run a real server-side TCP connect scan against a public host.' It also distinguishes itself from sibling network tools by focusing on port scanning and describing the possible port states (open, closed, filtered, blocked).

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

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

The description provides clear context on when to use the tool: it scans public hosts and has a default port catalog when no ports argument is given. It also gives an important exclusion ('Private, reserved and internal addresses are rejected') and a caution about authorization. It does not explicitly name alternative tools, but the sibling list makes the tool's unique purpose clear.

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

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

With no annotations, the description carries the full burden. It explains the core behavior (reverse resolving an IP to a PTR hostname) and mentions IPv4/IPv6 support, but it does not disclose edge-case behavior such as what happens when no PTR record exists, error conditions, or rate limits. This is adequate but not exhaustive for a simple read-only lookup.

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

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

The description is two sentences: the first states the core function, the second lists use cases. It is front-loaded with the action and contains no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema) and the description covers its purpose, supported IP types, and practical use cases. It lacks an explicit statement about the return value on failure, but overall the context is sufficient 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.

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

The schema covers the sole parameter with a clear description and a pattern. The tool description restates that it works for IPv4 or IPv6 but adds no additional semantic detail beyond the schema. With 100% schema coverage, baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states precisely that the tool 'Get[s] the PTR hostname' for an IPv4 or IPv6 address. This clearly identifies the verb and resource and distinguishes it from sibling tools like dns_lookup (forward DNS) and ip_lookup (IP metadata).

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

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

The description provides specific use cases ('identifying mail servers, confirming that a crawler really belongs to the bot it claims to be, or adding a human-readable name to a raw log IP'), which gives clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the rate limit (20 requests/minute) and the return format ('actual header value and an explanation'). However, it does not specify behaviors like redirect handling, error responses, or whether the fetch is raw or browser-like. This is acceptable but not richly transparent.

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

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

The description is two sentences and information-dense. The first sentence details the purpose and specific headers, while the second adds usage and rate-limit context. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no output schema, and no annotations, the description covers purpose, specific checks, return value details, usage intention, and rate limit. It would be more complete if it mentioned edge-case behavior like redirects or timeouts, but it is sufficiently complete for a simple audit tool.

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

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

The input schema already provides 100% coverage for the single parameter 'url', including a description and example. The tool description does not add additional parameter-level semantics beyond what the schema states, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Fetch a site and grade its HTTP security headers (A-F)'. It lists the specific headers checked (CSP, HSTS, etc.), distinguishing it from sibling tools like site_status_check or dns_lookup. The verb 'grade' and resource 'HTTP security headers' are specific and unambiguous.

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

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

The description provides clear usage context: 'Use it for a quick security review of your own site or a third party's.' This indicates when the tool is appropriate, but it does not explicitly mention alternatives or when not to use it. Thus it falls short of a 5 but is stronger than a 3.

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

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

With no annotations provided, the description fully carries the burden of disclosure. It reveals key behavioral traits: the tool is free, requires no API key/signup/auth, has a fair-use rate limit, and provides a tool list and links. This goes beyond the minimum and gives the agent clear expectations of what the tool offers.

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

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

The description is a single sentence that packs in a lot of information. It is structured as a list of expected content items, which is efficient. It could be slightly shorter, but every clause adds value, so the density is justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, no output schema), the description is complete. It covers what the tool does, when to use it, and what information it will return. The sibling context is irrelevant since this is the only informational tool, and the description fully prepares the agent.

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

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

This tool has zero parameters, so the baseline is 4. The description needs to explain no parameters and instead focuses on the output content, which it does effectively. It adds no parameter-specific meaning because none exist, but the baseline score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to describe the MCP server, including what it wraps, pricing, auth, rate limits, tool list, and links. This is distinct from sibling tools, which are specific lookup/scan operations, making the purpose unambiguous.

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

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

The description explicitly says when to call this tool: when the user asks what the server can do, whether it costs anything, or where the data comes from. This provides clear usage guidance and implicitly distinguishes it from the other data-focused sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the check is from Cloudflare's network (not local), lists the return fields (up/down boolean, HTTP status, response time, headers), and implies a read-only, non-destructive operation. This is substantial behavioral context.

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

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

The description is two sentences: the first states the action and return values, the second gives use cases. Every sentence earns its place; no jargon or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple tool with one parameter, no output schema, and no annotations. The description fully covers what the tool does, what it returns, and when to use it. It is complete for the given complexity.

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

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

Schema coverage is 100% (the single 'url' parameter is fully described). The description does not add parameter-specific details beyond the schema, but the schema already provides sufficient meaning, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks site reachability from Cloudflare's network, with a specific verb ('Check'), resource ('site'), and scope. It distinguishes itself from siblings by focusing on up/down status and HTTP-level details, which no other listed tool directly covers.

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

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

Explicit use cases are provided: confirming an outage is real versus local, and verifying a deployment is serving. It does not name alternative tools, but the guidance is clear enough for an agent to know when to invoke this tool.

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

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

No annotations are provided, so the description carries the full transparency burden. It discloses the classification output, geolocation/network owner inclusion, and the behavior when `ip` is omitted. It does not explicitly mention read-only/non-destructive nature, but that is implied by the lookup verb. It adds useful context beyond the schema, though it omits rate limits or external API dependencies which are not critical.

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

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

Two concise sentences: the first states the core purpose and outputs, the second provides use cases and the default parameter behavior. No redundancy, fully front-loaded, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a single-parameter lookup with no output schema, but the description covers the essential context: what classification categories are returned, the additional fields (geolocation, network owner), use cases, and the default behavior. This is complete for a simple IP-classification tool.

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

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

With 100% schema coverage, the parameter is already well-documented. The description adds value by rephrasing the default behavior ('Omit `ip` to check the connection this MCP request came from') in a more operational way, reinforcing when to omit the parameter. This elevates it beyond the schema baseline of 3 to a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Classify') and resource ('an IP'), and enumerates classification categories (hosting/datacenter, open proxy, mobile-carrier) plus geolocation and network owner. This distinguishes it from sibling tools like ip_lookup or asn_lookup by focusing on traffic classification rather than generic IP details.

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

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

The description provides clear context for when to use the tool: 'Use it to decide whether traffic is likely a VPN, a cloud server or a real residential/mobile user — for fraud triage, abuse review, or checking whether your own VPN is being detected.' While alternatives are not explicitly named, the use cases are concrete and differentiate from simple IP lookups. It lacks explicit exclusions (e.g., 'use ip_lookup for general details'), hence not a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses that RDAP is a third-party registry service, can be temporarily unavailable, and that a failure is upstream rather than caused by a bad query. This adds meaningful behavioral context beyond 'lookup' and indicates a read-only operation.

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

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

The description is two sentences that front-load the result data, provide short use-case phrases, and include a caveat. Every clause earns its place with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool with no output schema, the description is complete: it lists the returned data categories, gives usage scenarios, and explains failure behavior. One parameter makes complexity low, and the description covers all essential aspects.

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

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

The input schema has 100% visibility: the domain parameter is described with a pattern, length constraints, and an example. The description doesn't add meaning beyond the schema, but it doesn't need to. Baseline 3 applies because schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Fetch registration data for a domain via RDAP,' and enumerates concrete fields (registrar, dates, nameservers, EPP status codes). This clearly distinguishes the tool from siblings like dns_lookup or asn_lookup, which query different types of data.

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

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

The description provides explicit use cases: 'check domain age (a common trust signal), see when a domain expires, or find who it is registered through.' It does not name alternative tools or state when not to use it, but the context is clear enough given the sibling list.

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