Skip to main content
Glama

Revoke share links

revoke_media_link
DestructiveIdempotent

Turn share links off now: one (linkId), a clip's (clipId), a project's (projectId) or all of yours (all: true). Give exactly one. Returns { revoked, message }. Anyone holding a revoked link gets a 404 from then on.

Instructions

Turn share links off now: one (linkId), a clip's (clipId), a project's (projectId) or all of yours (all: true). Give exactly one. Returns { revoked, message }. Anyone holding a revoked link gets a 404 from then on.

Input Schema

NameRequiredDescriptionDefault
allNoEvery share link you have
clipIdNoEvery link to this clip
linkIdNoLink id (from get_media_links or list_media_links)
projectIdNoEvery link to this project's clips and zip

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.31.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark this as destructive and idempotent. The description adds valuable consequence detail: revoked links return 404 afterward, and it discloses the return shape { revoked, message }. It does not mention permissions or whether links can be re-enabled, but the key behavioral effect is explicit.

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?

Front-loaded with the core action, followed by scopes, invocation constraint, return shape, and consequence in a compact form. Every sentence carries useful information.

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?

Covers what the tool does, valid scope combinations, return value, and post-revocation behavior. Despite no output schema, the return shape is stated, and annotations already carry the safety profile.

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?

Schema coverage is 100%, so the baseline is 3. The description adds important mutual-exclusivity semantics ('Give exactly one') and maps each parameter to its revocation scope, which the schema alone does not fully emphasize.

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 ('Turn share links off') and enumerates the four supported scopes. An agent can immediately tell this is a revocation tool rather than a listing or creation tool.

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?

Clearly instructs to 'Give exactly one' scope, which prevents invalid multi-scope calls. It implies use when a share link must be disabled but does not explicitly contrast with sibling tools beyond noting linkId comes from get_media_links or list_media_links in the schema.

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