How do I use nwtools-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@nwtools-mcp Check if 10.0.0.5 is in 10.0.0.0/24" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

nwtools-mcp

by crims0n

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

nwtools-mcp

An MCP server that gives LLMs accurate IPv4 subnet and address tools. LLMs are unreliable at network math — this server provides deterministic, correct results via Python's ipaddress standard library.

PyPI: https://pypi.org/project/nwtools-mcp/

Tools

Tool	Description
`parse_cidr`	Network address, broadcast, netmask, wildcard mask, host count
`ip_in_subnet`	Check whether an IP falls within a subnet
`subnets_overlap`	Detect overlap between two subnets and return the intersection
`cidr_to_range`	Convert a CIDR to its first and last IP address
`range_to_cidrs`	Convert an IP range to the minimal list of covering CIDRs
`subtract_subnet`	Carve a subnet out of a larger block, returning remaining CIDRs
`find_gaps`	Find unallocated space within a container block
`check_coverage`	Check whether a set of CIDRs fully covers a target block
`summarize_cidrs`	Collapse a list of CIDRs into the minimal set of supernets
`classify_ip`	Classify an IP as RFC 1918, loopback, link-local, multicast, or public
`ip_convert`	Convert an IP between dotted-decimal, hex, binary, and integer

Related MCP server: subnet-calculator-mcp

Environment variables

Variable	Default	Description
`MCP_TRANSPORT`	`stdio`	`stdio`, `streamable-http`, or `sse`
`HOST`	`0.0.0.0`	Bind address (HTTP transports only)
`PORT`	`8000`	Listen port (HTTP transports only)
`API_KEY`	(none)	When set, requires `X-API-Key: <value>` on all HTTP requests
`LOG_LEVEL`	`INFO`	Python log level for process and request logging

Local use (stdio)

The stdio transport is used when Claude Desktop spawns the server as a subprocess. No network port is opened.

Run from PyPI with uvx

The simplest way to run the server locally is:

uvx nwtools-mcp

That runs the nwtools-mcp console command from an isolated ephemeral environment. For a persistent install:

uv tool install nwtools-mcp
nwtools-mcp

Install and run directly:

pip install -e .
python main.py

Or use the console script:

nwtools-mcp

Or install from PyPI with pip:

pip install nwtools-mcp
nwtools-mcp

Or via Docker:

docker run --rm -i nwtools-mcp

Claude Desktop config

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "nwtools": {
      "command": "python",
      "args": ["/path/to/nwtools-mcp/main.py"]
    }
  }
}

Or run it directly from PyPI with uvx:

{
  "mcpServers": {
    "nwtools": {
      "command": "uvx",
      "args": ["nwtools-mcp"]
    }
  }
}

If you prefer a persistent uv-managed install, use:

{
  "mcpServers": {
    "nwtools": {
      "command": "nwtools-mcp"
    }
  }
}

Remote deployment (HTTP)

The server supports streamable-http (recommended) and sse transports for remote access. Set MCP_TRANSPORT to switch modes.

Running the HTTP server

# Local test
MCP_TRANSPORT=streamable-http python main.py

# With auth
API_KEY=your-secret MCP_TRANSPORT=streamable-http python main.py

With Docker:

docker build -t nwtools-mcp .
docker run --rm -p 8000:8000 \
  -e MCP_TRANSPORT=streamable-http \
  -e API_KEY=your-secret \
  nwtools-mcp

Operational endpoints

When running in HTTP mode, the container exposes two unauthenticated probe endpoints:

Endpoint	Description
`/healthz`	Basic liveness probe
`/readyz`	Readiness probe

HTTP requests are also logged as structured JSON lines, including method, path, status, duration, client IP, and request ID.

TLS and auth

The server does not terminate TLS. In production, place it behind a reverse proxy. Example Caddy config:

nwtools.example.com {
    reverse_proxy localhost:8000
}

The built-in API_KEY check adds a layer of defense at the application level, but it does not replace TLS — never expose the server without it.

Connecting Claude to a remote server

In Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "nwtools": {
      "url": "https://nwtools.example.com/mcp",
      "headers": {
        "X-API-Key": "your-secret"
      }
    }
  }
}

