Outreach Desk

Purge Desk Data

purge_data

DestructiveIdempotent

Use this to permanently delete stored data. scope sender deletes every evaluation and the scoreboard row for one sender_domain, which is then required (for example "stripe.com"). scope desk deletes the whole desk: criteria, senders and evaluations. Deletion is immediate and cannot be undone, so confirm the scope with the user before calling. Returns purged true and what was deleted. Errors: scope sender with no sender_domain is refused with invalid_input; send sender_domain or use scope desk. Not for changing criteria; use set_criteria. The desk is the signed-in user's, so send no desk_key.

Input Schema

Name	Required	Description	Default
`scope`	Yes	What to delete: "sender" for one sender's records, or "desk" for the whole desk. Confirm with the user first.
`sender_domain`	No	Required when scope is "sender": the sender domain to delete, such as "stripe.com". Ignored for scope desk.

Output Schema

Name	Required	Description
`as_of`	Yes	Day of the call, as YYYY-MM-DD in UTC.
`scope`	Yes	What was deleted.
`purged`	Yes	True when the records were deleted.
`source`	Yes	Where the data comes from: the user's own private desk.
`message`	Yes	Plain statement of what was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026
- addedInput schema / properties / sender_domain / maxLength
```
Added value: +253
```

Changed1 schema field changedOct 15, 2026

addedInput schema / examples

Added value: +[
+  {
+    "scope": "sender",
+    "sender_domain": "faststaffing.biz"
+  }
+]

Changed8 schema fields changedOct 10, 2026

changedInput schema / properties / scope / description

Previous value: -"Whether to wipe the entire desk or records for a specific sender domain."New value: +"What to delete: \"sender\" for one sender's records, or \"desk\" for the whole desk. Confirm with the user first."

changedInput schema / properties / sender_domain / description

Previous value: -"Required if scope is 'sender': the domain name to delete."New value: +"Required when scope is \"sender\": the sender domain to delete, such as \"stripe.com\". Ignored for scope desk."

addedOutput schema / properties / as_of / description

Added value: +"Day of the call, as YYYY-MM-DD in UTC."

addedOutput schema / properties / message / description

Added value: +"Plain statement of what was deleted."

addedOutput schema / properties / purged / description

Added value: +"True when the records were deleted."

addedOutput schema / properties / scope / description
```
Added value: +"What was deleted."
```
addedOutput schema / properties / scope / enum
```
Added value: +[
+  "desk",
+  "sender"
+]
```

addedOutput schema / properties / source / description

Added value: +"Where the data comes from: the user's own private desk."

Changed2 schema fields changedOct 10, 2026

removedInput schema / properties / desk_key

Removed value: -{
-  "description": "The secret desk_key returned when the desk was created. It is the only credential for this desk and cannot be recovered.",
-  "pattern": "^od_[0-9a-f]{32}$",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "desk_key",
-  "scope"
-]New value: +[
+  "scope"
+]

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, but the description goes well beyond them: deletion is immediate and irreversible, the exact per-scope blast radius is listed, the success payload ('returns purged true and what was deleted') is described, the invalid_input failure path for scope sender without sender_domain is documented, and it notes the desk is implicitly the signed-in user's. This is a materially richer behavioral picture than the annotations alone.

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 purpose, then scopes, then the irreversibility warning, then return shape, then error path, then the sibling exclusion — a logical ordering. It is dense but nearly every clause carries distinct information; the error-handling sentence is the only part that could arguably live in the schema.

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?

An output schema exists, yet the description still previews the return shape in one clause, and it covers safety, per-scope semantics, prerequisites, and the alternative tool. For a two-parameter destructive tool, nothing an agent needs before invoking 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 coverage is 100% and the schema already documents both params, including that sender_domain is required when scope is 'sender' and ignored otherwise. The description restates that relationship with a concrete example and adds the 'send no desk_key' note, which is a useful guard against an invented parameter, but on balance the schema does the heavy lifting.

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 and resource ('permanently delete stored data') and then enumerates precisely what each scope removes: per-sender evaluations plus the scoreboard row, versus criteria, senders and evaluations for the desk. An agent can distinguish this from set_criteria and from any read siblings without opening the 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?

Gives explicit when-to-use guidance per scope plus an explicit exclusion: 'Not for changing criteria; use set_criteria.' It also imposes the prerequisite 'confirm the scope with the user before calling,' which is exactly the kind of decision guidance an agent needs before a destructive call.

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

All Outreach Desk 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.