Skip to main content
Glama
Sign In
MaxMindDB MCP Server

MaxMindDB MCP Server

by oschwald
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Summarize a network

summarize_network
Read-onlyIdempotent

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.

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

NameRequiredDescriptionDefault
filtersNoConditions 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.
networkYesCIDR to summarize. Use an IPv4 prefix length of 8 or greater, or a native IPv6 prefix length of 32 or greater.
databaseYesExact filename of a loaded database from list_databases.
group_byYesPath 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_modeNoCombine 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

NameRequiredDescriptionDefault
groupsYes
networkYes
databaseYes
group_byYes
matched_recordsYesStored network records passing the filters. Equals the sum of group record counts.
scanned_recordsYesStored network records examined before filtering, not individual IP addresses.
total_addressesYesNumber of addresses in the requested CIDR, including uncovered addresses. A decimal integer string preserves IPv6 precision.
matched_addressesYesAddresses covered by matching records inside the CIDR, excluding IPv4 aliases. A decimal integer string preserves IPv6 precision.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.4.0
    • addedOutput schema / properties / groups / items / properties / addresses / description
      Added value: +"Addresses covered by this group inside the requested CIDR. A decimal integer string preserves IPv6 precision."
    • addedOutput schema / properties / groups / items / properties / missing / description
      Added value: +"True when the group_by field is absent. Distinguishes a missing field from a field containing null."
    • addedOutput schema / properties / groups / items / properties / records / description
      Added value: +"Matching stored network records in this group, not individual IP addresses."
    • addedOutput schema / properties / matched_addresses / description
      Added value: +"Addresses covered by matching records inside the CIDR, excluding IPv4 aliases. A decimal integer string preserves IPv6 precision."
    • addedOutput schema / properties / matched_records / description
      Added value: +"Stored network records passing the filters. Equals the sum of group record counts."
    • addedOutput schema / properties / scanned_records / description
      Added value: +"Stored network records examined before filtering, not individual IP addresses."
    • addedOutput schema / properties / total_addresses / description
      Added value: +"Number of addresses in the requested CIDR, including uncovered addresses. A decimal integer string preserves IPv6 precision."
  2. Changed8 schema fields changedv0.3.1
    • 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."
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive safety. The description adds useful behavioral context beyond them: IPv4 aliases are excluded, and exceeding 10,000 scanned records or 100 groups returns an error.

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 short and front-loaded: it states the aggregation behavior first, then the alternative, exclusion, and limits. Every sentence adds useful information without waste.

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?

With an output schema present and full schema description coverage, the description does not need to explain return values or every parameter. It supplies the key operational constraints, exclusion behavior, and sibling alternative needed to call the tool correctly.

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 the schema already documents all parameters in detail. The description gives examples for group_by and network but does not add syntax or meaning beyond what the schema provides, making the baseline 3 appropriate.

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 states a specific verb and resource: group matching records by a scalar field and count records and covered addresses within a CIDR. It also distinguishes the tool from lookup_network by saying that lookup_network retrieves individual records.

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?

It explicitly names the alternative for retrieving individual records and gives a concrete remedy when a limit is reached: use a smaller CIDR. That gives an agent clear routing and constraint guidance.

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

Deploy Server

Other Tools