On claude.ai, add the server under Settings → Integrations using the same URL.

Development

Install with the test extra and run the suite:

pip install -e ".[test]"
pytest

To build distribution artifacts locally:

uv build

Or with the standard Python build frontend:

pip install build
python -m build

Release

The project is now structured to publish cleanly to PyPI and run via uvx.

Build locally:

uv build

Publish manually:

uv publish

Automated publishing uses publish.yml with PyPI Trusted Publishing.

Release checklist:

Update version in pyproject.toml and __version__ in src/nwtools_mcp/init.py.
Run pytest.
Run uv build.
Commit and push to main.
Push a version tag such as v0.2.0.

Trusted Publisher settings:

Create a pypi environment in the GitHub repository settings.
Add a Trusted Publisher for this project on PyPI that matches: Repository owner: crims0n Repository name: nwtools-mcp Workflow filename: publish.yml Environment name: pypi

The publish workflow builds the wheel and sdist, smoke-tests both artifacts, and then runs uv publish.

Requirements

Python 3.11+
mcp
uvicorn

Available Tools

11 tools

check_coverageC

Check whether a set of CIDRs fully covers a target block.

ParametersJSON Schema

Name	Required	Description	Default
`target_cidr`	Yes
`covering_cidrs`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only, what the output format is (e.g., boolean or list), or any side effects. Minimal 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.

Conciseness4/5

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

The description is a single, efficient sentence with no redundancy. However, it is too terse for the agent to fully understand usage, slightly reducing score from 5.

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

Completeness2/5

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

Given no output schema and no annotations, the description is incomplete. It fails to explain return value (e.g., boolean or detailed report) or edge cases, leaving the agent guessing.

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

Parameters2/5

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

Schema description coverage is 0%, yet description only loosely maps 'set of CIDRs' and 'target block' to parameters. No format constraints (e.g., CIDR string format) or additional semantics beyond property names.

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

Purpose4/5

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

The description clearly states the tool checks whether a set of CIDRs fully covers a target block, distinguishing it from siblings like find_gaps or subnets_overlap. The verb 'check' and specific resource 'CIDRs fully covers a target block' provide clear purpose.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like find_gaps or subnets_overlap. The description implies usage for coverage verification but offers no context or exclusions.

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

cidr_to_rangeC

Convert a CIDR block to its first and last IP address.

ParametersJSON Schema

Name	Required	Description	Default
`cidr`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided, and the description only states basic conversion. It does not disclose output format, error handling, or potential side effects.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the purpose. No extraneous words.

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

Completeness2/5

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

Despite the tool's simplicity, the description omits output details and validation information. Without an output schema, the agent lacks understanding of return values.

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

Parameters2/5

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

Schema description coverage is 0%. The description adds minimal value by noting the parameter is a 'CIDR block' but does not specify expected format or constraints.

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

Purpose4/5

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

The description clearly states the action (convert) and the resource (CIDR block to first and last IP address). It is specific but does not differentiate from sibling tools like parse_cidr or range_to_cidrs.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. With many sibling IP tools, the agent has no context for selection.

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

classify_ipC

Classify an IPv4 address by its scope and allocation type.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations exist, so the description must fully convey behavioral traits. It states it classifies by 'scope and allocation type' but does not disclose possible output values, format, or any side effects. The agent cannot infer the classification categories or return structure.

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 description is a single sentence, which is concise and front-loads the purpose. However, it is overly brief, sacrificing necessary details for the sake of brevity.

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

Completeness2/5

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

The tool is simple (one parameter) but the description is incomplete. It does not explain what 'scope and allocation type' means, list possible outputs, or relate to sibling tools. An agent cannot reliably invoke this tool without additional context.

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

Parameters1/5

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

Schema description coverage is 0%, requiring the description to explain the parameter. However, it only mentions 'IPv4 address' generically, not specifying the format (e.g., dotted decimal) or constraints. The parameter name 'ip' and title 'Ip' offer no additional meaning.

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 clearly states the tool's purpose: classifying an IPv4 address by scope and allocation type. The verb 'classify' and resource 'IPv4 address' are specific, and the tool is distinct from its sibling tools (e.g., check_coverage, cidr_to_range) which perform different operations.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as checking coverage or converting IPs. The description lacks context about prerequisites, limitations, or exclusion criteria.

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

