Skip to main content
Glama
Sign In

PatrolTech

by online.patroltech
OverviewDiscussionsAdmin

Guard ranking

patroltech_patrollers_get_ranking
Read-onlyIdempotent

Use when you want to compare guards by rounds completed and scans over a period, instead of building the comparison yourself. Returns the guards ordered by their activity in the period (rounds completed, completion rate, scans), each with totalScans, roundsCompleted, completionRate (percent of the checkpoints scanned out of all the checkpoints of the rounds of the guard; not the share of rounds completed) and avgTimeBetweenScans (seconds; null without data), plus a team summary and the most scanned checkpoints (topCheckpoints). Dates are calendar days in the time zone of the account; without a period it covers everything the data retention allows. retentionCutoff (UTC; null when unlimited): the period never starts before it, so older activity is not counted. With truncated: true the list is capped. It is activity data, not an assessment of the people (it does not see shifts, absences or assigned tasks): present it with its period and do not draw conclusions from it on your own about the performance or employment of anyone. Do not use when you need the people who sign in to the dashboard.

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

Input Schema

NameRequiredDescriptionDefault
toNoEnd date of the range (inclusive), YYYY-MM-DD.
fromNoStart date of the range, YYYY-MM-DD (never words like "yesterday").
periodNoRelative period. Use it when the user says "today", "yesterday", "last week", "last month" or similar.
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.3/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: defines completionRate precisely (checkpoints scanned, not share of rounds), notes avgTimeBetweenScans is null without data, explains the retentionCutoff constraint, the truncated cap, and that dates are calendar days in the account time zone. It also adds an ethical constraint against drawing employment conclusions, which is genuine operational guidance an agent could not get from 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?

Front-loaded with the use case and tightly written with no filler sentences; every clause carries information. It is a dense wall of prose with no breaks and the return-field enumeration sits mid-paragraph, which slightly hurts scannability.

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?

There is no output schema, and the description compensates fully by naming the returned fields (totalScans, roundsCompleted, completionRate, avgTimeBetweenScans, summary, topCheckpoints) plus the truncated and retentionCutoff signals. For a read-only, four-parameter tool, nothing an agent needs to call or report results 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 would be 3, but the description adds real meaning the schema lacks: dates are calendar days in the account's time zone, and omitting a period defaults to all data the retention window allows. The organization parameter is only covered by the schema, not reinforced in the description, which keeps it below 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?

States a specific verb and resource: compare guards by rounds completed and scans over a period, and explicitly says it replaces building the comparison yourself. The purpose is unmistakable, but no sibling tool (e.g. patroltech_patrollers_get_stats or patroltech_scans_count_by_patroller) is named as the adjacent alternative, so the differentiation from close siblings is left implicit.

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?

Gives an explicit positive trigger ("Use when you want to compare guards … instead of building the comparison yourself") and an explicit negative one ("Do not use when you need the people who sign in to the dashboard"). The exclusion is not tied to a named tool, so the agent must infer which sibling handles that case.

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