Skip to main content
Glama
aqeelshamz

wixzel-phone-mcp

by aqeelshamz

Revoke an API key

revoke_api_key
DestructiveIdempotent

Revoke an API key instantly to stop all access with no grace period. This irreversible action immediately disables compromised or unused credentials.

Instructions

Revoke immediately, with no grace period. Anything still using it starts failing at once, including this MCP server if it is the key in use. Not reversible.

Requires scope api_keys:write.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe record id, e.g. "6a96a3ead6e886d42462dd3e".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Annotations already indicate destructive and non-read-only behavior. The description adds critical context beyond that: immediate effect with no grace period, impact on this MCP server if the key is in use, irreversibility, and the required scope. This fully discloses the behavioral profile for an agent.

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 compact and front-loaded with the most important fact ('Revoke immediately'). Every sentence adds value: immediate effect, consequences, irreversibility, and authentication requirement. No redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter destructive action, the description is largely complete: it covers timing, side effects, reversibility, and required scope. The main gap is the lack of any note about the response or behavior on an already-revoked key, but given the annotations and simple input, this is a minor omission.

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 coverage is 100%, with the single 'id' parameter fully described including an example. The description adds no extra parameter-level meaning, which is acceptable given the high schema coverage, so the baseline of 3 applies.

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 clearly states the action ('Revoke') and the resource ('an API key') with specific behavioral details (immediate, no grace period). However, it does not explicitly differentiate from sibling tools like rotate_api_key, though the verb and irreversibility provide some implicit distinction.

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

Usage Guidelines3/5

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

The description implies when to use this tool: for immediate, irrevocable revocation. It mentions the required scope and the consequence that all users of the key will fail. But it does not explicitly state when not to use it or name alternatives like rotate_api_key for key rotation.

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