find_gapsC

Find unallocated address space within a container block.

ParametersJSON Schema

Name	Required	Description	Default
`container_cidr`	Yes
`used_cidrs`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It does not disclose return format, handling of overlapping used CIDRs, or constraints. The minimal phrase adds little beyond the tool name.

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

Conciseness2/5

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

While the single sentence is concise, it is under-specified for the tool's complexity. Conciseness should balance brevity with informativeness; here it sacrifices necessary detail.

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

Completeness2/5

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

Given 2 parameters, no output schema, and no annotations, the description is incomplete. It omits return value semantics, edge cases, and usage context, leaving the agent underinformed.

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

Parameters1/5

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

Schema coverage is 0% and the description does not augment it. No explanation of parameter format, constraints, or examples is given. The description fails to add value beyond 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?

The description clearly states the action ('Find') and resource ('unallocated address space') within a specific context ('within a container block'). This distinguishes it from sibling tools like 'check_coverage' or 'subtract_subnet'.

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

Usage Guidelines2/5

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

The description lacks guidance on when to use this tool versus alternatives like 'check_coverage' or 'summarize_cidrs'. No scenarios, prerequisites, or exclusions are mentioned.

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

ip_convertA

Convert an IPv4 address between dotted-decimal, hex, binary, and integer forms.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavior for invalid inputs, side effects, or whether conversion is bidirectional. A conversion tool likely has no side effects, but error handling is not addressed.

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

Conciseness5/5

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

One sentence that is front-loaded with the action and concise. Every word is necessary and no redundancy.

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

Completeness2/5

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

No output schema and description does not explain what the tool returns (e.g., which formats are output, single or multiple values). Also missing handling of invalid IPs. For a simple conversion tool, more completeness is expected.

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?

The single parameter 'ip' is typed as string, but the description clarifies it accepts IPv4 in four forms (dotted-decimal, hex, binary, integer). This adds meaning beyond the schema, though precise formatting constraints are omitted.

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 clearly states the tool converts IPv4 addresses between four forms (dotted-decimal, hex, binary, integer). The verb 'Convert' and resource 'IPv4 address' are specific, and the tool is distinct from sibling tools like cidr_to_range or classify_ip.

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 description implies usage when format conversion is needed, but does not explicitly state when not to use it or mention alternative tools. Given sibling context, the purpose is clear, but lacks explicit exclusions.

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

ip_in_subnetC

Check whether an IPv4 address falls within a subnet.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes
`cidr`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

The description implies a boolean check but does not explicitly state the return type or behavior on invalid input (e.g., malformed IP or CIDR). With no annotations, the description should disclose side effects or error handling, and it fails to do so. The statement is too minimal to inform an agent of the tool's full behavior.

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 description is a single sentence, which is concise, but it omits essential details. It is not overly verbose, but the brevity comes at the cost of completeness. It earns a middle score for being short but not sufficiently informative.

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

Completeness2/5

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is incomplete. It lacks information on return value format, error handling, and parameter constraints. An agent would need additional knowledge to invoke this tool correctly.

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

Parameters1/5

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

Schema description coverage is 0%, meaning the parameter names are not described in the schema. The description does not explain the expected format of 'ip' (e.g., dotted decimal) or 'cidr' (e.g., '192.168.1.0/24'). This is a critical gap for correct usage.

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

Purpose4/5

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

The description clearly states the tool checks if an IPv4 address belongs to a subnet. The verb 'Check' and the specific resource 'IPv4 address' and 'subnet' make the purpose explicit. However, it does not differentiate from sibling tools like check_coverage or subnets_overlap, which might have similar purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or context for use. The description simply states what it does without any when-to-use or when-not-to-use information.

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

parse_cidrC

Parse a CIDR block and return key network properties.

ParametersJSON Schema

Name	Required	Description	Default
`cidr`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it parses and returns properties. It does not disclose validation behavior, error handling, or output format.

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 description is a single concise sentence. It is not verbose but could be more informative. It is adequate but not excellent.

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

