GreenlandAI

hops

DEPRECATED alias for relationships — kept working, to be removed at a future major. Use relationships. Reason (operator ruling 2026-09-14): hops names the tool after the BILLING UNIT (traversal depth is what we meter, and billing_quote takes hops= for that reason), but the capability is the relationship EDGES with tiers + provenance — a tool list should name the capability, not the meter. Identical behavior and params to relationships (incl. an unknown relation_type = 400 on both paths, before any charge; entity_type + entity_id pin one entity, and a name matching several is a 409 listing the candidates, nothing charged); also the SDK helper name. ⚠ CHARGING: the meter RESERVES before the query runs and SETTLES after delivery for what was actually delivered (an empty result settles to 0; a partial traversal settles for the hops delivered; a 4xx releases the reservation). An abandoned or timed-out call still settles once the backend delivers. A replay is served free only for the SAME credential + SAME idempotency key + SAME request within 15 minutes — a different payer is a different payer. Every call through this relay carries a fresh key, so a retry here is always a new charge. Price with billing_quote first; verify any charge with the billing_attempts tool (own wallet: reserved vs settled, per attempt). WHAT YOU PAID: the JSON response carries a top-level charged_joules — the all-in PRICE of this call — and a metering block written AFTER the settle has run: {attempt_id, settlement, settled_joules, check}. metering.settlement is whether you PAID: settled · settled_zero (empty result, nothing moved) · settle_failed (delivered but UNPAID — the wallet is then locked until it clears; the next metered call 402s naming the attempt, the amount and what clears it) · released (4xx/5xx, nothing moved) · unknown. settled_joules is what actually left the wallet (0 unless settled). A cached replay carries no block.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`hops`	No
`as_of`	No
`limit`	No
`entity`	No
`offset`	No
`search`	No
`entity_id`	No
`entity_type`	No
`relation_type`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / as_of

Added value: +{
+  "default": null,
+  "title": "As Of",
+  "type": "string"
+}

Changed2 schema fields changedOct 1, 2026

addedInput schema / properties / entity_id

Added value: +{
+  "default": null,
+  "title": "Entity Id",
+  "type": "string"
+}

addedInput schema / properties / entity_type

Added value: +{
+  "default": null,
+  "title": "Entity Type",
+  "type": "string"
+}

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "hopsDictOutput",
+  "type": "object"
+}

First observedSep 14, 2026

TDQS

A4.5/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full behavioral burden and does so richly: reserve-before/settle-after metering, empty result settles to 0, 4xx releases, abandoned/timeout calls still settle, replay free only for same credential+key+request within 15 minutes, and the settle_failed wallet-lock / 402 behavior. This is unusually complete for a zero-annotation tool.

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?

Front-loaded with the deprecation and migration guidance, then the charging model, which is genuinely necessary given zero annotations. The operator-ruling rationale is somewhat editorially verbose, but the metering detail earns its place; no true redundancy.

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?

An output schema exists, yet the description still explains `charged_joules` and the `metering` block fields, and it covers error semantics and deprecation fully. The remaining gap is the undocumented execution parameters (limit/offset/search/as_of/entity), which keeps this from a 5.

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 0% across 9 params, so the description is the only source. It adds real meaning for `hops` (traversal depth = metered unit), `relation_type` (unknown value = 400 before charge), and `entity_type`+`entity_id` (pinning, multi-match = 409), but leaves `limit`, `offset`, `as_of`, `search`, and `entity` entirely undocumented. Partial compensation only.

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 immediately names the tool as a deprecated alias for `relationships` and explains why the naming was ruled wrong (billing unit vs. capability), so an agent understands exactly what the tool is. It is distinguishable from the `relationships` sibling without opening either schema.

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?

Explicit routing instruction: 'Use `relationships`' with the deprecation rationale, and the condition under which this alias still works. It also states identical behavior/params, so the agent knows migration is safe. Nothing is left to inference.

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

All GreenlandAI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?