MaxMindDB MCP Server

Overview Schema Source Related Servers Discussions Admin

Summarize a network

summarize_network

Read-onlyIdempotent

Group MMDB records in a CIDR by a scalar field, apply field filters, and count records and covered addresses for country or ASN summaries.

Instructions

Group matching records by a scalar field, such as country.iso_code or autonomous_system_number. Count records and covered addresses within a CIDR. Use lookup_network to retrieve individual records. IPv4 aliases are excluded. Exceeding 10,000 scanned records or 100 groups returns an error. Use a smaller CIDR if a limit is reached.

Input Schema

TableJSON Schema

Name	Required	Description
`filters`	No	Conditions on record fields. For example, [{"field":"autonomous_system_number","operator":"equals","value":13335}]. Omit for no filtering on a new query. On paginated queries, omit to retain the original filters.
`network`	Yes	CIDR to summarize. Use an IPv4 prefix length of 8 or greater, or a native IPv6 prefix length of 32 or greater.
`database`	Yes	Exact filename of a loaded database from list_databases.
`group_by`	Yes	Path to a scalar field, for example country.iso_code or autonomous_system_number. Use inspect_database to find paths. Supports numeric array indexes and $ for a scalar record. Missing fields form a separate group.
`filter_mode`	No	Combine filters with and (all must match) or or (any can match). Defaults to and for a new query. Omit when paging to retain the original mode.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`groups`	Yes
`network`	Yes
`database`	Yes
`group_by`	Yes
`matched_records`	Yes
`scanned_records`	Yes
`total_addresses`	Yes
`matched_addresses`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.1Oct 18, 2026

addedInput schema / properties / database / description

Added value: +"Exact filename of a loaded database from list_databases."

changedInput schema / properties / filter_mode / description

Previous value: -"How to combine filters: 'and' or 'or' (default: 'and')"New value: +"Combine filters with and (all must match) or or (any can match). Defaults to and for a new query. Omit when paging to retain the original mode."

changedInput schema / properties / filters / description

Previous value: -"Filters for a new query; omit to keep filters when continuing a query"New value: +"Conditions on record fields. For example, [{\"field\":\"autonomous_system_number\",\"operator\":\"equals\",\"value\":13335}]. Omit for no filtering on a new query. On paginated queries, omit to retain the original filters."

addedInput schema / properties / filters / items / properties / field / description

Added value: +"Field path from inspect_database, such as country.iso_code. Use dots for nested keys or numeric array indexes, or $ for the whole record."

addedInput schema / properties / filters / items / properties / operator / description

Added value: +"Comparison to apply. eq, ne, gt, lt, gte, and lte are aliases for the corresponding equality and ordering operators."

addedInput schema / properties / filters / items / properties / value / description

Added value: +"Comparison value. Use an array for in/not_in, a Go regular expression string for regex, or a substring for contains. For exists, true tests for a non-null field and false tests for a missing or null field. Ordering comparisons use numbers."

changedInput schema / properties / group_by / description

Previous value: -"Field path, array index, or $ for a scalar record. Missing fields form a separate group."New value: +"Path to a scalar field, for example country.iso_code or autonomous_system_number. Use inspect_database to find paths. Supports numeric array indexes and $ for a scalar record. Missing fields form a separate group."

changedInput schema / properties / network / description

Previous value: -"IPv4 /8 or smaller, or IPv6 /32 or smaller"New value: +"CIDR to summarize. Use an IPv4 prefix length of 8 or greater, or a native IPv6 prefix length of 32 or greater."

First observedv0.1.0Oct 18, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is established. The description adds meaningful operational detail beyond annotations: 'IPv4 aliases are excluded,' 'Exceeding 10,000 scanned records or 100 groups returns an error,' and the mitigation advice. This is valuable transparency about limits and data scope, though it doesn't explain output shape—but an output schema exists, so that's acceptable.

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?

Six sentences, each carrying distinct information: purpose, an example, an alternative tool pointer, a data caveat, a hard limit, and remediation advice. It's front-loaded with the core action and has no wasted words.

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?

For a read-only aggregation tool with full schema coverage and an output schema, the description covers purpose, usage boundaries, data exclusions, and error thresholds. The only minor gap is not explicitly stating that results are returned as grouped counts (though 'Count records and covered addresses' implies it), but overall it gives an agent enough to invoke the tool correctly and understand its limits.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters are fully documented in the schema with examples and enum explanations. The description mentions 'scalar field' and examples like country.iso_code, but adds no additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb and resource: 'Group matching records by a scalar field... Count records and covered addresses within a CIDR.' This clearly distinguishes summarize_network from lookup_network and lookup_range, which retrieve individual records rather than aggregate counts.

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 explicitly says 'Use lookup_network to retrieve individual records,' which routes the agent away from this tool for single-record lookups. It also gives practical guidance for hitting limits ('Use a smaller CIDR if a limit is reached'). It could be stronger by stating when to use summarize_network versus compare_databases, but the primary alternative is covered.

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

Deploy Server