Skip to main content
Glama
Sign In

PatrolTech

by online.patroltech
OverviewDiscussionsAdmin

Rounds detail by route

patroltech_rounds_list_by_route
Read-onlyIdempotent

Use when you want to see the latest rounds of each route and how they ended. Returns each route with its recent rounds (status, guard, checkpoints done of total, times in UTC). A route with error could not be read: do not say it has no rounds. With truncated: true the data is capped: do not state totals or absences. Do not use when you need the definition of routes or checkpoints.

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": "patroltech_rounds_list_by_route"
  }
}

Input Schema

NameRequiredDescriptionDefault
organizationNoOmit unless the account has more than one organization; then the exact name (or id) as listed by patroltech_account_get_context.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses critical result-integrity caveats: route-level errors mean the route could not be read, and truncated results mean totals or absences must not be stated. These are exactly the behavioral details an agent needs to avoid making false claims from the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary use case, then quickly covers return shape, edge-case handling, and exclusions. Every sentence earns its place and none of the operational caveats are buried or wasted.

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?

With no output schema, the description still explains what each route entry contains (status, guard, checkpoints done of total, UTC times) and how to interpret error and truncated states. Combined with full schema coverage for the single optional parameter, it is complete enough for correct invocation and interpretation.

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?

The only parameter, organization, is already fully documented in the schema, including the instruction to omit it unless the account has multiple organizations. The description adds no parameter-specific guidance, so the baseline score of 3 applies for high schema coverage.

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 states a specific verb and resource: listing the latest rounds for each route and how they ended, plus returned fields. It distinguishes this from tools that provide route or checkpoint definitions, so an agent can tell it apart from siblings such as rounds_get_status or routes_get_schedules.

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 explicitly states when to use it ("Use when you want to see the latest rounds of each route and how they ended") and when not to use it ("Do not use when you need the definition of routes or checkpoints"). This is strong routing guidance, even though it implies rather than names the alternative tools.

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

All PatrolTech 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