Skip to main content
Glama

Delete invoice draft link

well_delete_invoice_draft_link
DestructiveIdempotent

Delete the link to the web page that shows one draft invoice, so the address no longer opens for anyone who has it. Call it when the user asks to stop sharing, delete or revoke the draft link. Only a workspace owner or admin can.

REQUIRED: invoice_id (the invoice whose draft link stops).

The invoice itself is unchanged. A later well_get_invoice_draft_link for the same draft makes a new address; the deleted one never opens again. When outcome is "no_live_link", say the invoice had no live link; never say a link was stopped.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

NameRequiredDescriptionDefault
invoice_idYesThe invoice whose draft link stops.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
errorNo
messageNo
outcomeNo
successYes
invoice_idNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description goes well beyond them by naming the permission gate, the irreversibility of the old address, the fact that the invoice itself is untouched, and the correct user-facing phrasing for the 'no_live_link' outcome. It also explains the workspace-resolution consequence (a write lands in exactly one workspace, no guessing) that annotations cannot express.

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?

Front-loaded with the effect and the usage trigger, then requirements, then caveats — every block earns its place. One blemish: the multi-workspace sentence calls this destructive delete 'this read', a leftover from a read-tool template that slightly muddies an otherwise clean paragraph.

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 all five parameters in prose where it matters, explains the outcome field despite an output schema existing, and handles the single-vs-multi-workspace branching. Nothing an agent needs to call this destructive operation correctly is missing.

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, but the description adds operational meaning the schema lacks: it flags invoice_id as REQUIRED and states that with a single-workspace token no prior workspace call is needed, which is process guidance not present in the workspace_id field text.

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 precise verb and resource ('Delete the link to the web page that shows one draft invoice') and immediately describes the observable effect ('the address no longer opens for anyone who has it'). That wording separates it from well_delete_invoice and well_delete_invoice_portal_link without the agent needing to open either schema.

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 an explicit trigger ('when the user asks to stop sharing, delete or revoke the draft link') and an authorization precondition (workspace owner or admin). It does not explicitly contrast with the nearby portal-link or full-invoice deletion tools, so an agent still has to infer the boundary from the 'draft link' wording.

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