Skip to main content
Glama

Revoke Invitation

revoke_invitation

Cancel a pending invitation so its link stops working; the person can be invited again later. Requires workspace admin or owner.

Instructions

Cancel a pending invitation; its link stops working. The person can be invited again later. Needs a workspace admin or owner.

Input Schema

NameRequiredDescriptionDefault
invitation_idYesInvitation id from list_invitations.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

A4.3/5.0
Behavior4/5

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

Adds real context beyond the annotations: the invitation link is invalidated, the action is recoverable (re-invite is possible), and it requires admin/owner privileges. The recoverability note is consistent with destructiveHint=false since nothing is permanently destroyed. It doesn't say whether revoking an already-accepted invitation errors out, which keeps it from a 5.

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?

Three short sentences in descending priority: action+effect, reversibility, then prerequisite. Zero filler.

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 one-parameter mutation with an output schema already defined, the description covers effect, reversibility, and permission gating — everything an agent needs before calling it.

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% and the single parameter already carries a description pointing at list_invitations. The description adds nothing about the id's format or failure behavior, so the baseline 3 applies.

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 (cancel/revoke) and resource (a pending invitation) plus the observable effect: 'its link stops working.' That effect cleanly separates it from resend_invitation and invite_people without needing to name them.

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?

Scoping is explicit — it applies to a pending invitation only, and the follow-up 'can be invited again later' tells the agent this is the non-permanent path versus deactivate_member. It states the required role (workspace admin or owner) but doesn't explicitly name the sibling alternative for a different case.

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