Outreach Desk

Draft Response

draft_response

Read-onlyIdempotent

Use this to draft a reply to a scored pitch: an interested reply, a request for salary and remote details, or a polite decline. It needs an evaluation_id from score_message or get_scoreboard; evaluations expire after 30 days. Errors: unknown_evaluation means score the pitch again with score_message and use the new evaluation_id; no_desk means call set_criteria first. Decision defaults to the recommended action. For a decline, ask the user whether to include the feedback card. Returns subject and body as a draft only; it never sends anything, and the user sends the reply themselves. The desk is the signed-in user's, so send no desk_key.

Input Schema

Name	Required	Description
`decision`	No	Kind of reply. Defaults to the evaluation's recommended_action.
`evaluation_id`	Yes	The evaluation_id returned by score_message or get_scoreboard, such as "ev_3f9a1c2b". Evaluations expire after 30 days.
`include_feedback`	No	Only for decline: true appends a 3-line feedback card that says why the pitch did not fit. Defaults to false.

Output Schema

Name	Required	Description
`body`	Yes	Draft reply body, with the feedback card appended when asked for.
`as_of`	Yes	Day of the call, as YYYY-MM-DD in UTC.
`notes`	Yes	Reminder that this is a draft and nothing is sent.
`source`	Yes	Where the data comes from: the user's own private desk.
`subject`	Yes	Draft subject line.
`decision`	Yes	Kind of reply drafted.
`evaluation_id`	Yes	The evaluation the reply is for.
`feedback_card`	Yes	The feedback card text, or null when not asked for or not a decline.
`sender_domain`	Yes	Sender domain of the pitch.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

addedInput schema / examples

Added value: +[
+  {
+    "evaluation_id": "ev_3c92680b"
+  }
+]

Changed14 schema fields changedOct 10, 2026

changedInput schema / properties / decision / description

Previous value: -"The response decision (defaults to the evaluation's recommended_action)."New value: +"Kind of reply. Defaults to the evaluation's recommended_action."

changedInput schema / properties / evaluation_id / description

Previous value: -"The evaluation_id of the pitch to draft a reply for."New value: +"The evaluation_id returned by score_message or get_scoreboard, such as \"ev_3f9a1c2b\". Evaluations expire after 30 days."

addedInput schema / properties / evaluation_id / minLength
```
Added value: +1
```

changedInput schema / properties / include_feedback / description

Previous value: -"If true, appends an objective calibration feedback card to a decline draft."New value: +"Only for decline: true appends a 3-line feedback card that says why the pitch did not fit. Defaults to false."

addedOutput schema / properties / as_of / description

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

addedOutput schema / properties / body / description

Added value: +"Draft reply body, with the feedback card appended when asked for."

addedOutput schema / properties / decision / description
```
Added value: +"Kind of reply drafted."
```

addedOutput schema / properties / decision / enum

Added value: +[
+  "interested",
+  "request_info",
+  "decline"
+]

addedOutput schema / properties / evaluation_id / description
```
Added value: +"The evaluation the reply is for."
```

addedOutput schema / properties / feedback_card / description

Added value: +"The feedback card text, or null when not asked for or not a decline."

addedOutput schema / properties / notes / description

Added value: +"Reminder that this is a draft and nothing is sent."

addedOutput schema / properties / sender_domain / description
```
Added value: +"Sender domain of the pitch."
```

addedOutput schema / properties / source / description

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

addedOutput schema / properties / subject / description
```
Added value: +"Draft subject line."
```

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",
-  "evaluation_id"
-]New value: +[
+  "evaluation_id"
+]

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.9/5.0

Behavior5/5

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

The annotations already declare read-only, idempotent, non-destructive behavior, and the description adds important context: evaluations expire after 30 days, error meanings, decline feedback handling, and that the result is a draft only that is never sent. It also states the desk is the signed-in user's, so no desk_key is needed.

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?

It is front-loaded with the core purpose and then adds only operational rules: prerequisites, error recovery, defaults, decline handling, safety boundary, and authentication. Despite being several sentences, each one carries useful information.

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?

Given the existing output schema and annotations, the description covers everything needed for correct invocation: required input provenance, expiry, error recovery, decision defaults, decline-specific behavior, no-send semantics, and identity constraints.

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. The description still adds meaning by mapping the decision values to interested, salary/remote request, and decline, and by instructing the agent to ask the user about the feedback card for declines.

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?

It states a specific verb and resource, 'draft a reply to a scored pitch,' and enumerates the three reply types. It also distinguishes drafting from sending, which separates it from submission-oriented siblings.

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?

It gives an explicit trigger, required evaluation_id source, expiry, and concrete error recovery paths for unknown_evaluation and no_desk. It also clarifies default decision behavior and the decline feedback confirmation step.

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.