PointRover

Events Near the Business

pointrover_events

Read-only

Returns the recalls, weather alerts, disaster declarations and trade actions reaching the business's locations or what it buys, each in its publisher's words, with how closely it touches the business. Use this when the assistant is checking whether a storm warning covers a location, or a recall hits parts the business stocks. Not for the business's own books: invoices, bank, payroll or accounting live in its accounting connector, not here. Each event gives its state, dates, exposure, coverage and weight; an ended one opens with fetch. Pass since (check id or ISO date), min_exposure, min_coverage, min_weight (numbers), kinds (array, such as ["weather_watch"]), all and sources (booleans). Example: pointrover_events({"min_weight": 0.0001}). Ordered by end date; about 3000 tokens at most.

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_events"
  }
}

Input Schema

Name	Required	Description
`all`	No	true lists every live event passing the other filters, on the board or off it. With no argument at all, the events off the board are counted, not listed.
`kinds`	No	Only events of these types, as each record's event_type names them — for example weather_watch, vehicle_recall, disaster_declaration, trade_action.
`since`	No	Only events opened since this point: a check id from an earlier answer, or an ISO date. An event the board itself holds opened when the board was built.
`sources`	No	true adds each event source's last check, in full, to the answer.
`min_weight`	No	Only events whose weight (exposure × coverage) is at least this. Records with none are excluded; a named, weighted record is kept.
`min_coverage`	No	Only events covering at least this share of their row. Records with none are excluded; a named, weighted record is kept.
`min_exposure`	No	Only events exposed at least this much: a trade or product event's weight, any other event's exposure. Records with none, and weighted: false records, are excluded.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond readOnlyHint=true, it discloses that events retain their publishers' wording, lists the principal event fields, and explains that an ended event is opened with fetch. It also states end-date ordering and the approximate 3000-token response ceiling, which are valuable response-shaping details absent from the 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?

The purpose, use cases, and exclusion are front-loaded, and the remaining sentences convey invocation and response behavior without filler. It is nevertheless a dense single paragraph, and the parameter-by-parameter inventory partially duplicates the fully documented schema.

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?

Despite having no output schema, the definition covers event content, relevance measures, detail retrieval, ordering, and response size while the input schema supplies the detailed filtering behavior. Together these provide enough context to select the tool, construct a call, and anticipate its result.

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 100%, and the description's parameter inventory largely repeats the types and meanings already documented there, often with less detail. The concrete min_weight invocation example is useful, but it adds limited semantic information beyond the schema.

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 opening sentence precisely identifies the resource and scope: external recalls, weather alerts, disaster declarations, and trade actions affecting the business's locations or purchases. It also distinguishes these events from the business's own financial records and points to fetch for opening an ended event.

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 concrete selection cases, such as checking whether a storm warning covers a location or a recall affects stocked parts. The explicit exclusion for invoices, banking, payroll, and accounting provides useful when-not guidance and redirects those requests to the accounting connector.

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

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