Packetrove

Smallest Covering CIDR

cidr-cover

Read-onlyIdempotent

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

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.

All Packetrove tools Inspect

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.