Run a geolocation check from a specified node to determine the location of an IP address. Use this to verify outbound IP geolocation or test a given IP from a node's network interface.
Run a geolocation check from a node (async job; requires node 3.3.0+)
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | IP address to check (defaults to the node outbound IP) | |
| nodeUuid | Yes | Node UUID to run the check from | |
| interface | No | Network interface to use |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses the async nature ('async job') and a version constraint ('requires node 3.3.0+'), which is useful. However, it does not explain what happens on failure, how results are obtained, or the response structure. Lacks critical behavioral details for an async operation.
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, compact sentence that front-loads the core action. It avoids redundancy and is efficient, though it omits useful context like result retrieval.
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 output schema and async behavior, the description should mention how to obtain results (e.g., via connections_get_geocheck_result) and any prerequisites. The version note is helpful, but the missing relationship to result retrieval leaves a gap for agent execution.
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 all parameters already have descriptions. The tool description adds no extra parameter semantics, which aligns with the baseline of 3 when the schema handles parameter documentation.
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 ('Run a geolocation check') and the resource ('from a node'), which is specific and distinguishes it from fetching results. However, it does not explicitly differentiate from sibling tools like connections_get_geocheck_result, though 'async job' hints at the separation.
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 notes the async nature and the version requirement, which gives context on when to use it. It does not explicitly mention alternatives or when not to use it, such as referencing connections_get_geocheck_result for retrieving results. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.