Skip to main content
Glama

Walk the Graph

pointrover_graph
Read-only

Returns many connected pieces at once, such as what the business buys and what is upstream of it, its wages, rules and locations, and how each links to the next. Use this when the assistant is weighing many things together, such as everything moving against the business beyond its usual range. Not for the business's own books: invoices, bank, payroll or accounting live in its accounting connector, not here. Nor is it search: this walks many items and their connections, at more cost; one item is cheaper through search and fetch. Each item comes with its figure, how unusual its move is, which way it cuts, and whether it is preliminary, corrected or withheld. Pass start (string id; default the business), edges (array of edge kinds), depth (integer 1 to 3, default 1), where (up to 4 filters, OR between them, AND within), detail (concise or full) and token_budget (integer). Example: pointrover_graph({"depth": 2, "where": [{"band_at_least": "unusual", "direction": "against"}, {"kind": ["event"], "state": ["open"]}]}). About 3000 tokens by default and up to 12000; anything trimmed is stated. County demand readings and what they support are described in the docs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pointrover_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNoHow many edges out to walk. Default 1, capped at 3.
edgesNoWhich edge kinds to follow; only these are served. Omit to follow this business's own edges, the industry's typical items left out and counted. The vocabulary is the read model's own: supplies and consumes are stored arcs; the rest are the fixed verbs the board already draws for each collection.
startNoThe record id to walk from, as search, fetch or pointrover_brief returns them. Defaults to this business's own node. The company handle from any answer is accepted here too.
whereNoFilters over states this contract already serves. Fields inside ONE filter are joined by AND; the list is joined by OR, which is how one call asks about records of several shapes at once. Every field is optional. A single filter object is accepted here as well as a list of one.
detailNoconcise is the default and gives each node its identity, figure and states. full adds each node's whole record, which buys fewer nodes for the same budget.
token_budgetNoEstimated-token ceiling for the answer. Default 3000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond readOnlyHint=true it discloses the cost profile (about 3000 tokens by default, capped at 12000, with any trimming stated) and the shape of each returned item (figure, how unusual the move is, which way it cuts, and whether the value is preliminary, corrected or withheld). It also explains the edge vocabulary semantics — supplies/consumes are stored arcs while the rest are fixed verbs the board draws — which is real behavioral context, not restated annotations.

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?

It is front-loaded with purpose, then exclusions, then parameters, then an example, which is the right ordering. Most sentences earn their place, but the parameter sentence duplicates defaults already in the schema, and the closing line about county demand readings being 'described in the docs' is a vague dangling pointer that adds no actionable information.

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?

For a six-parameter traversal tool with no output schema, the description covers what comes back, how budget and trimming work, defaults for every parameter, the exclusion boundaries against three siblings, and a concrete example. Nothing an agent needs in order to call it correctly is missing.

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 earns above that by showing a worked example call that demonstrates how `where` filters compose, and by explaining the consequence of omitting `edges` (this business's own edges, industry-typical items left out and counted). Some sentences merely restate schema defaults (depth 1, detail concise/full, token_budget 3000), which keeps it from a 5.

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 states a concrete verb and resource — it walks/returns many connected items and the edges linking them — and enumerates example content (buys, upstream, wages, rules, locations). It explicitly separates itself from search/fetch and from an accounting connector. The phrasing is indirect ('connected pieces', 'walks many items') rather than saying plainly that it traverses a graph from a start node, so it falls just short of a 5.

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?

It gives an explicit when: weighing many things together, e.g. everything moving against the business beyond range. It gives explicit when-nots: the business's own books belong to the accounting connector, and single-item lookups should go through search and fetch because they are cheaper. Cost is named as the discriminator, which is exactly the routing signal an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.