A
licenseNot graded
qualityB
maintenanceProvides IP address utilities including parsing and classification of IPv4/IPv6 addresses and CIDR block information.
11 npm
MIT
Packetrove
Server Details
Open-source IP address and CIDR tools for network calculations and public IP lookup.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 23 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- euyuil/packetrove
- GitHub Stars
- 0
TDQS
A4.5/5.0
Scored across 6 tools
Disambiguation4/5
Each tool targets a clearly distinct operation: certificate parsing, CIDR covering, CIDR subtraction, range expansion, connection IP reflection, and feedback submission. The three CIDR/IP tools are the only possible point of confusion at a glance, but their descriptions sharply separate one-covering-CIDR (cidr-cover) from minimal CIDR decomposition (range-to-cidrs) and set difference (cidr-subtract).
Naming Consistency4/5
All names use consistent lowercase kebab-case, which keeps the set visually coherent. The structural pattern is slightly mixed—most are noun-oriented (certificate-bundle, cidr-cover, public-ip) while submit-feedback is verb-first—but the casing convention is uniform, so this is a minor deviation rather than a real inconsistency.
Tool Count5/5
Six tools sits comfortably in the well-scoped 3–15 range, and each tool covers a distinct capability rather than duplicating another. No tool feels redundant or trivially padded for the stated utility-server purpose.
Completeness4/5
The CIDR/IP surface is reasonably complete (cover, subtract, range expansion, connection IP), and feedback submission covers the interaction path. Minor gaps exist—no explicit CIDR-to-range reverse, membership/contains check, or intersection primitive—but agents can work around these via the provided operations.
Available Tools
6 toolscertificate-bundleCertificate Bundle CheckerARead-onlyIdempotentInspect
Use to inspect a supplied PEM certificate bundle before TLS configuration. Accept pem with 1–16 CERTIFICATE blocks and at most 49152 UTF-8 bytes, optional ASCII DNS hostname, and optional zero-based leafIndex. Reject private keys and unsupported blocks without echoing them. Return original certificate positions, Subject, Issuer, Common Name, SANs, validity, CA and Key Usage flags, SHA-256 fingerprints, independently checked candidate links, explicit leaf ambiguity, and stable findings with severity, observed evidence, and nextAction. Verify signatures cryptographically; name matching alone is not verification. Missing selected-leaf issuers and blocked requested hostname checks are warnings; other missing issuers are informational because roots are commonly omitted. All explicitly rejected supplied issuer candidates for the selected leaf produce an error. Unknown checks and key-identifier mismatches alone do not produce that error. A failed candidate does not invalidate another viable link. Verified self-issued CA key rollover is informational; verification with the certificate's own public key remains separate. Hostname checks use DNS SAN with one-label complete leftmost wildcards and no Common Name fallback. Results use this server's evaluation time and do not establish client trust, full RFC 5280 path validity, revocation status, or deployment safety. This remote call transmits certificates and hostname to the server; the website checks locally. Certificate input and details never enter application logs. Do not submit private keys. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| pem | Yes | One or more PEM CERTIFICATE blocks, with only whitespace between blocks. At most 48 KiB of UTF-8 and 16 blocks. Private keys and other block types are rejected. | |
| hostname | No | Optional ASCII DNS hostname, including pre-converted IDNA A-labels. No URL, port, IP address, or wildcard. Blank skips identity checking. | |
| leafIndex | No | Zero-based original position of a non-CA certificate. Required to resolve multiple possible leaves for hostname checking. |
Output Schema
| Name | Required | Description |
|---|---|---|
| findings | Yes | |
| hostname | Yes | |
| evaluatedAt | Yes | Evaluation time from this runtime clock, not a deployment observation. |
| leafIndexes | Yes | First occurrences of distinct non-CA certificates; these are possible leaves, not a verified deployment selection. |
| certificates | Yes | |
| relationships | Yes | |
| selectedLeafIndex | Yes |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond that: private keys and unsupported blocks are rejected without echoing, signature verification is cryptographic (name matching alone is not verification), and the warning/error semantics for missing issuers, blocked hostname checks, and rejected issuer candidates are spelled out. It also discloses what the result does NOT establish (client trust, RFC 5280 path validity, revocation, deployment safety), which is rare and valuable.
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?
The purpose and input rules are correctly front-loaded, but the paragraph is a dense wall that mixes invocation-critical rules with operational boilerplate (event fields, automation run identifiers, Cloudflare metadata, privacy policy URL) that an agent does not use when calling the tool. There is also redundancy, e.g. 'Reject private keys' restated as 'Do not submit private keys'. Correctly sized content is padded by material that does not earn its place.
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 high-complexity validation tool, the description covers everything needed to invoke it correctly: input block constraints, leaf disambiguation, hostname matching rules, and the full warning-vs-error decision surface. An output schema exists, so the description is not obligated to explain return values, and the extra detail it does give about findings and nextAction is incidental rather than a gap.
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%, so the baseline is 3, but the description adds real meaning: pem blocks are constrained to 1–16 blocks / 49152 UTF-8 bytes, hostname is ASCII DNS with IDNA A-labels and no URL/port/IP/wildcard, and leafIndex is tied to resolving multiple possible leaves for hostname checking. The hostname wildcard matching rule (one-label complete leftmost, no Common Name fallback) is semantics the schema does not carry.
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 concrete verb and resource: inspect a supplied PEM certificate bundle before TLS configuration. It is unmistakably distinct from the CIDR/IP networking siblings, and the scope (certificate blocks, hostname check, leaf selection) is stated up front rather than buried.
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?
It gives clear deployment context ('before TLS configuration') and implies the alternative path by noting 'the website checks locally'. It does not, however, state an explicit when-not condition or name an alternative tool the agent should prefer in any scenario, so it stops 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.
cidr-coverSmallest Covering CIDRARead-onlyIdempotentInspect
Use when combining a selected group of firewall allowlist or blocklist entries into one smallest covering CIDR, or when checking the exact extra coverage. Accept 1 to 1,000 IP addresses or CIDRs from one address family, up to 64 characters each; normalize host bits and count overlaps once. Return the canonical CIDR, inclusive range, and exact decimal-string counts, including additionalAddressCount. The range may allow or block additional addresses. This computes one CIDR for the supplied inputs; it does not optimize an entire list against an entry limit or change firewall rules. Remote MCP calls submit inputs to this server; the calculation makes no outbound network requests. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | IP addresses or CIDRs from one address family. Surrounding whitespace is ignored during parsing; CIDRs with host bits are normalized. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cidr | Yes | The smallest single canonical CIDR containing every input address. |
| range | Yes | |
| family | Yes | |
| normalizedInputs | Yes | Canonical CIDRs in input order. Individual addresses become /32 or /128. Duplicates are retained here. |
| inputAddressCount | Yes | Number of distinct addresses in the union of the inputs. |
| coveredAddressCount | Yes | Number of all addresses in the resulting CIDR. |
| additionalAddressCount | Yes | Covered address count minus input address count. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds genuinely useful behavior: host-bit normalization, de-duplicated overlap counting, that the covering range may allow/block extra addresses, remote submission with no outbound network requests, and event-logging contents with exclusions. Some of this is telemetry boilerplate, but it is disclosure beyond the structured fields.
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?
The operational guidance is front-loaded and earns its place, but roughly half the text is privacy/telemetry detail (event fields, exclusions, platform metadata, privacy URL) that does not help an agent decide to call the tool. Appropriate in size overall, diluted by boilerplate.
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?
An output schema exists, yet the description still frames the return (canonical CIDR, inclusive range, exact counts) at a high level while covering input limits, family constraint, and the extra-coverage caveat. Nothing needed to invoke correctly is missing.
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% so the baseline is 3, but the description adds semantics the schema does not: 'one address family,' 'count overlaps once,' and the normalization/extra-coverage consequence. It reinforces rather than adds new constraints to the 1,000/64 bounds already in the 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?
States a specific verb and resource: 'combining a selected group of firewall allowlist or blocklist entries into one smallest covering CIDR.' It further scopes itself ('This computes one CIDR for the supplied inputs; it does not optimize an entire list against an entry limit'), which distinguishes it from siblings like range-to-cidrs and cidr-subtract.
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?
Explicit when-to-use ('when combining a selected group... or when checking the exact extra coverage') and when-not ('does not optimize an entire list against an entry limit or change firewall rules'). The agent can select this over siblings without reading their schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cidr-subtractCIDR SubtractionARead-onlyIdempotentInspect
Use to prepare WireGuard AllowedIPs exceptions or calculate remaining address space relative to supplied include and exclude lists. Compute union(include) minus union(exclude) as a minimal sorted canonical CIDR list, without adding addresses. Use one address family, a nonempty include list, and at most 1000 entries across both lists, up to 64 characters each. Exclude may be empty. Normalize host bits and count overlaps once. Return cidrs, normalizedInclude, normalizedExclude, and exact decimal-string includedAddressCount, removedAddressCount, remainingAddressCount. Complete removal returns an empty list; more than 10000 output CIDRs returns an error without a partial result. Error issues identify include or exclude and the zero-based entry index. Remote calls submit inputs to this server; the browser calculates locally. This does not inspect live allocation, configure WireGuard, or change firewall rules. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| exclude | Yes | Ranges to remove from the included address space. An empty array simplifies the exact include union. | |
| include | Yes | The nonempty included address space. Use at most 1,000 entries across include and exclude, from one address family. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cidrs | Yes | |
| family | Yes | |
| normalizedExclude | Yes | |
| normalizedInclude | Yes | |
| removedAddressCount | Yes | Exact number of addresses as a base-10 string, including network and broadcast addresses. |
| includedAddressCount | Yes | Exact number of addresses as a base-10 string, including network and broadcast addresses. |
| remainingAddressCount | Yes | Exact number of addresses as a base-10 string, including network and broadcast addresses. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-schema behavior: normalization of host bits, overlap counted once, the >10000 output CIDRs hard error with no partial result, error payloads identifying list and zero-based index, remote-vs-browser execution, and telemetry/privacy disclosure with exclusions about what is not logged.
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?
Purpose and constraints are front-loaded, which is good, but the definition runs long and the tail paragraphs on operational events and privacy policy are verbose relative to their value for tool selection. Information density is high but structure is closer to a compliance statement than a tight tool description.
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?
An output schema exists, yet the description still enumerates the returned fields and the empty-list success case and the error case, alongside all input constraints. For a pure computation tool with two array params, nothing an agent needs to invoke it correctly is missing.
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 description coverage is 100%, so the baseline is 3; the description then adds cross-parameter constraints the schema cannot express — one address family across both lists, a combined 1000-entry budget, 64-character limit, exclude allowed to be empty, include required nonempty, and the semantic consequence that an empty exclude simplifies the exact union.
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?
States a precise operation as a formula — 'Compute union(include) minus union(exclude) as a minimal sorted canonical CIDR list, without adding addresses' — plus a concrete use case (WireGuard AllowedIPs exceptions). The phrase 'without adding addresses' implicitly separates it from aggregating siblings like cidr-cover, and the explicit non-goals ('does not inspect live allocation... change firewall rules') further bound what the tool is.
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?
Gives clear triggering contexts (prepare WireGuard AllowedIPs exceptions, calculate remaining address space) and explicit when-not-to-use cases. It does not name any sibling tool (cidr-cover, range-to-cidrs, public-ip) or state which to pick instead, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
public-ipCurrent Public IPARead-onlyIdempotentInspect
Use to inspect the public IPv4 or IPv6 address observed for the connection making this MCP tool call. Takes an empty object and returns ip and family. This is the MCP client connection: a hosted AI client may observe its own exit address, not the user device address. If the user needs their browser or computer connection, direct them to the web tool or a CLI running on that machine. A VPN or proxy changes the observed path. One call observes one address family; it does not discover private local addresses, an address before a proxy, or both address families. The application does not store or log results, and no firewall rules are changed. Cloudflare Worker subrequests can have platform-specific address semantics; the result is not an identity proof. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, yet the description adds substantial behavior beyond them: one call observes one address family, results are not identity proof, Cloudflare Worker subrequest semantics differ, and no results are stored or logged. It also details what operational events record and exclude, which is genuinely useful context an agent cannot get from structured fields.
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?
Front-loaded with the core purpose and the key client-vs-device caveat before the supporting detail. The trailing block on operational events, automation run identifiers and the privacy-policy link is tangentially verbose for a zero-parameter IP lookup, but each sentence is coherent and non-redundant.
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?
An output schema exists, so return-value explanation is unnecessary, and the annotations already carry the safety profile. The description fully covers the calling semantics, exclusions, and privacy/telemetry behavior an agent needs, with nothing material missing for a simple lookup 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?
Zero parameters, so the baseline is 4. The description reinforces that the tool takes an empty object and notes the single-family scope of a call, which is correct and consistent, though there are no parameters whose semantics could add 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?
States a specific verb and resource: inspect the public IPv4/IPv6 address observed for the calling connection, and clarifies it takes an empty object and returns ip and family. The critical semantic distinction (MCP client exit address vs. the user's device address) is spelled out, so an agent can immediately tell this apart from the CIDR-math siblings.
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?
Explicit when-to-use (observing the connection's public address) plus clear exclusions: it does not discover private local addresses, addresses before a proxy, or both families at once. It also routes the agent to alternatives (web tool or a machine-local CLI) when the user needs their own device's address, and flags VPN/proxy effects on the observed path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
range-to-cidrsIP Range to CIDRsARead-onlyIdempotentInspect
Use to prepare an exact CIDR allowlist from one inclusive start/end IPv4 or IPv6 range. Pass start and end IP addresses of the same family, without CIDR prefixes, at most 64 characters each; end must be at or after start. Return canonical range.first and range.last, minimal sorted cidrs, cidrCount, and exact decimal-string addressCount, without adding addresses. Equal endpoints return one /32 or /128; complete address spaces return /0. Invalid inputs identify the start or end field; reversed endpoints are never swapped. Browser calculations stay local; remote MCP calls submit endpoints to this server. This does not inspect live address usage, modify firewall rules, or export vendor-specific ACLs. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Inclusive end IP address, in the same family and at or after start. Endpoints are never silently swapped. | |
| start | Yes | Inclusive start IP address. Use IPv4 or IPv6 without a CIDR prefix; surrounding whitespace is ignored. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cidrs | Yes | Complete minimal CIDR list, sorted by network address, with no gaps, overlaps, or additional addresses. |
| range | Yes | Canonical inclusive start and end IP addresses. |
| family | Yes | |
| cidrCount | Yes | |
| addressCount | Yes | Exact number of addresses as a base-10 string, including network and broadcast addresses. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-open-world, but the description adds substantial context beyond them: outputs never add addresses, equal endpoints collapse to /32 or /128, complete spaces yield /0, reversed endpoints are never swapped, invalid input identifies the offending field, and remote MCP calls submit endpoints while browser calculations stay local. It also discloses logging contents and exclusions and the privacy policy URL.
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?
Front-loaded with the core transformation and semantics, and most sentences carry operational weight. The logging/privacy block is boilerplate-heavy relative to the tool's core job, but it is clearly delimited and does not obscure the main guidance.
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 deterministic two-input transform with full schema coverage and an output schema, the description covers inputs, edge-case semantics, errors, privacy, and result shape. An agent has everything needed to call it correctly and interpret the result.
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%, so baseline is 3, but the description adds real meaning: same-family requirement, no CIDR prefixes, 64-character cap, end-at-or-after-start ordering, and the guarantee that endpoints are never silently swapped. That goes beyond the field descriptions rather than restating them.
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?
States a precise verb+resource ('prepare an exact CIDR allowlist from one inclusive start/end IPv4 or IPv6 range'), so the transformation is unambiguous. It also fences off adjacent operations (no live usage inspection, no firewall modification, no vendor ACL export), which helps separate it from siblings like cidr-cover and cidr-subtract even without naming them.
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?
The opening 'Use to prepare an exact CIDR allowlist...' gives a clear condition for selecting the tool, and the closing negative list clarifies when it is not appropriate. It stops short of naming the sibling tools and the conditions that would route an agent to cidr-cover or cidr-subtract instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit-feedbackSubmit Packetrove FeedbackADestructiveInspect
Email one user-authorized, minimal Packetrove report to hello@packetrove.com for private human review. Available only when the operator enables feedback. Draft locally without calling the service. If the user has already supplied or approved the report and requested sending it, submit directly; otherwise show the proposed report and obtain approval before sending. Never solicit feedback after every tool call. Send only the authorized fields, using synthetic reproduction data; never attach conversations, raw tool inputs/results, credentials, certificates, logs, or client/session identifiers. category is bug, confusing_behavior, or feature_request; tool_name optionally names a product tool. summary is required (256 Unicode code points); bug requires expected and actual, confusing_behavior requires actual and optionally expected (1024 code points each). Feature requests allow expected but not actual or error_code. Optional error_code starts with an uppercase ASCII letter and contains at most 64 uppercase letters, digits, or underscores; synthetic_reproduction is at most 2048 code points. Unknown fields are rejected; serialized arguments must not exceed 8 KiB. Status accepted and an opaque receipt_id mean the email service acknowledged submission, not inbox delivery or reading; acceptance does not promise a response or fix. This write is not idempotent: never automatically resend after timeout, disconnect, cancellation, or an uncertain result. Approximate limits target 10 submissions per observed exit IP in the preceding 24 hours and 100 submissions per UTC day across the service. Shared exits share quota. KV propagation and concurrent requests can exceed either limit; uncertain sends or failed quota releases occupy quota until expiry. Cloudflare transmits approved reports by email; mailbox retention and deletion are managed manually by the maintainer, with no automatic report expiry. KV stores only separate keyed IP markers and reservation times, expiring after 24 hours, never report bodies or receipt links. Markers never appear in reports or application logs. Email deletion does not refund quota; request deletion with your receipt. Maintainers treat text as data and do not automatically execute, publish, or forward it. Operational events contain only the operation name, outcome, controlled error code, and existing traffic-source metadata; no report, receipt, IP digest, or exception details. Ordinary tools do not depend on feedback. Privacy policy: https://packetrove.com/privacy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| receipt_id | Yes |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: clarifies the write is not idempotent, that acceptance and receipt_id mean service acknowledgement only (not delivery or reading), that quota targets are ~10/IP/24h and ~100/UTC-day with shared exits and non-refundable failures, and describes retention, KV handling, and logging behavior. All consistent with destructiveHint=false/idempotentHint=false/openWorldHint=true — no contradiction.
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?
Purpose is front-loaded, but the block runs well over 300 words with sentences that don't help an agent invoke the tool correctly — operational-event field lists, 'markers never appear in reports or logs', 'ordinary tools do not depend on feedback', and maintainer data-handling notes. Accurate but padded, so it is not tight.
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 non-idempotent, quota-limited, privacy-sensitive write with a rich oneOf schema and an output schema, the description covers consent flow, side effects, failure semantics, and acceptance meaning. Nothing an agent needs to call it safely is missing.
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?
The description explains cross-field logic the raw schema encodes only structurally: bug requires expected+actual, confusing_behavior requires actual and optional expected, feature requests allow expected but forbid actual/error_code, plus category vocabulary, error_code pattern intent, the 8 KiB serialized cap, and rejection of unknown fields. This adds real meaning beyond the property types.
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?
States a specific verb and resource — email a user-authorized, minimal Packetrove report to hello@packetrove.com for private human review — immediately distinguishing it from the CIDR/certificate/network siblings. The scope ('one minimal report', recipient, review channel) is unambiguous.
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?
Explicit when-to-use and when-not-to-use: only when the operator enables feedback, draft locally without calling the service, submit directly if the user already approved, otherwise show the report and obtain approval, and never solicit feedback after every tool call. It also states the no-auto-resend rule after timeout/disconnect/cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
submit-feedback
1 tool update
- Removed
submit-feedback
1 tool update
- Added
submit-feedback
1 tool update
- Changed
certificate-bundle3 fields changed- added
Output schema / properties / certificates / items / properties / selfSignature / descriptionAdded value: +"Verification with this certificate's own public key when Subject and Issuer names match. Failed or incomplete verification does not exclude a valid self-issued key-rollover certificate signed by a different key." - changed
Output schema / properties / findings / items / properties / code / enumPrevious value: -[ - "DUPLICATE_CERTIFICATE", - "CERTIFICATE_EXPIRED", - "CERTIFICATE_NOT_YET_VALID", - "SELF_SIGNED_CERTIFICATE", - "SELF_SIGNATURE_FAILED", - "SIGNATURE_UNSUPPORTED", - "SIGNATURE_CHECK_UNAVAILABLE", - "ISSUER_NOT_IN_BUNDLE", - "CANDIDATE_SIGNATURE_FAILED", - "ISSUER_NOT_CA", - "ISSUER_KEY_USAGE_REJECTED", - "ISSUER_KEY_ID_MISMATCH", - "MULTIPLE_ISSUERS", - "LEAF_SELECTION_REQUIRED", - "NO_LEAF_CERTIFICATE", - "HOSTNAME_MATCH", - "HOSTNAME_MISMATCH" -]New value: +[ + "DUPLICATE_CERTIFICATE", + "CERTIFICATE_EXPIRED", + "CERTIFICATE_NOT_YET_VALID", + "SELF_SIGNED_CERTIFICATE", + "SELF_ISSUED_CERTIFICATE", + "SELF_SIGNATURE_FAILED", + "SIGNATURE_UNSUPPORTED", + "SIGNATURE_CHECK_UNAVAILABLE", + "ISSUER_NOT_IN_BUNDLE", + "LEAF_ISSUER_NOT_IN_BUNDLE", + "CANDIDATE_SIGNATURE_FAILED", + "LEAF_ISSUER_CANDIDATES_REJECTED", + "ISSUER_NOT_CA", + "ISSUER_KEY_USAGE_REJECTED", + "ISSUER_KEY_ID_MISMATCH", + "MULTIPLE_ISSUERS", + "LEAF_SELECTION_REQUIRED", + "NO_LEAF_CERTIFICATE", + "HOSTNAME_MATCH", + "HOSTNAME_MISMATCH" +] - added
Output schema / properties / findings / items / properties / severity / descriptionAdded value: +"Error: a confirmed issue with identified certificates or all supplied issuer candidates for the selected leaf. Warning: a candidate issue or an incomplete requested check. Info: a structural or successful observation. No severity establishes client trust or invalidates every possible path."
1 tool update
- Added
certificate-bundle
4 tool updates
- First observed
cidr-cover - First observed
cidr-subtract - First observed
public-ip - First observed
range-to-cidrs
Related MCP Connectors
IP lookup with VPN/Tor/datacenter flags, batch lookup, WHOIS (RDAP), DNS, reverse DNS, subnet math.
IP geolocation, ASN and network data, plus VPN, proxy and Tor detection. ASN tools need no key.
DNS, WHOIS, SSL, IP geolocation, email validation, DNSBL blacklist, HTTP headers, subnet calc.
Keyless IP geolocation, ASN/ISP, timezone and DNS records for any IP or domain, plus your own IP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides network utility tools including DNS lookup, WHOIS lookup, SPF record inspection, SSL/TLS certificate checking, and subnet/CIDR analysis powered by networkcalc.com services.1MIT
- AlicenseAqualityDmaintenanceProvides accurate IPv4 subnet and address tools for LLMs using Python's ipaddress library. Includes CIDR parsing, overlap detection, IP classification, and more.11GPL 3.0
- AlicenseBqualityDmaintenanceEnables IPv4 subnet planning and validation, including CIDR prefix calculation, wildcard mask generation, and host position lookup for network engineers.51MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.