iplookup
Server Details
IP Lookup MCP — ip-api.com (free, no auth for basic usage)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-iplookup
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.1/5 across 7 of 7 tools scored. Lowest: 2.9/5.
The tools have overlapping purposes that could cause confusion, such as 'geolocate_ip' and 'batch_geolocate' both handling IP geolocation, and 'remember', 'recall', and 'forget' all managing memory operations. However, their descriptions help clarify the distinctions, like single vs. batch processing or specific memory actions, preventing complete ambiguity.
Naming conventions are inconsistent across the tool set, mixing styles like snake_case ('geolocate_ip', 'batch_geolocate') with other formats ('ask_pipeworx', 'discover_tools'). There is no uniform verb_noun pattern, and some names are vague or compound, making the set less predictable and readable.
With 7 tools, the count is reasonable for a server that appears to combine IP lookup with general-purpose utilities. It's slightly broad in scope but manageable, avoiding the extremes of being too thin or overloaded, though it might benefit from tighter focus.
For IP lookup, the surface covers geolocation well with single and batch tools, but lacks other common operations like DNS resolution or IP reputation checks. The inclusion of memory and query tools adds functionality but creates a mixed domain, making it incomplete for a pure IP lookup server while offering broader utility.
Available Tools
7 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that Pipeworx 'picks the right tool, fills the arguments, and returns the result,' which describes the tool's decision-making process. However, it doesn't mention limitations like rate limits, authentication requirements, or potential accuracy constraints. The behavioral description is helpful but not comprehensive.
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 efficiently structured: the first sentence states the core functionality, the second explains the mechanism, the third provides usage guidance, and the fourth gives examples. Every sentence adds value, and there's no redundant information. The description is appropriately sized for a single-parameter tool.
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 tool's complexity (natural language processing with backend tool selection), no annotations, and no output schema, the description does well but has gaps. It explains the tool's purpose and usage clearly but doesn't describe the format or structure of returned answers, potential limitations, or error conditions. For a tool that abstracts multiple data sources, more context about reliability and scope would be helpful.
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 input schema has 100% description coverage, so the baseline is 3. The description adds value by providing context about the parameter: it should be 'a question or request in natural language' and gives concrete examples ('What is the US trade deficit with China?', etc.). This enhances understanding beyond the schema's basic 'Your question or request in natural language' 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 clearly states the tool's purpose: 'Ask a question in plain English and get an answer from the best available data source.' It specifies the verb ('ask'), resource ('answer'), and mechanism ('Pipeworx picks the right tool, fills the arguments'). It distinguishes itself from siblings by emphasizing natural language processing rather than requiring specific tool selection or schema knowledge.
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 provides explicit guidance on when to use this tool: 'No need to browse tools or learn schemas — just describe what you need.' It contrasts with alternatives by stating users should use this when they want to ask questions in plain English rather than using specific tools. The examples further illustrate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_geolocateAInspect
Look up locations for up to 100 IP addresses at once. Returns geolocation and ISP data in the same order as input. Use for analyzing multiple IPs efficiently.
| Name | Required | Description | Default |
|---|---|---|---|
| ips | Yes | Array of IPv4 or IPv6 addresses to look up (maximum 100) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the batch processing capability, input limit (100 IPs), and output ordering (same order as input). However, it lacks details on error handling, rate limits, or authentication requirements, which are common for API tools, leaving some behavioral aspects unclear.
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 highly concise and well-structured in two sentences. The first sentence states the core functionality and constraint, while the second explains the output format. Every word earns its place with no redundancy, making it easy for an agent to parse and understand quickly.
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 tool's moderate complexity (batch processing with a limit), no annotations, and no output schema, the description is largely complete. It covers purpose, usage, input constraints, and output behavior. However, it lacks details on error responses or example outputs, which would be helpful for an agent to handle edge cases, slightly reducing completeness.
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 input schema has 100% description coverage, clearly documenting the 'ips' parameter as an array of IPv4/IPv6 addresses with a maximum of 100. The description adds minimal value beyond this, only reiterating the limit and input type. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional semantic context like format examples or validation rules.
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 purpose with specific verbs ('look up geolocation') and resources ('multiple IP addresses'), and distinguishes it from the sibling tool 'geolocate_ip' by emphasizing batch processing ('in a single request'). It explicitly mentions the scope ('up to 100 IPs') and output format ('array of results'), making the purpose unambiguous.
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 provides explicit usage guidance by specifying when to use this tool ('for multiple IP addresses in a single request') and implicitly when not to use it (for single IPs, suggesting the sibling 'geolocate_ip' as an alternative). It also sets clear constraints ('up to 100 IPs'), helping the agent choose appropriately based on input volume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns 'the most relevant tools with names and descriptions,' which gives some insight into output behavior, but it lacks details on aspects like rate limits, authentication needs, error handling, or pagination. The description adds basic context but falls short of fully compensating for the absence of 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 front-loaded with the core purpose in the first sentence, followed by a clear usage guideline. Both sentences are essential and contribute directly to understanding the tool's role and application, with no wasted words or redundant information. It is efficiently structured and appropriately sized for its function.
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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers the purpose, usage guidelines, and basic behavioral context effectively. However, without annotations or an output schema, it could benefit from more details on the return format or error conditions, slightly limiting completeness for a search 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?
Schema description coverage is 100%, so the schema already documents both parameters (query and limit) thoroughly. The description does not add any additional meaning or clarification beyond what the schema provides, such as examples or usage tips for the parameters. This meets the baseline score of 3, as the schema handles the parameter documentation adequately.
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 specific action ('Search the Pipeworx tool catalog'), the resource ('tool catalog'), and the method ('by describing what you need'), distinguishing it from sibling tools like batch_geolocate and geolocate_ip. It explicitly mentions returning 'the most relevant tools with names and descriptions,' making the purpose unambiguous and distinct.
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 provides explicit guidance on when to use this tool ('Call this FIRST when you have 500+ tools available and need to find the right ones for your task'), including a specific condition (500+ tools) and a clear alternative scenario (using it as an initial step). This directly addresses when to use it versus other tools, offering strong contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetCInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a deletion operation, implying it's destructive, but doesn't specify whether deletion is permanent, reversible, requires confirmation, or has side effects. For a destructive tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple deletion operation and is front-loaded with the essential action. Every word earns its place in this minimal but complete statement.
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 destructive operation with no annotations and no output schema, the description is insufficiently complete. It doesn't address what happens after deletion (success/failure indicators), whether the operation is idempotent, or what constitutes a valid memory key. The agent lacks critical context needed to use this tool safely and effectively.
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%, with the single parameter 'key' fully documented in the schema as 'Memory key to delete'. The description adds no additional semantic context beyond what's already in the schema (e.g., key format, examples, or constraints). Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 action ('Delete') and resource ('a stored memory by key'), making the purpose immediately understandable. It distinguishes from sibling 'recall' (which retrieves) and 'remember' (which stores), though doesn't explicitly mention these alternatives. The verb+resource combination is specific but could be more precise about what type of memory is being deleted.
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 provides no guidance on when to use this tool versus alternatives. While it's clear this deletes memories, there's no mention of prerequisites (e.g., memory must exist), consequences, or when to choose deletion over other operations. The agent must infer usage from the purpose alone without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geolocate_ipAInspect
Look up an IP address to find its location and network details. Returns country, region, city, coordinates, timezone, ISP, and AS number. Use when you need to identify where a user or server is located.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address to look up (e.g., "8.8.8.8", "2001:4860:4860::8888") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return data (country, region, city, etc.), which is useful behavioral context. However, it lacks details on rate limits, error handling, or data freshness, leaving gaps in transparency for a network-dependent tool.
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 a single, well-structured sentence that efficiently conveys purpose, scope, and return values without redundancy. Every element serves a clear informational role, making it highly concise.
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 tool's low complexity (one parameter, no annotations, no output schema), the description is reasonably complete. It covers purpose, input type, and return data. However, without an output schema, it could benefit from more detail on response format or limitations.
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 input schema has 100% description coverage, fully documenting the 'ip' parameter with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema 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?
The description clearly states the verb 'look up' and the resource 'geolocation, ISP, and network information for a single IP address', specifying both IPv4 and IPv6 support. It distinguishes from the sibling tool 'batch_geolocate' by emphasizing 'single IP address'.
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 context by stating 'for a single IP address', which suggests this tool is for individual lookups versus batch processing. However, it does not explicitly name the sibling tool 'batch_geolocate' as an alternative or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the dual functionality (retrieve by key vs. list all) and persistence across sessions, which is valuable context. However, it doesn't describe error behavior (e.g., what happens with invalid keys), rate limits, or authentication requirements, leaving some behavioral aspects unclear.
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 efficiently structured in two sentences: the first explains the dual functionality, and the second provides usage context. Every word serves a purpose with no redundancy or unnecessary elaboration.
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 retrieval tool with one optional parameter and no output schema, the description provides adequate context about functionality and usage. It could be more complete by mentioning what format memories are returned in or error handling, but given the tool's simplicity, it covers the essential aspects well.
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 description coverage is 100%, so the schema already documents the optional 'key' parameter. The description adds meaningful context by explaining the semantic difference between providing a key (retrieve specific memory) and omitting it (list all keys), which helps the agent understand when to use each mode.
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 purpose with specific verbs ('retrieve', 'list') and resources ('previously stored memory', 'all stored memories'). It distinguishes from siblings like 'remember' (store) and 'forget' (delete) by focusing on retrieval operations.
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 provides explicit guidance on when to use this tool: 'to retrieve context you saved earlier in the session or in previous sessions.' It also specifies when to omit the key parameter to list all memories, offering clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses persistence differences ('Authenticated users get persistent memory; anonymous sessions last 24 hours'), which is critical for understanding tool behavior beyond basic storage. However, it does not mention rate limits, error conditions, or memory size limits.
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, zero waste: first states purpose with examples, second adds critical behavioral context (persistence rules). Every sentence earns its place, and information is front-loaded appropriately.
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 2-parameter tool with no annotations and no output schema, the description is mostly complete: it covers purpose, usage context, and key behavioral traits (persistence rules). However, it lacks details on return values or error handling, leaving minor gaps given the tool's moderate complexity.
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 the schema already documents both parameters thoroughly. The description does not add meaning beyond what the schema provides (e.g., no additional syntax or format details). Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('Store') and resource ('key-value pair in your session memory'), with specific examples of what to store ('intermediate findings, user preferences, or context across tool calls'). It distinguishes from sibling 'recall' (which likely retrieves) and 'forget' (which likely removes).
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 provides clear context for when to use ('save intermediate findings, user preferences, or context across tool calls'), but does not explicitly state when not to use or name alternatives (e.g., 'forget' for removal). It implies usage across sessions but lacks explicit 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.
Discussions
No comments yet. Be the first to start the discussion!