Skip to main content
Glama
iplocate

IPLocate

Official
by iplocate

Look up IP Address Abuse Contacts

lookup_ip_address_abuse_contacts

Report malicious IP activity by finding network administrator contact details including email, phone, and address for any IPv4 or IPv6 address.

Instructions

Get abuse contact information for an IP address to report malicious activity. Includes email, phone, and address of the network administrator. Can look up any IPv4 or IPv6 address, or your own IP if no address is provided.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ipNoIPv4 or IPv6 address to look up. If not provided, returns information about the caller's IP address.

Implementation Reference

  • Handler function that validates the input IP address, fetches IP data using fetchIPData, extracts the 'abuse' contacts information, and returns it as formatted JSON or an error message.
    async ({ ip }) => {
      if (ip && !isValidIP(ip)) {
        return {
          content: [{
            type: "text",
            text: `Error: "${ip}" is not a valid IPv4 or IPv6 address.`
          }],
          isError: true
        };
      }
    
      try {
        const data = await fetchIPData(ip);
        const abuseData = {
          ip: data.ip,
          abuse: data.abuse
        };
    
        return {
          content: [{
            type: "text",
            text: JSON.stringify(abuseData, null, 2)
          }]
        };
      } catch (error) {
        return {
          content: [{
            type: "text",
            text: `Error: ${error instanceof Error ? error.message : String(error)}`
          }],
          isError: true
        };
      }
    }
  • src/index.ts:327-368 (registration)
    Registers the 'lookup_ip_address_abuse_contacts' tool with the MCP server, including title, description, input schema, and inline handler function.
    server.registerTool(
      "lookup_ip_address_abuse_contacts",
      {
        title: "Look up IP Address Abuse Contacts",
        description: "Get abuse contact information for an IP address to report malicious activity. Includes email, phone, and address of the network administrator. Can look up any IPv4 or IPv6 address, or your own IP if no address is provided.",
        inputSchema: IPAddressSchema
      },
      async ({ ip }) => {
        if (ip && !isValidIP(ip)) {
          return {
            content: [{
              type: "text",
              text: `Error: "${ip}" is not a valid IPv4 or IPv6 address.`
            }],
            isError: true
          };
        }
    
        try {
          const data = await fetchIPData(ip);
          const abuseData = {
            ip: data.ip,
            abuse: data.abuse
          };
    
          return {
            content: [{
              type: "text",
              text: JSON.stringify(abuseData, null, 2)
            }]
          };
        } catch (error) {
          return {
            content: [{
              type: "text",
              text: `Error: ${error instanceof Error ? error.message : String(error)}`
            }],
            isError: true
          };
        }
      }
    );
  • Input schema definition for the tool, accepting an optional IP address string with Zod validation and description.
    const IPAddressSchema = {
      ip: z.string().optional().describe("IPv4 or IPv6 address to look up. If not provided, returns information about the caller's IP address.")
    };
  • TypeScript interface defining the structure of abuse contact information returned by the IPLocate API.
    export interface AbuseInfo {
      address?: string | null;
      country_code?: string | null;
      email?: string | null;
      name?: string | null;
      network?: string | null;
      phone?: string | null;
    }
  • Helper function that makes the HTTP request to the IPLocate API to fetch comprehensive IP address data, which the handler then extracts the abuse contacts from.
    async function fetchIPData(ip?: string): Promise<IPLocateResponse> {
      const baseUrl = "https://iplocate.io/api/lookup";
      const apiKey = process.env.IPLOCATE_API_KEY;
    
      let url = ip ? `${baseUrl}/${ip}` : `${baseUrl}/`;
    
      // Add API key if available
      if (apiKey) {
        url += `?apikey=${apiKey}`;
      }
    
      try {
        const response = await fetch(url, {
          headers: {
            'User-Agent': `mcp-server-iplocate/${VERSION}`
          }
        });
    
        if (!response.ok) {
          const errorText = await response.text();
          let errorMessage = `API request failed with status ${response.status}`;
    
          try {
            const errorJson = JSON.parse(errorText);
            if (errorJson.error) {
              errorMessage = errorJson.error;
            }
          } catch {
            // If not JSON, use the raw text
            if (errorText) {
              errorMessage = errorText;
            }
          }
    
          throw new Error(errorMessage);
        }
    
        const data = await response.json() as IPLocateResponse;
        return data;
      } catch (error) {
        if (error instanceof Error) {
          throw error;
        }
        throw new Error(`Failed to fetch IP data: ${String(error)}`);
      }
    }
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the tool's behavior by explaining what information is returned (email, phone, address) and the default behavior when no IP is provided. However, it doesn't mention rate limits, authentication requirements, or potential limitations of the data source.

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?

The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose and what's included, while the second explains parameter behavior and default case. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (single optional parameter, no output schema, no annotations), the description is reasonably complete. It explains what the tool does, when to use it, what information it returns, and parameter behavior. The main gap is lack of information about response format or potential limitations.

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%, so the schema already documents the single parameter completely. The description adds minimal value by restating that it accepts IPv4/IPv6 addresses and explaining the default behavior, but doesn't provide additional semantic context beyond what's in the schema.

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?

The description clearly states the tool's purpose with specific verbs ('Get abuse contact information') and resources ('IP address'), and distinguishes it from siblings by focusing on abuse contacts rather than company, details, location, network, or privacy information.

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?

The description explicitly states when to use it ('to report malicious activity') and provides clear context on when-not-to-use alternatives by specifying its unique focus on abuse contacts. It also explains the default behavior when no IP is provided, which helps differentiate usage scenarios.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iplocate/mcp-server-iplocate'

If you have feedback or need assistance with the MCP directory API, please join our Discord server