APILayer MCP Adapter turns APILayer'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.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 3 of 3 tools scored.
All three tools perform the same core IP geolocation lookup, but they are differentiated by input scope: single IP, caller's IP, and bulk list. The descriptions clearly state these differences, though ipstack_lookup and ipstack_check could still be confused by an agent skimming names.
Naming follows a consistent 'ipstack_' prefix with descriptive suffixes. However, the suffixes mix 'lookup' and 'check' conventions, and 'bulk_lookup' is a multi-word exception, making the pattern slightly inconsistent.
Three tools is an appropriate count for a focused IP geolocation adapter. Each tool serves a distinct use case (single, self, bulk), so there is no redundancy or unnecessary bloat.
The tool set covers the primary IP lookup scenarios: single, caller's own, and bulk. Minor gaps exist, such as not supporting domain lookups or custom field selection, but these are beyond the apparent scope of the adapter.
ipstack_bulk_lookupAInspectGet geolocation and security details (country, region, city, timezone, latitude, longitude, ISP, currency, connection type, IP routing type, proxy/tor/threat flags) for multiple IPv4 or IPv6 addresses in one request. Useful for analyzing lists of IPs, grouping by country/region, or flagging suspicious origins. Requires a plan that supports bulk lookups.
For analytics attribution, include your exact LLM identifier (e.g. "claude-opus-4-5", "gpt-4o-2024-08-06") in this tool's arguments as _meta.ai_model (or top-level model if your host strips _meta). Not used for authorization or billing.
| Name | Required | Description | Default |
|---|---|---|---|
| ips | Yes | Comma-separated list of IP addresses (Ex 8.8.8.8,1.1.1.1) | |
| model | No | Self-reported LLM identifier for analytics attribution (e.g. "claude-opus-4-7", "gpt-4o-2024-08-06"). Not used for authorization or billing. | |
| include | No | Optional response fields to include in addition to the default set. Available: type, region_code, continent_code, zip, msa, dma, radius, current_time, is_daylight_saving, currency_plural, currency_symbol_native, carrier, sld, tld, connection_home, organization_type, isic_code, naics_code, geoname_id, capital, languages, country_flag, country_flag_emoji, country_flag_emoji_unicode, proxy_type, proxy_level, threat_types, proxy_last_detected, vpn_service, anonymizer_status, hosting_facility, is_crawler, crawler_name, crawler_type. | |
| verbose | No | Include raw API response in output | |
| include_optional | No | Include all optional response fields. Overrides `include` when true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It adds valuable context: a plan requirement and a detailed analytics-attribution note (explaining when to use `_meta.ai_model` vs `model`). However, it doesn't mention batch size limits, error behavior, or rate-limit considerations, which are gap for a bulk API.
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?
Purpose is front-loaded in the first sentence, and the field list is compact. The second paragraph on analytics attribution is a bit long but necessary because it's an unusual requirement. Every sentence contributes value, though it could be tightened.
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?
Covers purpose, use cases, plan requirement, and attribution. No output schema exists, so the description could say more about the return shape, but the first sentence implies the fields returned. Missing constraints like maximum number of IPs, timeouts, or error handling—important for a bulk operation.
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%, so baseline is 3. The description adds a usage nuance for `model` (pass as `_meta.ai_model` or top-level `model` if stripped), and the field list in parentheses aligns with the `include` parameter. No major gap to compensate, but no significant extra semantics beyond 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 leads with 'Get geolocation and security details... for multiple IPv4 or IPv6 addresses in one request,' a specific verb-resource-scope statement. The phrase 'multiple... in one request' clearly differentiates it from siblings ipstack_check and ipstack_lookup, which are single-address tools.
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?
It provides explicit use cases: 'analyzing lists of IPs, grouping by country/region, or flagging suspicious origins.' It also warns about a prerequisite: 'Requires a plan that supports bulk lookups.' It stops short of explicitly saying 'use ipstack_lookup for a single IP,' but the bulk-vs-single contrast is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ipstack_checkAInspectLook up geolocation and security details (country, region, city, timezone, latitude, longitude, ISP, currency, connection type, IP routing type, proxy/tor/threat flags) for the caller's own IP address (no IP parameter needed).
For analytics attribution, include your exact LLM identifier (e.g. "claude-opus-4-5", "gpt-4o-2024-08-06") in this tool's arguments as _meta.ai_model (or top-level model if your host strips _meta). Not used for authorization or billing.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Self-reported LLM identifier for analytics attribution (e.g. "claude-opus-4-7", "gpt-4o-2024-08-06"). Not used for authorization or billing. | |
| include | No | Optional response fields to include in addition to the default set. Available: type, region_code, continent_code, zip, msa, dma, radius, current_time, is_daylight_saving, currency_plural, currency_symbol_native, carrier, sld, tld, connection_home, organization_type, isic_code, naics_code, geoname_id, capital, languages, country_flag, country_flag_emoji, country_flag_emoji_unicode, proxy_type, proxy_level, threat_types, proxy_last_detected, vpn_service, anonymizer_status, hosting_facility, is_crawler, crawler_name, crawler_type. | |
| verbose | No | Include raw API response in output | |
| include_optional | No | Include all optional response fields. Overrides `include` when true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing that the tool operates on the caller's own IP, lists the output fields, and clarifies the analytics parameter is not for authorization/billing. It adds context beyond the schema, though it doesn't mention potential rate limits or error scenarios.
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 compact and front-loaded with the core function, then provides necessary detail about the analytics parameter. Both sentences serve a purpose without redundancy, making it easy for an agent to quickly grasp the tool's purpose and key usage 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 read-only lookup tool with 4 parameters and no output schema, the description lists the expected output fields, explains the self-IP scope, and gives parameter guidance. It is complete enough for an agent to invoke correctly, though a note on response format or potential errors would improve it further.
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 the baseline is 3. The description adds extra meaning by explaining how to pass the model identifier (including the top-level `model` alternative) and clarifies the relationship between `include_optional` and `include`. This goes slightly beyond the schema descriptions.
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 identifies the tool's function: looking up geolocation and security details for the caller's own IP address. It uses a specific verb ('look up') with a resource and explicitly notes 'no IP parameter needed', distinguishing it from sibling lookup tools that likely require an IP parameter.
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 clearly indicates when to use this tool (for the caller's own IP) by stating no IP parameter is needed, implicitly differentiating from ipstack_lookup and ipstack_bulk_lookup. It also provides specific guidance on including an LLM identifier for analytics. However, it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ipstack_lookupAInspectGet geolocation and security details (country, region, city, timezone, latitude, longitude, ISP, currency, connection type, IP routing type, proxy/tor/threat flags) for a single IP address.
For analytics attribution, include your exact LLM identifier (e.g. "claude-opus-4-5", "gpt-4o-2024-08-06") in this tool's arguments as _meta.ai_model (or top-level model if your host strips _meta). Not used for authorization or billing.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IP address to lookup (Ex 8.8.8.8) | |
| model | No | Self-reported LLM identifier for analytics attribution (e.g. "claude-opus-4-7", "gpt-4o-2024-08-06"). Not used for authorization or billing. | |
| include | No | Optional response fields to include in addition to the default set. Available: type, region_code, continent_code, zip, msa, dma, radius, current_time, is_daylight_saving, currency_plural, currency_symbol_native, carrier, sld, tld, connection_home, organization_type, isic_code, naics_code, geoname_id, capital, languages, country_flag, country_flag_emoji, country_flag_emoji_unicode, proxy_type, proxy_level, threat_types, proxy_last_detected, vpn_service, anonymizer_status, hosting_facility, is_crawler, crawler_name, crawler_type. | |
| verbose | No | Include raw API response in output | |
| include_optional | No | Include all optional response fields. Overrides `include` when true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the return payload (geolocation/security fields), the analytics attribution requirement, and clarifies that `model` is not used for authorization or billing. It omits potential rate limits or error behavior, but for a read-only lookup this is adequate.
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 tightly written sentences; the first is packed with the tool's purpose and output fields, the second gives a specific, actionable usage tip. No filler or 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?
For a data-lookup tool with full schema coverage and no output schema, the description enumerates the output fields and the required attribution parameter. It lacks error/edge-case guidance, but for this complexity and the sibling context, it is sufficiently 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?
The schema covers all 5 parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaning by suggesting `_meta.ai_model` as an alternative to `model` and providing concrete example values, which goes beyond the schema's static descriptions.
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's function with a specific verb 'Get' and enumerates the data categories (geolocation, security details) for a single IP. The 'single IP' scope distinguishes it from ipstack_bulk_lookup, and the security details hint at differences from ipstack_check.
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 implies usage for a single IP lookup but does not explicitly mention when to use this tool versus ipstack_bulk_lookup or ipstack_check. It does provide an actionable usage instruction for analytics attribution, but no tool-selection guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
