Skip to main content
Glama
thenavidm
by thenavidm

Delete a link

delete_link
Destructive

Remove a short link from your authenticated workspace by providing its link ID or external ID. Requires confirmation to prevent accidental deletion.

Instructions

Delete a link for the authenticated workspace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private workspace profile label; not a tenant or provider account ID.
confirmNoMust be true for the requested mutation or exclusive private output file.
link_idYesThe id of the link to delete. You may use either `linkId` (obtained via `/links/info` endpoint) or `externalId` prefixed with `ext_`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds only the workspace scoping clause and says nothing about irreversibility, the required confirm=true gate, or what a successful deletion returns – very little value beyond structured data.

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?

A single short, front-loaded sentence with no filler. It is economical, though its brevity is as much under-specification as conciseness.

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

Completeness3/5

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

For a simple one-parameter delete with full annotation and schema coverage and no output schema, the definition is minimally adequate. It omits the confirm gate and any consequence of deletion, which matter for a destructive operation.

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 the linkId vs ext_-prefixed externalId distinction and the confirm requirement, so the schema carries the parameter burden. The description adds no parameter meaning whatsoever, which is the correct baseline of 3.

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?

States a specific verb (delete) and resource (link), and scopes it to the authenticated workspace. It does not, however, distinguish itself from the sibling bulk_delete_links, which is the most plausible confusion for an agent.

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

Usage Guidelines2/5

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

No when-to-use guidance and no mention of alternatives. The sibling list contains bulk_delete_links, and nothing here tells the agent to pick the single-item tool over the bulk one when removing one link.

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