Paddock Cards

Delete private uploads

delete_private_content

DestructiveIdempotent

Request deletion of unused uploads and compositions in one private scope at the buyer’s request. Returns acceptance and deletion state; it does not cancel an order. Purchased content remains until 90 days after mailing or final cancellation/refund, longer while an order, dispute or legal hold is unresolved.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scope_id": "<scope_id>",
      "order_access_token": "<order_access_token>"
    },
    "name": "delete_private_content"
  }
}

Input Schema

Name	Required	Description	Default
`scope_id`	Yes	Exact scope_id from open_private_content whose unused content the buyer wants deleted.
`order_access_token`	Yes	Exact private order_access_token returned by open_private_content for this scope. Keep it private and never invent one.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / order_access_token / description

Previous value: -"The private capability returned by open_private_content. Never invent one."New value: +"Exact private order_access_token returned by open_private_content for this scope. Keep it private and never invent one."

addedInput schema / properties / scope_id / description

Added value: +"Exact scope_id from open_private_content whose unused content the buyer wants deleted."

AddedOct 29, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations, the description adds important behavior: it returns acceptance and deletion state, does not cancel an order, and explains retention timing for purchased content including mailing, cancellation/refund, disputes, and legal holds. This is substantial disclosure for a destructive operation and is consistent with destructiveHint=true and idempotentHint=true.

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?

The description is three tight sentences, front-loaded with the action and scope, followed by return behavior and retention constraints. Every sentence adds decision-relevant information with no waste.

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 deletion tool with an output schema and full schema coverage, the description is complete: it states what is deleted, what is not affected, return behavior, and retention/legal-hold conditions. Nothing essential for correct invocation is missing.

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%, so both required parameters are already well documented in the schema. The description reinforces that the action applies to 'one private scope' but does not add parameter-level syntax or usage detail beyond the schema, so the baseline 3 is appropriate.

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?

The description uses a specific verb and resource: 'Request deletion of unused uploads and compositions in one private scope at the buyer’s request.' It also explicitly distinguishes this from order cancellation by stating 'it does not cancel an order,' which helps separate it from siblings such as cancel_order.

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?

It clearly identifies the usage context ('at the buyer’s request') and a key exclusion ('does not cancel an order'), plus retention conditions that matter before use. It does not explicitly name cancel_order as the alternative for cancellation, so it falls short of full 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 Paddock Cards 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?