Skip to main content
Glama

cpu_next_hops

Survey legal next waypoints from a cell. Lists eligible revealed cells and Hubs within one hop under the reach rule, with hop distance, owner, fee, and optional compass to a destination.

Instructions

Survey the legal next waypoints from a cell (read-only). Lists every eligible waypoint — your revealed cells and all Hubs — within one hop under the reach rule: hop ≤ radius(from)+radius(to)−1 grid steps (default balance: own↔own 1 = adjacent only, own↔hub 3, hub↔hub 5). Foreign cells are never waypoints, so even a single foreign cell between two plain cells is a WALL — only a Hub reaches across; empty hops means goods can only be hauled up to here. Facts per candidate: hop distance, owner, hub flag, per-unit transit fee, and — with towards — the remaining grid distance (a compass, not a route). Planning is YOUR job: pick each hop yourself (cheap vs short vs whose hub you trust), chain them into path, and verify with cpu_quote_transport. To break a wall: build a border Hub (it still needs an eligible landing cell within reach on the far side), buy land across, or go around. WHEN: the cheap point check — call it right before each leg and after cpu_get_changes shows movement (hubs get demolished, fees change while goods travel); replan via cpu_route_network only when a local fix is impossible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromYesThe cell to hop from (your revealed cell, or a Hub).
towardsNoOptional destination — adds the remaining grid distance to it for each candidate (a compass).
Behavior5/5

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

No annotations provided, so description carries full burden. It explains read-only nature, reach rule, what facts are returned (hop distance, owner, hub flag, fee, and remaining grid distance with towards), and edge cases like foreign cells acting as walls.

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?

Description is lengthy but front-loaded with purpose. Every sentence adds value given complexity, though could be more terse. No redundancy.

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

Completeness5/5

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

Given no output schema, description fully explains return facts, interactions with sibling tools (cpu_get_changes, cpu_route_network), and strategies for handling walls. Complete for planning and invocation.

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

Parameters4/5

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

Schema coverage is 100%, but description adds context: clarifies that 'towards' adds remaining grid distance as a compass not a route. Also explains usage semantics not in schema (e.g., pick each hop yourself). Slightly above baseline.

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 starts with 'Survey the legal next waypoints from a cell (read-only)', a specific verb and resource. It clearly distinguishes from siblings like cpu_route_network and cpu_quote_transport by stating when each is appropriate.

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 'WHEN' clause: 'call it right before each leg and after cpu_get_changes shows movement; replan via cpu_route_network only when a local fix is impossible.' Also explains when not to use it and alternatives.

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/sodiqit/project-cpu-mcp'

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