BetSlip Doctor

Doctor: decisions, reply buttons, memory

doctor_actions

DestructiveIdempotent

The Doctor actions beside the conversation, as the app does them. Record a decision only when the customer says what they did; change memory consent only when they ask. Delete and forget preview until confirmed; reuse the same commandKey on a retry. decision: GET doctor/messages/{messageId}/decision optional params {beforeRevision}; returns the saved reply reference and responseRevision; record_decision: POST doctor/messages/{messageId}/decision body {messageId, messageDigest, threadId, binding:{ticketId, reportId, history}, expectedRevision, confirmation: SAVE_RESPONSE, decision: followed|changed|skipped|unknown, modifiedTicketId?}; use the exact reference and responseRevision from decision; binding values can be null; subject to the app Doctor action access gate; saved_reply: GET doctor/messages/{messageId}/saved-reply params {messageDigest, threadId, ticketId?, reportId?, historyKind?, historyId?}; omit null bindings, include ticketId with reportId, and send historyKind and historyId together; grade_this: POST doctor/messages/{messageId}/grade-quote app body; compare_books: POST doctor/messages/{messageId}/book-prices app body; revise_ticket: POST doctor/messages/{messageId}/revisions app body; book_check: GET doctor/book-comparisons/{comparisonId}; delete_thread: POST doctor/threads/{threadId}/delete (confirmation DELETE); memory_status: GET doctor/memory; memory_context: GET doctor/memory/context; memory_consent: POST doctor/memory/consent body {enabled, expectedGeneration, confirmation}; use memory_status.generation and ALLOW_HONCHO_MEMORY when enabling or DISABLE_HONCHO_MEMORY when disabling; enabling requires notes memory enabled; memory_forget_all: POST doctor/memory/forget body {expectedGeneration}; use memory_status.generation; confirmed notes remain and vendor erasure can be pending (confirmation FORGET_RECALLED_MEMORY); notes_consent: POST memory/consent body {enabled, expectedGeneration}; use memory_status.generation; the switch controls both notes and automatic Doctor memory, without deleting notes. Confirm the requested change with the customer before a write. A valid write is sent without a separate MCP preview unless the action says otherwise.

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": {
      "action": "<action>"
    },
    "name": "doctor_actions"
  }
}

Input Schema

Name	Required	Description
`body`	No	The app request body for this action, unchanged.
`action`	Yes
`params`	No	The app query (filters, limit, cursor) for a read.
`threadId`	No
`messageId`	No
`commandKey`	No	Writes: one stable key per write, reused on every retry.
`comparisonId`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 31, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Given annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, the description still adds real substance: which actions preview until confirmed, the exact confirmation sentinels (SAVE_RESPONSE, DELETE, FORGET_RECALLED_MEMORY), optimistic concurrency via expectedRevision/expectedGeneration, commandKey reuse on retry, the Doctor action access gate, and the caveat that confirmed notes remain while vendor erasure can be pending. It does not contradict the annotations (read endpoints coexist inside a mutating dispatcher), but it never states error behavior or what a rejected revision returns.

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

Conciseness2/5

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

The content is front-loaded correctly – the safety rules come before the endpoint catalog – but the body is a single run-on paragraph chained with semicolons that mixes policy, path templates and JSON body sketches with no formatting, making the per-action spec hard to scan. 'use memory_status.generation' is repeated verbatim for two actions, which is avoidable repetition in an already dense block.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-action dispatcher with no output schema and opaque nested bodies, the description is unusually complete: it pairs every action with a method/path, gives the confirmation tokens, states the ordering constraint between decision and record_decision, and covers memory gating. The remaining gaps are the three app-body actions (grade_this, compare_books, revise_ticket) and their return values, which an agent would have to infer.

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 only 43% and the two nested objects (body, params) are essentially undocumented ('The app request body for this action, unchanged'), so the description carries real weight: it spells out required body fields for record_decision, memory_consent, notes_consent and memory_forget_all, the params for decision and saved_reply, and the null-binding rules. Against that, three actions' bodies are left as bare 'app body' and the commandKey/expectedRevision relationship is described only implicitly, so it compensates well but incompletely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates all 13 actions with their HTTP endpoints and, for the important ones (decision, record_decision, saved_reply, memory_consent, memory_forget_all, notes_consent), the body shape and confirmation token, which lets an agent pick the right action without opening the schema. However the umbrella sentence ('The Doctor actions beside the conversation, as the app does them') is vague, and several actions (grade_this, compare_books, revise_ticket, book_check) are conveyed only by an endpoint path, which is close to restating the action name.

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?

Unlike most definitions it gives explicit when-to rules: 'Record a decision only when the customer says what they did; change memory consent only when they ask', 'Delete and forget preview until confirmed', 'Confirm the requested change with the customer before a write'. What it omits is sibling disambiguation – memory_status vs get_doctor_memory, memory_forget_all vs forget_doctor_note, memoody_consent vs set_synced_record_consent are never contrasted, even though those siblings clearly overlap.

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

All BetSlip Doctor 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.