Skip to main content
Glama
Sign In

PointRover

by com.pointrover
OverviewDiscussionsAdmin

Fetch a Record

fetch
Read-only

Returns everything PointRover holds on one item: its latest figure, its change over a year and how unusual that is, its receipt handle and the events touching it. Use this when the assistant is opening an id that search, pointrover_brief or pointrover_graph returned, to check one input, duty, wage or rule in detail. Not for the business's own books: invoices, bank, payroll or accounting live in its accounting connector, not here. History is in pointrover_series, sources in pointrover_receipt, connections in pointrover_graph. Pass id (string, as an answer gave it), detail (concise, the default; full; origins for an import) and page (integer). Example: fetch({"id": "node:nod_d78067cbf7b5497786a75b140af28e5f"}).

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": {
      "id": "<id>"
    },
    "name": "fetch"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesA record id as this server returns them: "<kind>:<the read model's own id>", for example "series:PCU4441--4441--".
pageNoWhich page of an event's key values, key trail and documents, five of each per page. An import record's measures in force, origins and open reasons page together the same way. Default 1; the record says how many pages there are and the call for the next.
detailNoHow much to return. Default concise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / page / description
      Previous value: -"Which page of an event's key values, key trail and documents, five of each per page. Default 1; the record says how many pages there are and the call for the next."New value: +"Which page of an event's key values, key trail and documents, five of each per page. An import record's measures in force, origins and open reasons page together the same way. Default 1; the record says how many pages there are and the call for the next."
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds real behavioral detail on top: what the response contains, that paging applies to key values/key trail/documents at five per page, and that the record itself reports total pages. It stops short of describing failure modes (missing or malformed id) or latency, which keeps it below 5.

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?

One dense paragraph, front-loaded with the return value and followed by usage, exclusions, alternatives, parameters and an example in a logical order. Nearly every clause carries information, though the exclusion/alternative list and parameter recap make it longer than strictly necessary.

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?

With no output schema, the description must describe return values, and it does so plus paging and detail levels. It lacks guidance on what happens with an unknown id or an empty result, a minor gap for a 3-parameter read tool.

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 a 3 is the baseline, but the description adds meaning the schema does not: id should be passed "as an answer gave it", detail is "concise, the default; full; origins for an import", and page is an integer for paging. It clarifies the semantics of detail beyond the bare enum values.

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?

"Returns everything PointRover holds on one item" gives a specific verb and resource, then enumerates the payload (latest figure, one-year change, anomaly signal, receipt handle, events). It is immediately distinguishable from list/search siblings, which return many records rather than one.

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?

Explicitly states when to use it (opening an id that search, pointrover_brief or pointrover_graph returned, to inspect one input/duty/wage/rule) and when not to (accounting data lives in another connector). It also routes the agent elsewhere for the specific adjacent needs: history to pointrover_series, sources to pointrover_receipt, connections to pointrover_graph.

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

All PointRover toolsInspect
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