Packetrove

IP Range to CIDRs

range-to-cidrs

Read-onlyIdempotent

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

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.

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.