ipv4.fr Network Tools

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral value by stating the default record types resolved when types is omitted, but says nothing about failure behavior (NXDOMAIN, timeouts) or response shape.

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?

One compact sentence with zero filler, front-loaded with the resource and defaults. It loses a point only because the missing verb makes the opening slightly less immediately parseable.

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 two-parameter external lookup with no output schema, the description covers inputs but leaves the agent guessing at the return format and error cases. Adequate for invocation, thin for interpreting results.

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 50% — domain is documented in the schema but types is not — so the description must compensate. It does so well by enumerating the allowed record types and, crucially, explaining which are fetched by default, which the schema never states.

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 names the resource (DNS records for a domain) and the record types returned, which lets an agent distinguish it from whois or ssl_check. But it omits a verb entirely — it reads as a noun phrase, so the agent must infer that this performs a lookup rather than describing a domain's stored records.

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?

No guidance on when to use this over siblings like whois (registration data) or http_headers, despite obvious overlap in the 'investigate a domain' workflow. The default type set is mentioned but not framed as decision guidance (e.g., when to pass an explicit types array).

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully discloses that live MX/SMTP lookups and reputation heuristics occur, which is behavioral context beyond the annotations. It stops short of saying the SMTP check is a live network probe that may be blocked, slow, or inconclusive, and says nothing about what a failed validation returns.

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?

One sentence, front-loaded with the verb and resource, followed by the check list. No filler or restatement of the tool name.

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?

There is no output schema, so the description should convey the shape of the result — boolean verdict, per-check breakdown, reason codes — and it does not. For a validation tool whose value depends on how the verdict is reported, that leaves a meaningful gap, though the check enumeration does tell an agent what dimensions are evaluated.

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?

Single parameter with 100% schema coverage and a maxLength constraint already documented, so the schema carries the burden. The description only echoes "email address" and adds no format or normalization guidance (e.g., trimming, case handling). Baseline 3 applies.

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?

States a specific verb and resource ("Validate an email address") and then enumerates the exact checks performed: syntax, MX, SMTP, disposable, role-based. That enumeration distinguishes it cleanly from siblings like dns_lookup or whois, which cover only part of the same ground.

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 listed checks imply when the tool is appropriate (you need a deliverability/quality verdict on an address), so usage is inferable. But there is no explicit when-to-use/when-not statement, no mention of when a plain dns_lookup would suffice, and no prerequisites or caveats for the SMTP probe.

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?

Annotations already cover read-only and open-world safety, but the description adds real behavioral context: HEAD (no body fetch, lightweight), redirects are followed so the returned status is the final one, and the target must be a public URL. It stops short of saying what happens on unreachable hosts or whether it returns an error vs partial data.

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?

A single sentence that front-loads the returned resource and uses the parenthetical for the method and redirect behavior. Nothing is wasted or buried.

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 one-parameter read tool with no output schema, the description adequately covers what is retrieved and how. The remaining gaps — error behavior on unreachable hosts and the shape of the returned headers — are minor, though the latter would help since no output schema exists.

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 there is only one parameter, so the schema already carries the burden. The description adds the 'public' restriction, which is a meaningful constraint beyond the schema's 'URL or domain' example, but little else.

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?

Names a specific resource (HTTP response headers and status) and the method used (HEAD request), which is clearly distinct from siblings like dns_lookup, ssl_check, and whois. It never explicitly names an alternative, but the resource boundary is 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?

Usage is only implied: 'public URL' hints at a precondition (internal/private hosts presumably unsupported) and the resource implies you call it when you need status/header info. There is no explicit statement of when to prefer this over ssl_check or dns_lookup for a URL's health.

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?

readOnlyHint and openWorldHint already tell the agent this is a safe external read. The description usefully discloses exactly which three blacklists are queried, but says nothing about latency, rate limits, or that results depend on live third-party DNS zones.

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?

A single front-loaded sentence with no filler; the key scope (3 named blacklists) lands immediately.

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 read-only lookup this is mostly adequate, but with no output schema the description never says what comes back — e.g., per-list listed/unlisted status or an aggregate verdict — leaving the response shape undocumented.

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?

Only one parameter and schema coverage is 100%, with the schema already documenting 'IPv4 address'. The description's mention of IPv4 adds no format detail (e.g., no IPv6 support) beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb (Check), resource (IPv4 address) and scope (3 named DNS blacklists: Barracuda, SpamCop, UCEPROTECT). It is clearly not dns_lookup or ip_geolocation, though it never explicitly names siblings to differentiate.

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?

Usage is implied by the name and scope — use when you need a reputation/blocklist check on an IP. There is no explicit when-to-use vs. when-not, no mention of alternatives like ip_geolocation, and no stated preconditions.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the shape of the result set (country, city, ISP, coordinates, timezone), which is genuinely useful since there is no output schema, but it says nothing about accuracy limits, missing-field behavior, or failure modes for invalid IPs.

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?

