NetLoc8 MCP gives AI assistants IP geolocation, network utilities, and account management via 14 tools and 4 prompts, usable with or without an API key.
Geolocation (API-based)
Geolocate any IP (geolocate_ip): Look up country, city, region, coordinates, timezone, ASN, org, and EU membership for any IPv4/IPv6 address.
Geolocate your own machine (geolocate_me): Retrieve rich geo data for the server's own public IP — no arguments needed.
Get timezone for an IP (get_timezone): Fetch just the IANA timezone string for an IP, useful for scheduling or date formatting.
Local Utilities (no API call, no quota)
Validate an IP (validate_ip): Check whether a string is a valid IPv4 or IPv6 address.
Check if an IP is public (is_public_ip): Determine if an IP is publicly routable, rejecting RFC1918, CGNAT, loopback, link-local, and ULA addresses.
Normalize an IP string (normalize_ip): Strip brackets, remove IPv4-mapped prefixes, trim whitespace, and lowercase.
Derive subnet (get_subnet): Calculate the /24 CIDR prefix from an IPv4 address (e.g., 8.8.8.8 → 8.8.8.0/24).
Account Management (requires API key)
List, create, delete, and renew API keys; view usage stats, account profile, and audit logs.
Guided Prompts
Deep-dive IP analysis, security audits, batch geolocation comparisons, and onboarding workflows.
Resources
Product overview, SDKs, pricing, and quick-start guides via netloc8://about.
Direct geo data for a specific IP via netloc8://ip/{address}.
Note: This repository is a read-only mirror. Please do not submit issues or pull requests here; contributions and development are managed internally.
⚠️ Deprecated: This Go binary is replaced by the
@netloc8/mcpnpm package and the hosted server atmcp.netloc8.com. See Migration below.# New install (no Go required): npx --yes --prefer-online @netloc8/mcp@latest
An MCP server that gives AI assistants access to NetLoc8 — IP geolocation deployed to 300+ edge locations worldwide.
Works with or without an API key. Without a key, you get country-level geo data and local utility tools. With a free key, you unlock city-level detail, coordinates, timezone, and account management.
AI coding assistants run into IP geolocation constantly — parsing access logs, debugging proxy chains, geo-routing traffic, checking EU compliance, verifying CDN behavior. Without an MCP server, you have to copy-paste results from a browser tab. With this server, your AI assistant resolves IPs inline, in context, without breaking flow.
Zero-config — go install and add three lines to your MCP config
Works without a key — country-level lookups and local IP utilities with no sign-up
14 tools — geo lookup, timezone, IP validation, subnet math, account management
4 guided prompts — IP analysis, security audit, batch comparison, onboarding
Freemium built in — unauthenticated users see upgrade hints for city-level data
Related MCP server: IP Geolocation MCP Server
Ask your AI assistant:
Where is 8.8.8.8?
The assistant calls geolocate_ip and responds with something like:
8.8.8.8 is located in Mountain View, California, US.
Country United States (US) 🇺🇸
Region California (CA)
City Mountain View
Coordinates 37.386, -122.084
Timezone America/Los_Angeles (UTC-07:00)
ASN AS15169
Org Google LLC
EU member NoOther things you can ask:
Prompt | What happens |
"Where is my server?" | Calls |
"Is 10.0.0.1 a public IP?" | Calls |
"Analyze 203.0.113.42" | Runs the |
"Compare these IPs: 8.8.8.8, 1.1.1.1, 208.67.222.222" | Runs |
"Audit my NetLoc8 account" | Runs |
"What subnet is 203.0.113.42 in?" | Calls |
"Set me up with NetLoc8 for Next.js" | Runs |
Requires Go 1.26+.
go install github.com/netloc8/netloc8-mcp@latestOne-liner:
claude mcp add --env NETLOC8_API_KEY=sk_live_YOUR_KEY netloc8 -- netloc8-mcpOr add to .mcp.json in your project root (committable):
{
"mcpServers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}Add to .cursor/mcp.json in your project root (or ~/.cursor/mcp.json for global):
{
"mcpServers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}Add to .vscode/mcp.json in your project root:
{
"servers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}One-liner:
codex mcp add --env NETLOC8_API_KEY=sk_live_YOUR_KEY netloc8 -- netloc8-mcpOr add to ~/.codex/config.toml (global) or .codex/config.toml (project):
[mcp_servers.netloc8]
command = "netloc8-mcp"
env = { NETLOC8_API_KEY = "sk_live_YOUR_KEY" }Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}Add to ~/.gemini/config/mcp_config.json:
{
"mcpServers": {
"netloc8": {
"command": "netloc8-mcp",
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}No API key? Remove the
"env"block entirely. The server starts in unauthenticated mode with country-level geo lookups and local tools. Sign up for a free key at netloc8.com to unlock full features.
Variable | Required | Default | Description |
| No | — | Your NetLoc8 API key. Enables city-level data and account management. |
| No |
| Override the API base URL (for staging/dev). |
Tool | Description |
| Look up geolocation for any IPv4/IPv6 address |
| Look up geolocation for the server's own IP |
| Get IANA timezone for an IP address |
| Check if a string is a valid IP address |
Tool | Description |
| Check if an IP is publicly routable |
| Clean up IP strings (brackets, ::ffff: prefix, whitespace) |
| Derive /24 CIDR prefix from an IPv4 address |
Tool | Description |
| List all API keys on your account |
| Get request counts and plan limits |
| Get account profile (name, email) |
| View account activity log |
| Create a new API key |
| Revoke an API key (irreversible) |
| Extend an API key's expiration |
Prompts are guided workflows that chain multiple tools together. Select them from your MCP client's prompt picker, or just describe what you want — most clients will match you to the right prompt automatically.
Prompt | Description |
| Deep-dive analysis of a single IP — classification, geolocation, network, timezone, EU status |
| Review your NetLoc8 account — API key inventory, recent activity, usage, recommendations |
| Look up multiple IPs and produce a comparison table |
| Guided onboarding — create a key, verify it, get SDK install instructions for your platform |
URI | Description |
| Product overview, SDKs, pricing, and quick start guide |
| Geo data for a specific IP address |
Feature | No API Key | Free Key | Paid Key |
Country-level geo | ✅ | ✅ | ✅ |
City, coordinates, timezone | — | ✅ | ✅ |
Local utility tools | ✅ | ✅ | ✅ |
Account management | — | ✅ | ✅ |
Monthly requests | — | 5,000 | 25,000+ |
NetLoc8 — Sign up (free, no credit card)
This Go binary server is deprecated in favor of:
npm package — @netloc8/mcp — same tools, no Go required
Hosted server — mcp.netloc8.com — zero install, OAuth 2.1 auth
Replace your MCP client config:
{
"mcpServers": {
"netloc8": {
- "command": "/path/to/netloc8-mcp",
+ "command": "npx",
+ "args": ["--yes", "--prefer-online", "@netloc8/mcp@latest"],
"env": {
"NETLOC8_API_KEY": "sk_live_YOUR_KEY"
}
}
}
}All 14 tools, 4 prompts, and 2 resources are identical — no client-side changes needed.
Look up geolocation data for an IPv4 or IPv6 address using NetLoc8's edge network. Returns country, city, region, coordinates, timezone, ASN, and EU membership status. Use this when you need the physical location of an IP address. Example: ip="8.8.8.8" → United States, Mountain View, CA, America/Los_Angeles.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to geolocate (e.g. 8.8.8.8 or 2001:4860:4860::8888) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds value by naming the data source (NetLoc8's edge network) and detailing return fields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and result, zero wasted words. Includes an example. Exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description fully covers purpose, usage, parameter, and expected results. Sibling tools are listed. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'ip' is 100% with its own description. Description adds an example and mentions IPv4/IPv6, but does not fundamentally enhance understanding beyond schema. Baseline score due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'look up' and resource 'geolocation data for an IPv4 or IPv6 address', lists returned fields, and distinguishes from siblings like geolocate_me. High specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use this when you need the physical location of an IP address' and provides an example. No explicit when-not-to-use, but context is clear. Sibling tool names provide additional orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up geolocation data for this machine's public IP address using NetLoc8. Returns the same rich data as geolocate_ip (country, city, coordinates, ASN, EU status). Useful for determining the developer's location or the server's egress point. No arguments required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds value by detailing the return data fields (country, city, coordinates, ASN, EU status) and noting no arguments required, which is not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose, no redundant information. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides all necessary context: what it does, what data it returns, and typical use cases. Annotations cover safety. Complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description confirms 'No arguments required', which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up geolocation data for 'this machine's public IP', using a specific verb 'Look up' and resource. It distinguishes from the sibling 'geolocate_ip' by specifying the scope is the local machine's IP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions two use cases: determining developer location or server egress point. It implies that for other IPs one should use 'geolocate_ip', providing context without explicit when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive the /24 CIDR prefix from an IPv4 address (e.g. 8.8.8.8 → 8.8.8.0/24). For IPv6 or invalid addresses, returns a message explaining why no /24 subnet applies. Runs locally — no API call, no quota usage.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds value by confirming local execution (no API/quota) and handling of IPv6/invalid inputs, which goes beyond structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two concise sentences. The first sentence directly states the primary function with an example; the second covers edge cases and execution context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple computational tool with 1 parameter and no output schema, the description covers purpose, edge cases, and execution constraints (local, no quota). All essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'ip' parameter. Description adds meaning by explaining the result is a computed /24 for IPv4 and an error message otherwise, providing context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool derives a /24 CIDR prefix from an IPv4 address with an explicit example. It also specifies behavior for IPv6/invalid addresses, distinguishing it from sibling tools that perform geolocation or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions local execution and no quota usage, implying use when network call avoidance is desired. However, it does not explicitly state when not to use it or compare to alternatives like validate_ip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the IANA timezone string for an IP address. Lighter than a full geolocate_ip call when you only need the timezone. Useful for scheduling, date formatting, or timezone-aware code. Example: ip="8.8.8.8" → "America/Los_Angeles".
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds that it's lighter than geolocate_ip and provides an example input/output, which adds performance and usage context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences plus an example line. No extraneous information. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema and annotations, the description covers purpose, usage, and output. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the ip parameter. The description reinforces the example (ip='8.8.8.8') and output format, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the IANA timezone string for an IP address' and distinguishes from sibling tool geolocate_ip by noting it's lighter. The name and title align.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'when you only need the timezone', and lists use cases: scheduling, date formatting, timezone-aware code. Contrasts with geolocate_ip as a heavier alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an IP address is publicly routable. Rejects RFC1918, CGNAT, loopback, link-local, and ULA addresses. Example: ip="8.8.8.8" → public, ip="192.168.1.1" → private. Runs locally — no API call, no quota usage.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly and idempotent hints. Description adds critical behavioral detail: runs locally, no API call, no quota usage, and lists specific address types rejected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Front-loaded with purpose, then examples and key behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean check with one parameter, the description covers purpose, expected inputs, outputs, and performance characteristics completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single parameter 'ip' fully. Description does not add new parameter details beyond confirming the examples match the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Check if an IP address is publicly routable'). Immediately distinguishes from siblings like geolocate_ip and validate_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example usage and explains what addresses are rejected. Lacks explicit when-not-to-use guidance, but context is strong enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize an IP address string: strip brackets, remove IPv4-mapped prefix (::ffff:), trim whitespace, and lowercase. Runs locally — no API call, no quota usage.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: the tool operates locally with no API call or quota usage, and details the exact transformations applied (strip brackets, remove IPv4-mapped prefix, trim, lowercase). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence states the main action and details, the second adds usage context. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one parameter, no output schema), the description is complete. It explains the transformation, local execution, and zero cost. Sibling tools cover different operations, so no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'ip'. The description adds meaning by explaining what normalization does to the IP string, which complements the schema. However, it does not add further per-parameter semantics beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Normalize') and resource ('IP address string'), and lists clear actions (strip brackets, remove prefix, trim, lowercase). It distinguishes normalize_ip from sibling tools like geolocate_ip or validate_ip by focusing on transformation rather than lookup or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Runs locally — no API call, no quota usage', guiding the agent to use this tool when a quick, cost-free normalization is needed versus alternatives that may involve external calls. Exclusions are implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a string is a valid IPv4 or IPv6 address. Returns a human-readable message stating whether the input is valid. Useful for input validation before making a geo lookup. Example: ip="8.8.8.8" → valid, ip="not-an-ip" → invalid. Runs locally — no API call, no quota usage.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | the IPv4 or IPv6 address to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it runs locally with no API call or quota usage, providing extra behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and output, then use case, then examples/performance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with full schema coverage, no output schema, and clear annotations, the description fully covers what the tool does, when to use it, and its local execution nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds examples and clarifies that the parameter is the input to validate, providing more meaning than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a string is a valid IPv4 or IPv6 address, using specific verb 'check' and resource 'IP address'. It distinguishes from sibling tools (geolocate, subnet, etc.) by focusing on validation only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests using before a geo lookup, and notes it runs locally with no API call, which aids in deciding when to use. Does not explicitly list alternatives or when-not scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0geolocate_ipgeolocate_meget_subnetget_timezoneis_public_ipnormalize_ipvalidate_ipScored across 7 tools
All tools have clearly distinct purposes: full geolocation (geolocate_ip, geolocate_me), subnet derivation, timezone lookup, public IP check, normalization, and validation. No overlap in functionality.
Tool names follow a consistent verb_noun snake_case pattern: geolocate_ip, get_subnet, is_public_ip, normalize_ip, validate_ip. The pattern is uniform and predictable.
With 7 tools, the server is well-scoped for IP geolocation and utility tasks. Each tool serves a distinct need without being too few or too many.
The tool set covers essential IP operations: geolocation (full and for current machine), subnet info, timezone, validation, normalization, and public/private check. No obvious gaps for common use cases.
The official Model Context Protocol server for Ambee. It gives any MCP-compatible AI assistant — Claude, ChatGPT, Cursor, VS Code, Ollama, and more direct access to live air quality, pollen, and weather data. To get started, including information on signing up and obtaining your Ambee key, check out the Ambee documentation on https://docs.ambeedata.com
IPStack MCP Adapter turns IPStack's REST APIs into Model Context Protocol tools so any MCP-compatible client can call them directly in conversation. The first release ships IPStack IP geolocation and security lookups (single IP, caller's IP, and bulk). Additional APILayer services are added by registering them in a single config file, so the catalog grows without client-side changes.
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
