Skip to main content
Glama
Sign In

PatrolTech

by online.patroltech
OverviewDiscussionsAdmin

Guard app links

patroltech_patrollers_get_app_links
Read-onlyIdempotent

Use when you want the link each guard uses to open the app. Returns the personal app link of each guard (it signs in as that guard without a password: share each one only with its guard) and the general link of the organization (it asks which guard signs in; give it for a guard not created yet). With guard, only theirs plus messageToForward: a ready message with their name, their link and how to install the app, to give as is. 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_app_links"
  }
}

Input Schema

NameRequiredDescriptionDefault
guardNoName of the guard who will receive it: returns their link and `messageToForward`, the message to forward to them. Omit it to list the links of every guard.
languageNoLanguage of `messageToForward`: 'es', 'en' or 'fr' (any other language: 'en').
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.8/5.0
Behavior5/5

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

The annotations already declare a read-only, idempotent, non-destructive operation, but the description adds important behavioral context: personal links sign in as a guard without a password, should be shared only with that guard, and the organization link prompts for guard sign-in. It also explains the special `messageToForward` behavior when `guard` is supplied.

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 use case, then explains return behavior, parameter-specific behavior, and the exclusion. Despite being dense, every sentence earns its place by clarifying safe usage or output expectations.

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, but the description explains what is returned: per-guard personal links, the organization link, and the ready-to-forward message when `guard` is specified. Combined with the annotations and fully described parameters, it gives an agent enough to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds meaningful cross-parameter semantics beyond the schema: `guard` narrows the result to that guard's link plus a ready-to-forward message, `language` controls that message's language, and `organization` only applies to multi-organization accounts. This materially helps an agent use the parameters correctly.

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: retrieving the app links guards use to open the app. It distinguishes personal guard links from the organization-wide link and explicitly contrasts itself with dashboard-user needs, so an agent can identify its role among siblings.

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?

It gives a clear primary use case and an explicit exclusion: do not use it when you need the people who sign in to the dashboard. It does not name a specific sibling alternative for that dashboard-user need, which keeps it from a full 5 under the rubric.

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