Skip to main content
Glama

Revoke invite

revoke_invite
DestructiveIdempotent

Cancel a pending team invitation so its link stops working. The inviteId comes from list_invites.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "teamId": "<teamId>",
      "inviteId": "<inviteId>"
    },
    "name": "revoke_invite"
  }
}

Input Schema

NameRequiredDescriptionDefault
teamIdYesTeam ID from list_teams.
inviteIdYesFrom list_invites, e.g. t:12.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the destructive and idempotent annotations, it explains the user-visible consequence that the invitation link stops working and limits the operation to pending invitations. It does not clarify recovery, permissions, or error behavior, but the essential destructive effect is clear.

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?

Two short sentences front-load the action and consequence, then provide only the useful ID-source pointer. There is no redundant, promotional, or distracting wording.

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 simple two-parameter revocation, the description, fully documented schema, and annotations jointly provide the target, ID-discovery workflow, operational scope, and destructive effect. Recovery and response details are unstated, but they are not necessary to select the tool and make a correct initial call.

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%, including parameter sources, the inviteId pattern, and an example, so the baseline score applies. The description repeats inviteId's list_invites provenance, reinforcing the workflow without adding new format, validation, or teamId semantics.

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 uses a concrete action and resource—cancelling a pending team invitation—and states the practical result that its link stops working. This scope distinguishes it from creating or accepting invitations and from revoking other resources such as API keys.

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 identifies the applicable state, a pending team invitation, and provides a useful workflow by directing the agent to list_invites for inviteId. It does not explicitly state when not to use the tool or what to do for invitations in other states.

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