Skip to main content
Glama

tascan_revoke_device

DestructiveIdempotent

Revoke a device credential immediately — the kill switch for a lost, stolen, or decommissioned device (RFID portal, barcode gun, PLC, camera, robot, tool, sensor). Its next evidence post is refused. Idempotent: revoking an already-revoked device reports already_revoked and mints no second receipt. Requires the device:admin permission (owner-only, needs full, never reachable through OAuth).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy this device is being revoked (up to 500 characters)
device_idYesDevice ID to revoke

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: the real consequence ('its next evidence post is refused'), the idempotency outcome ('reports already_revoked and mints no second receipt'), and a precise auth constraint (device:admin, owner-only, never reachable through OAuth). Annotations only flag destructive/idempotent; the description explains what those mean in practice.

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 core action and consequence, then idempotency and permissions in descending importance. Dense but every clause carries information; the parenthetical device enumeration is the only slightly expendable part.

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?

For a mutation tool without an output schema, the description supplies the missing outcome semantics (evidence posts refused, already_revoked report), the auth model, and reversibility implications, leaving nothing an agent needs to call it correctly.

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%, so both parameters are already documented. The description conveys the intent of revocation but adds no syntax, format, or edge-case detail for device_id or the up-to-500-character reason beyond what the schema states.

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?

States a specific verb and resource (revoke a device credential) and grounds it with a memorable metaphor plus concrete device examples. No sibling tool performs a revoke action, so an agent can identify this uniquely without opening schemas.

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?

The 'kill switch for a lost, stolen, or decommissioned device' clause gives clear triggering contexts. It stops short of naming alternatives or when-not-to-use conditions, and no revoke sibling exists, so there is nothing to route against.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.