Completeness2/5

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 says 'return key network properties' without specifying what properties. The agent has no idea what it will receive. Given the low complexity, this is incomplete.

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

Parameters2/5

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

The schema has 0% description coverage, and the description only says 'Parse a CIDR block' without specifying the expected format (e.g., '192.168.1.0/24'). The agent lacks guidance on the parameter's syntax.

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

Purpose4/5

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

The description clearly states the tool parses a CIDR block and returns key network properties. The verb 'parse' and resource 'CIDR block' are specific. However, it does not list what properties are returned, which would enhance clarity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus siblings like cidr_to_range or ip_in_subnet. The description lacks context for selection.

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

range_to_cidrsA

Convert an inclusive IP address range to the minimal list of covering CIDRs.

ParametersJSON Schema

Name	Required	Description	Default
`first_ip`	Yes
`last_ip`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It truthfully states the conversion to a 'minimal list of covering CIDRs', but does not disclose input validation, handling of invalid IPs, or whether it supports IPv6. The simplicity reduces the need for more, but some gaps remain.

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

Conciseness5/5

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

The description is a single, well-structured sentence with no unnecessary words. It conveys the core functionality efficiently.

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

Completeness4/5

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

Given the tool's low complexity and lack of output schema, the description sufficiently explains what the tool does and what it returns (a list of CIDRs). However, it omits error handling and specific IP format requirements, which are minor gaps.

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

Parameters2/5

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

Schema description coverage is 0%, yet the description does not elaborate on the parameters. It only names them implicitly ('first_ip', 'last_ip') but provides no format guidance (e.g., dotted decimal, CIDR notation) or constraints. This is insufficient for a tool requiring valid IP addresses.

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 clearly states the action ('convert') and the resource ('inclusive IP address range' to 'minimal list of covering CIDRs'). It is specific and distinguishes well from sibling tools like cidr_to_range (reverse operation) and check_coverage.

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

Usage Guidelines3/5

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

The description implies when to use this tool (when you have an IP range and need CIDR representation) but does not explicitly mention when not to use it or suggest alternatives. Sibling tool names hint at other operations, but no direct guidance is provided.

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

subnets_overlapB

Check whether two IPv4 subnets overlap.

ParametersJSON Schema

Name	Required	Description	Default
`cidr_a`	Yes
`cidr_b`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Without annotations, the description only states the core behavior. It does not disclose return format, edge cases, or whether the operation is read-only, but the behavior is straightforward.

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

Conciseness5/5

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

The description is a single, efficient sentence with no unnecessary words, perfectly concise.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the basic purpose but lacks details on return value, error handling, and overlap definition, making it minimally adequate.

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

Parameters2/5

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

Schema description coverage is 0% and the description adds no additional meaning to the parameters beyond their names, neglecting to specify expected formats like CIDR notation.

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 uses a specific verb 'Check' and identifies the resource as 'two IPv4 subnets', clearly distinguishing the tool from siblings like ip_in_subnet or find_gaps.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool over alternatives, nor does it mention preconditions or exclusions.

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

subtract_subnetC

Subtract one subnet from another and return the remaining address space as CIDRs.

ParametersJSON Schema

Name	Required	Description	Default
`base_cidr`	Yes
`remove_cidr`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description carries the full burden. It does not disclose side effects, error conditions, or requirements like permissions. Only states the operation and output, missing behavioral details.

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?

One sentence, no wasted words. Front-loaded with the action. Could be slightly more informative without sacrificing conciseness.

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

Completeness2/5

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

Given 0% schema description coverage, no output schema, and no annotations, the description is insufficient. It does not explain parameter formats, edge cases, or the exact output structure.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only generically refers to 'one subnet from another' without explaining the format or constraints of base_cidr and remove_cidr.

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 clearly states the verb 'Subtract', the resource 'one subnet from another', and the outcome 'return the remaining address space as CIDRs'. It distinguishes from siblings like find_gaps and subnets_overlap.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as find_gaps or subnets_overlap. The description implies a usage scenario but does not explicitly state it.

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

summarize_cidrsA

