Skip to main content
Glama

Revoke number from member

revoke-number
Destructive

Remove a corporate member's assignment to a fax number (DELETE assigned_to entry). user_id is the member to REMOVE from the number — NOT the owner and NOT 'who is calling'. To unassign Dom User, pass Dom User's user ID. Using self removes YOUR own assignment (common mistake). Does not cancel the number, delete it, or change owner_id. Number cannot be revoked from the admin/owner in some cases.

Side effects: removes the named member from the number's assigned_to list (does not cancel the number).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
numberYesFax number in E.164 form, e.g. +1234567890.
user_idYesREQUIRED: user ID of the member whose assignment to remove from the number. Pass the member UUID (e.g. Dom User). Use self ONLY to remove your own assignment. Do not default to self when unassigning someone else.
confirmation_textYesMust be exactly REVOKE_NUMBER.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
numberYes
messageYes
revokedYes
revoked_from_user_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as destructive, and the description adds valuable scoping: only the assigned_to entry is removed, the number itself is not canceled, and owner_id is untouched. It also warns about the common self-unassignment mistake and an admin/owner limitation.

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?

Core action is front-loaded, followed by essential warnings and side effects. It is a little repetitive around 'does not cancel the number', but the length is justified for a destructive operation with a subtle user_id parameter.

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 destructive tool with 3 required parameters, the description covers all important operational details: parameter semantics, confirmation_text behavior was left to schema, the actual mutation scope, and an edge case. An output schema exists, so return-value detail is not required.

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?

The schema already covers all three parameters, but the description significantly clarifies user_id semantics by stressing that it is the member to remove, not the owner, not 'who is calling', and that 'self' only unassigns the current caller. This goes beyond the raw schema.

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 clearly states the action: remove a member's assignment to a fax number via a DELETE on the assigned_to entry. It explicitly distinguishes this from canceling or deleting the number, and from changing owner_id, which sets it apart from sibling tools like update-number or purchase-number.

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 a clear picture of when to use the tool: revoking a member from a number. It explicitly warns about what the tool does not do (cancel/delete/owner change) and calls out an admin/owner edge case, though it does not name alternative sibling tools for each 'not' case.

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.

Resources