Running Cat Geo

Plan a round trip

plan_loop

Read-only

A round trip from one start back to it, of about distanceKm (5 to 200 km), when there is no destination: "a 60 km gravel ride from here". It sets off towards direction (degrees, 0 = north, 90 = east); another direction gives another loop, and when no loop fits the length the server tries other directions itself. Returns length, climb, duration, kilometres paved, unpaved and unknown, and an outline of about 40 [lon, lat] points; with report it adds the same parts as plan_route. Use plan_route when there are waypoints to pass or a different finish. Counts once per started 100 km; each report part counts one request.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start": "<start>",
      "distanceKm": "<distanceKm>"
    },
    "name": "plan_loop"
  }
}

Input Schema

Name	Required	Description
`start`	Yes	Start and finish as [lon, lat]
`report`	No	Report parts about the loop found; none by default
`profile`	No	Default bike
`speedKmh`	No	Average speed for the weather timing, default 20
`departure`	No	ISO time with offset, for the weather; now by default
`direction`	No	Degrees, 0 = north; default 0
`distanceKm`	Yes	Length of the loop in km, 5 to 200; the server tries a few times to come within 10% of it and returns the closest loop

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: the ~10% length tolerance and server-side retries, the exact shape of the return (length, climb, duration, surface breakdown, ~40-point outline), what report adds on top, and the credit cost rule (once per started 100 km, each report part one request). That cost and retry disclosure is exactly the behavior an agent needs before invoking.

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?

Purpose and the plan_route alternative are front-loaded, and every clause carries information (tolerance, return shape, cost). It is dense and reads as one long run-on with minor awkwardness ('of about distanceKm', 'kilometres paved'), so it is efficient but not maximally clean.

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?

No output schema exists, yet the description fully enumerates the return fields and the outline point count, covers the optional report expansion, and discloses billing. For a 7-parameter planning tool this leaves nothing an agent needs unknown before calling.

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%, so the baseline is 3; the description still adds real meaning by explaining that direction (degrees, 0 = north) yields a different loop and that varying it is the way to get alternatives, plus that report parts each cost a request. It does not restate profile/speed/departure semantics, which the schema already covers.

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?

Opens with a concrete verb+resource: a round trip from one start back to it, sized by distanceKm. It immediately scopes the case ('when there is no destination: a 60 km gravel ride from here') and names the sibling that handles the different case, so an agent can distinguish it from plan_route 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?

Gives both the selecting condition ('when there is no destination') and the exclusion with the alternative ('Use plan_route when there are waypoints to pass or a different finish'). It also states a fallback behavior (server tries other directions when no loop fits), which tells the agent it does not need to retry manually.

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

All Running Cat Geo 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?