Skip to main content
Glama

Delete the referral link

well_delete_referral_code
DestructiveIdempotent

Stop the workspace's referral link, when the user asks to stop, cancel, delete or replace their referral link. From then on a signup with the old link counts for nobody. The people who already joined with it keep their own accounts.

referral_link_deleted is true when the live link was stopped and false when the workspace had none. To give a new link, call well_create_referral_code after this: it makes a new code, and the old one never counts again. Only an owner or admin of the workspace, or the member who made the link, may stop it; otherwise refusal is INSUFFICIENT_PERMISSIONS and nothing changes.

Input Schema

NameRequiredDescriptionDefault
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
refusalNoPresent only when nothing was stopped. DEMO_WORKSPACE: a demo workspace has no referral link. INSUFFICIENT_PERMISSIONS: only an owner or admin of the workspace, or the member who made the link, may stop it.
successYes
workspace_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.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
referral_link_deletedNoTrue when the live referral link was stopped: a signup with it counts for nobody from now on, and the people it already brought in keep their own accounts. False when the workspace had no live referral link.
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. Added

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: what stopping means going forward (old link counts for nobody), what is preserved (existing joiners keep their accounts), the exact response semantics of referral_link_deleted true/false, and the authorization requirement with the INSUFFICIENT_PERMISSIONS refusal path. The annotations already declare destructive/idempotent/non-read-only, so this description is well ahead of the bar; only the irreversibility/rate-limit dimension is left implicit.

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 verb and trigger, then layers outcome, follow-up tool, and permissions. Every sentence carries information, though it runs long and splits into distinct blocks (effect, output, next step, auth) that could be tightened slightly.

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 destructive write with an output schema, the definition covers effect, side effects on prior signups, output field meaning, follow-up routing, and authorization failure mode. An agent has everything needed to invoke it correctly and to interpret the result.

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% and each parameter (workspace_id, conversation_id, idempotency_key, workspace_scope) is documented in depth by the schema itself. The description adds no parameter-level syntax or format detail beyond what the schema provides, 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+resource ('Stop the workspace's referral link') and immediately broadens the trigger vocabulary ('stop, cancel, delete or replace'), which lets an agent match real user phrasing. It is clearly separable from well_create_referral_code and well_get_referral_code.

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

Usage Guidelines5/5

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

Gives explicit when-to-use conditions (user asks to stop/cancel/delete/replace) and names the follow-up alternative 'well_create_referral_code after this' with the reason (to give a new link). Exclusions and the ordering relationship are stated, not implied.

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