ip-enrichment-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_ipsA | Resolve what each IP is, from two independently-reported sources: a synced copy of Azure service tags (service_tag) and live reverse DNS (reverse_dns). Each result says which source(s) actually resolved and when the service-tags copy was last synced - never a fabricated hostname or tag. Accepts up to 50 IPs per call. |
| list_service_tag_rangesA | List every IPv4 CIDR prefix stored under one exact Azure service-tag name (e.g. "AzureAutomation.WestEurope", "Storage.EastUS", or the whole-cloud "AzureCloud"). Reads the same synced local index resolve_ips uses - never re-fetches from Azure. If the tag isn't in the current index, found is false and address_prefixes is empty - never a guessed or partial list. A near-miss on casing is reported (case_insensitive_match) rather than silently matched. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
resolve_ips operates on IP addresses, while list_service_tag_ranges operates on a tag name; the two tools have clearly distinct inputs and outputs, with no overlap in purpose.
Both tools use snake_case and follow a verb_noun pattern (resolve_ips, list_service_tag_ranges), providing a consistent and predictable naming convention.
Only two tools are provided; while each is distinct, the surface feels thin for an enrichment server that could reasonably support additional query or discovery operations (e.g., listing all tags, sync status).
The core enrichment workflow (IP resolution) is well-covered, and the auxiliary tag-range lookup adds value. However, minor gaps exist, such as no tool to list available service tags or explicitly check/trigger index synchronization.