Skip to main content
Glama
MaxMindDB MCP Server

MaxMindDB MCP Server

Query a network

lookup_network
Read-only

Find stored network records overlapping a CIDR, with optional filters and field selection. Returned networks may extend beyond the requested CIDR. Use lookup_range for start/end bounds or summarize_network for grouped counts.

Instructions

Find stored network records overlapping a CIDR, with optional filters and field selection. Returned networks may extend beyond the requested CIDR. Use lookup_range for start/end bounds or summarize_network for grouped counts. Repeat the network and database on each page. Stop when has_more is false.

Input Schema

NameRequiredDescriptionDefault
fieldsNoOptional field paths. Returns an object keyed by each selected path. Use dots for map keys, numeric array indexes, or $ for the whole record. Omit or use [] for full records. Repeat on each page.
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.
networkYesIPv4 or IPv6 CIDR to scan, for example 192.168.1.0/24 or 2001:db8::/32. Broad queries may scan many records.
databaseNoExact filename from list_databases. Required when more than one database is loaded. Repeat the same name on each page.
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.
iterator_idNoID from the previous page. Omit on the first request. Send with the latest resume_token to continue if the iterator expires.
max_resultsNoMaximum matching records to return on this page. Use a smaller page to reduce response size.
resume_tokenNoToken from the previous page, used if iterator_id is missing or expired. Omit on the first request. If the database build changed, start a new query.

Output Schema

NameRequiredDescriptionDefault
resultsYes
has_moreYesTrue when another matching record exists. Continue with the same query parameters.
iterator_idYesIdentifier for continuing this live query with the same parameters.
resume_tokenYesToken for resuming after the last returned record if the live iterator expires.
total_matchedYesCumulative matching records returned across pages, not the count on this page.
total_processedYesCumulative records processed across pages, including nonmatching records scanned ahead to find the next match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.0
    • addedOutput schema / properties / has_more / description
      Added value: +"True when another matching record exists. Continue with the same query parameters."
    • addedOutput schema / properties / iterator_id / description
      Added value: +"Identifier for continuing this live query with the same parameters."
    • addedOutput schema / properties / resume_token / description
      Added value: +"Token for resuming after the last returned record if the live iterator expires."
    • addedOutput schema / properties / total_matched / description
      Added value: +"Cumulative matching records returned across pages, not the count on this page."
    • addedOutput schema / properties / total_processed / description
      Added value: +"Cumulative records processed across pages, including nonmatching records scanned ahead to find the next match."
  2. Changed10 schema fields changedv0.3.1
    • changedInput schema / properties / database / description
      Previous value: -"Database name from list_databases; required when more than one is loaded"New value: +"Exact filename from list_databases. Required when more than one database is loaded. Repeat the same name on each page."
    • 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 / iterator_id / description
      Previous value: -"Resume existing iterator (fast path)"New value: +"ID from the previous page. Omit on the first request. Send with the latest resume_token to continue if the iterator expires."
    • changedInput schema / properties / max_results / description
      Previous value: -"Page size from 1 to 1000"New value: +"Maximum matching records to return on this page. Use a smaller page to reduce response size."
    • changedInput schema / properties / network / description
      Previous value: -"CIDR network to scan (e.g., '192.168.1.0/24')"New value: +"IPv4 or IPv6 CIDR to scan, for example 192.168.1.0/24 or 2001:db8::/32. Broad queries may scan many records."
    • changedInput schema / properties / resume_token / description
      Previous value: -"Fallback token if iterator expired"New value: +"Token from the previous page, used if iterator_id is missing or expired. Omit on the first request. If the database build changed, start a new query."
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior — that returned networks may extend beyond the requested CIDR, and that network/database must be re-sent on each page. These are non-obvious semantics an agent could not infer from the annotations and would only partially get from the schema. Not full marks because it does not surface the cost of broad scans or iterator expiration (both only implied in the schema).

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?

Four short sentences, front-loaded with purpose, then the caveat, then the alternatives, then the paging contract. No filler and nothing repeated; each sentence carries a distinct decision-relevant fact.

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 an 8-parameter, paginated query tool with an output schema and full annotation coverage, the description gives exactly the missing context: overlap semantics, sibling routing, and the pagination loop termination condition. Nothing an agent needs in order to call it correctly is absent.

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% and each parameter carries a detailed description including paging retention rules, so the schema does the heavy lifting. The description's only parameter-level contribution is repeating that network and database must be repeated per page, which is largely restated from the schema. Baseline 3 applies.

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 — find stored network records — plus the defining scope condition (overlapping a CIDR) and the optional filters/field selection. It immediately distinguishes itself from lookup_range and summarize_network, so an agent can route correctly without opening the schema.

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?

Explicitly names the two alternatives and the condition that selects each (start/end bounds → lookup_range, grouped counts → summarize_network). It also gives a paging usage rule (repeat network/database per page, stop when has_more is false), so both tool choice and call sequencing are covered.

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