One compact sentence with the resource first and the returned fields after; nothing is wasted. The telegraphic fragment style is efficient, though it omits an explicit verb.

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, read-only lookup with annotations and no output schema, the description covers the input domain and the returned field set, which is what an agent needs to call it. Only minor gaps remain around error behavior and data source freshness.

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 single parameter is documented as 'IPv4 or IPv6 address', so the schema carries the semantics. The description adds no format examples or edge-case notes beyond restating that the input is an IP address; baseline 3 applies.

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?

Names the specific resource (IP address) and enumerates the geolocation data returned (country, city, ISP, coordinates, timezone), which clearly separates it from siblings like dns_lookup, whois, and ip_blacklist. It lacks an explicit verb ('returns geolocation for...') and never names a sibling, so it stops short of 5.

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?

There is no guidance on when to choose this over whois or ip_blacklist, no statement of prerequisites (API key, rate limits), and no conditions for when-not to use it. The agent must infer the use case entirely from the field list.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe outbound network read. The description adds useful behavioral value by listing what is returned (validity, issuer, expiry, days remaining, SAN) in the absence of an output schema. It does not disclose what happens when the certificate is invalid, self-signed, or the host is unreachable, which matters for a network probe.

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?

A single compact fragment with zero filler, front-loaded with the resource and followed by the returned fields. It is terse to the point of being telegraphic, but nothing in it 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?

For a two-parameter network probe with no output schema, the description does cover the return contents, which is the main gap-filler. However, it omits port defaulting, failure semantics (bad/expired cert, connection refused), and any expectation of latency, so an agent cannot fully predict behavior.

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 only 50%: host is documented in the schema ('Hostname or public IP'), but port has no description anywhere. The description adds no parameter detail at all, so the common question of what port defaults to (443) and whether a non-standard port is supported is left unanswered. With low coverage the description should have compensated and does not.

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 names a specific resource (the TLS certificate of a host) and enumerates the exact facts it surfaces: validity, issuer, expiry, days remaining, SAN. That is enough to distinguish it from siblings like dns_lookup or whois. It is a noun phrase rather than a verb, but the resource and output are concrete.

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?

There is no guidance on when to reach for this tool versus dns_lookup, whois, or http_headers, and no mention of prerequisites or exclusions. The only implicit cue is that it is certificate-focused, leaving the agent to infer the use case.

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?

Annotations already declare readOnlyHint=true, so safety is covered; the description adds real value by naming exactly which values come back, which matters because there is no output schema. The only gap is that it doesn't say what happens on malformed or out-of-range CIDR input.

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?

One front-loaded sentence, dense with the exact output fields and zero filler. Nothing to trim and nothing buried.

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 one-parameter pure calculator with no output schema, listing the returned fields covers the main completeness need. It falls short only on input-validation behavior and the IPv4-only scope, which an agent might otherwise assume includes IPv6.

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?

Single parameter with 100% schema coverage including an example ('192.168.1.0/24'), so the schema does the work. The phrase 'from CIDR' in the description adds nothing beyond the schema's own example, which is baseline-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?

States a specific verb+resource ('IPv4 subnet calculator') and immediately enumerates the computed outputs (network, broadcast, netmask, wildcard, host range, host count). No sibling tool in the list does subnet math, so there is zero ambiguity about which tool to pick.

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?

Usage is implied by the name and the 'from CIDR' framing, and no sibling overlaps, but the description never states when to reach for this versus e.g. ip_geolocation or dns_lookup, nor any exclusions (IPv6 is silently out of scope). The agent must infer the boundary.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds value by disclosing the returned data categories, but omits well-known WHOIS behaviors: rate limiting, privacy-redacted fields, and the no-record case for unregistered or restricted TLDs — all of which materially affect result interpretation.

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?

One sentence, front-loaded with the resource and immediately followed by the concrete payload contents. Nothing superfluous and nothing buried.

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 read-only lookup with no output schema, the description usefully substitutes for one by listing the fields returned, and annotations cover the safety profile. It falls short only on expected edge behaviors (no record found, redacted data, rate limits), which are the main open questions for an open-world lookup.

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% with a single required 'domain' parameter documented with an example, so the description need not explain it. The description adds no syntax guidance (e.g. whether a scheme, subdomain, or IDN is acceptable), leaving baseline 3 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?

States a specific resource (WHOIS registration data) and enumerates the concrete fields returned: registrar, creation/expiry dates, name servers. It doesn't name or distinguish itself from the domain-shaped siblings like dns_lookup and ssl_check, but the resource noun ('WHOIS registration data') is distinctive enough for an agent to identify it.

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?

Usage is implied rather than stated: an agent infers 'use this to get domain registration/ownership info.' There is no explicit when-to-use, no exclusion, and no routing advice versus dns_lookup or ssl_check, which also take a domain — a plausible confusion point left unaddressed.

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