PatrolTech

Guard statistics

patroltech_patrollers_get_stats

Read-onlyIdempotent

Use when you want the statistics of one specific guard. Returns the totals of one guard over their whole history: totalScans, roundsCompleted out of totalRounds, completionRate (percent of the checkpoints scanned out of all the checkpoints of the rounds of the guard; not the share of rounds completed), avgTimeBetweenScans (seconds; null without data) and, when known, incidentsReported and incidentsOpen. retentionCutoff (UTC; null when unlimited): activity before it still counts in the totals, but its details are no longer shown. If the name matches several guards or none, it fails with the names to choose from. Do not use when you need the people who sign in to the dashboard.

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": {
      "guard": "<guard>"
    },
    "name": "patroltech_patrollers_get_stats"
  }
}

Input Schema

Name	Required	Description	Default
`guard`	Yes	Name of the guard (never empty: if you do not know it, ask).
`organization`	No	Omit 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.

First observedOct 31, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description still adds genuine behavioral detail: null semantics for avgTimeBetweenScans and retentionCutoff, the fact that pre-cutoff activity counts in totals but loses detail, and the multi-match failure returning candidate names. It even pre-empts a likely misreading by clarifying completionRate is checkpoints-scanned, not rounds-completed.

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 trigger and the core return fields are front-loaded, and every clause (null handling, retention cutoff, failure mode, exclusion) carries information an agent needs. It is a dense single block rather than a lean one, but nothing is filler.

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 carries full responsibility for describing return values and does so field by field, including units (seconds) and nullability. Combined with annotations covering the safety profile and a fully described schema, an agent has enough to call it correctly and interpret the result.

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% and both parameters carry their own descriptions, so the baseline is already met. The description adds value beyond the schema by explaining what happens when the guard name is ambiguous or empty, which is the main semantic risk for the required parameter. The optional organization parameter is left entirely to the schema, which is reasonable.

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 opens with a specific verb and resource ('statistics of one specific guard') and enumerates exactly what totals come back, which lets an agent picture the payload before calling. It distinguishes itself from patroltech_users_list_roles but never contrasts with the closer siblings patroltech_patrollers_get_ranking or patroltech_patrollers_list_activity, so an agent choosing among the three patroller tools still has to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use when you want the statistics of one specific guard' sets the trigger, and 'Do not use when you need the people who sign in to the dashboard' states an explicit exclusion. The failure mode on ambiguous or missing guard names is documented, which is real routing guidance. It stops short of naming the ranking/activity alternatives it is most likely to be confused with.

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

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