Capable

Delete record

delete_record

Destructive

Archive (soft-delete) a record by object_type + id. DESTRUCTIVE — call once to get a confirmation prompt, then again with confirm:true. Sets deleted_at (never a hard delete) for custom objects, saved reports (creator, manager, or admin), a whole quote (its line items cascade), AND contact plus the core leaf objects opportunity / task / signal / touch — so a mistaken or duplicate one can be removed. Contact history and account links are retained for restore. An ACCOUNT can be removed too (e.g. a junk import), but ONLY once it has no live records under it — an account with any open opportunity or any subscription is refused with the counts and the next step (close / re-point / mark-lost those first); its contacts, touches, notes, and tasks are kept as history and don't block. Subscription still doesn't remove this way (it has cancel_subscription) — change it via update_record. A single quote line item can't be deleted directly (change the line set with update_quote). Returns the archived record.

When to use: Archive a record (soft delete; pass confirm:true) — a custom-object record, a saved report, a contact, or a core leaf object (opportunity / task / signal / touch), e.g. a mistaken or duplicate record. Contact history and account links are retained for web restore. An account is removable too once nothing live sits under it (open deals / subscriptions refuse with the counts); subscription doesn't remove this way — cancel or change it via update_record.

Example: Delete that duplicate contact .

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	A uuid.
`confirm`	No	Boolean (true/false).
`object_type`	Yes	Object key of the record to archive, e.g. contact, opportunity, task, touch, account, report, quote, a custom object's key, or rollup / automation (admin-only); subscription is refused.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`record`	No
`result`	No
`deleted`	No
`requires_confirm`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes well beyond them: the two-call confirmation flow (first call returns a prompt, second with confirm:true), that it only sets deleted_at and never hard-deletes, cascade behavior for quote line items, what is retained for restore, and the refusal-with-counts behavior for accounts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded, but the 'When to use' paragraph largely restates the opening paragraph almost verbatim (soft-delete, confirm:true, contact history retained, account removal, subscription exception), so a meaningful share of the text is duplicated rather than additive.

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, multi-object tool this covers the destructive mechanics, the confirmation handshake, cascade and retention behavior, and the refusal conditions; an output schema exists and the description still notes the return ('the archived record'), so nothing needed to invoke it 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 real meaning the schema lacks: the semantics of confirm (a deliberate second-call gate, not just 'Boolean (true/false)') and the object_type acceptance/refusal rules including the admin-only rollup/automation case and the refused subscription.

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?

Opens with a specific verb+resource+keying scheme: 'Archive (soft-delete) a record by object_type + id.' It explicitly carves itself out from siblings by naming cancel_subscription, update_record, and update_quote as the correct paths for cases this tool refuses, so an agent can distinguish it without opening another schema.

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?

Has a dedicated 'When to use' block plus explicit exclusions: subscription does not remove this way (use cancel_subscription/update_record), a single quote line item cannot be deleted (use update_quote), and an account is refused while live records exist with the next-step guidance. This is explicit when/when-not/alternative coverage.

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

All Capable tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?