Collapse a list of CIDRs into the minimal set of covering supernets.

ParametersJSON Schema

Name	Required	Description	Default
`cidrs`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes the core behavior (collapsing to minimal supernets) but omits details like input validation, handling of non-overlapping CIDRs, or output format. Adequate for a simple tool but lacks depth.

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

Conciseness5/5

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

A single, front-loaded sentence with no wasted words. Every part of the description adds value.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the basic operation but lacks details on return value, edge cases, and prerequisites. With no output schema and minimal parameter info, the description is adequate but not fully complete.

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

Parameters2/5

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

The single parameter 'cidrs' has 0% schema description coverage. The description only says 'list of CIDRs', which minimally explains the expected string format but does not specify constraints like valid CIDR notation, allowed address families, or behavior with duplicates.

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 uses specific verb 'collapse' and specifies resource 'list of CIDRs' and outcome 'minimal set of covering supernets'. It clearly distinguishes from sibling tools like find_gaps or subtract_subnet.

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 description implies usage when needing to combine overlapping CIDRs into supernets, but does not provide explicit when-not-to-use or alternative tool comparisons. However, the context is clear enough for a straightforward computation tool.

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.

11 tool updatesv0.2.0Jun 4, 2026
- First observedcheck_coverage
- First observedcidr_to_range
- First observedclassify_ip
- First observedfind_gaps
- First observedip_convert
- First observedip_in_subnet
- First observedparse_cidr
- First observedrange_to_cidrs
- First observedsubnets_overlap
- First observedsubtract_subnet
- First observedsummarize_cidrs

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-06-04 04:55 across 11 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, from parsing CIDRs (parse_cidr) to checking coverage (check_coverage) and finding gaps (find_gaps). There is no ambiguity or overlap between tool functionalities.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., classify_ip, summarize_cidrs, subtract_subnet), making the set predictable and easy to navigate.

Tool Count5/5

With 11 tools, the server is well-scoped for IP address manipulation tasks. Each tool earns its place, covering essential operations without unnecessary bloat or missing coverage.

Completeness5/5

The tool set covers the full lifecycle of common IP networking tasks: parsing, conversion, classification, membership checking, coverage analysis, gap detection, overlap checking, subtraction, summarization, and range conversion. No obvious gaps for the domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Subnet Calculator MCP A
io.github.zekerutledge
Calculates IPv4 subnet information from an IP address and CIDR prefix or dotted decimal subnet mask
Networking & Infrastructure Developer Tools
11
Lookip A
io.lookip
IP geolocation, ASN and network data, plus VPN, proxy and Tor detection. ASN tools need no key.
Location Services Security Networking & Infrastructure
51
Ipaddress A
io.github.pipeworx-io
IP address utilities MCP.
Networking & Infrastructure Location Services
332
TinyFn C
io.tinyfn
500+ deterministic tools for AI agents: math, conversion, validation, hashing, encoding, date/time.
Developer Tools
57221

Related MCP Servers

IPMentor
Education & Learning Tools Networking & Infrastructure
DavidLMS
A
license
Not graded
quality
D
maintenance
Provides verified IPv4 subnet calculations, IP analysis, and network diagram generation for AI tutoring systems via MCP.
Updated 10 months ago (2025-11-02 18:26 UTC)
1
MIT
subnet-calculator-mcp
Networking & Infrastructure
sanjayshreeyans
A
license
B
quality
D
maintenance
Enables IPv4 subnet planning and validation, including CIDR prefix calculation, wildcard mask generation, and host position lookup for network engineers.
Updated 10 months ago (2025-11-11 05:06 UTC)
5
1
MIT
ip-mcp
Networking & Infrastructure
MukundaKatta
A
license
A
quality
D
maintenance
Provides tools to classify, test, and expand IPv4/IPv6 addresses using Node's built-in net module.
Updated 10 days ago (2026-09-05 23:52 UTC)
3
6 npm
MIT
mcp-ipaddress
Networking & Infrastructure Developer Tools
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides IP address utilities including parsing and classification of IPv4/IPv6 addresses and CIDR block information.
Updated 20 days ago (2026-08-26 17:16 UTC)
5 npm
MIT