Skip to main content
Glama

what_is_my_ip_tool

Retrieve your client's public IP address and request metadata instantly for agent discovery. Free, zero-auth, sub-50ms response.

Instructions

    [Free / Zero Auth] Return client's public IP and request metadata for agent discovery
    Sub-50ms deterministic machine execution.

    Args:
        input_data: Target payload or query string.
        parameters: Optional dictionary or JSON string of execution arguments.
        payment_signature: Optional x402 Base USDC transaction hash (defaults to developer mock key).
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
input_dataYes
parametersNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose zero-auth, speed, and deterministic execution, which is useful. However, it doesn't explain what 'request metadata' includes, whether any side effects occur, or how the optional payment_signature affects execution beyond being a mock key default.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, leading with the main purpose and then performance characteristics. The Args section is compact and generally adds value given the lack of schema descriptions, with only minimal verbosity.

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

Completeness2/5

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

The tool is relatively simple, but there is no output schema and the description omits response format and the meaning of 'request metadata'. The necessity of the required input_data parameter is unclear, and the payment_signature behavior is only partially described. These are meaningful gaps for an agent deciding whether and how to call the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds types and defaults for parameters and payment_signature, but 'Target payload or query string' for input_data and 'execution arguments' for parameters are generic and fail to explain what values actually influence the IP/metadata result. The semantics are too vague to be actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: 'Return client's public IP and request metadata for agent discovery'. It differentiates the core intent from network-related siblings like whois_lookup or get_node_telemetry_stats by focusing on the client's own IP and request metadata, though it doesn't explicitly name any sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Free / Zero Auth' and 'Sub-50ms deterministic machine execution', which hints at lightweight usage, but it never states when to use this tool versus alternatives or when not to use it. No exclusions or alternative tool references are provided.

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