MCP Tool Reference
Tools, resources, and prompts exposed by the MCP server.
Server URL: https://api.deecee.ai/mcp (Streamable HTTP transport). See Authentication for creating an API key, and the Claude Desktop quickstart for setting it in your client.
Tools
| Tool | Maps to | Description |
|---|---|---|
start_decision_brief | POST /v1/decisions | Create a new decision (context is optional — see below) |
list_frameworks | GET /v1/frameworks | List DACI, SPADE, helix with descriptions |
list_use_cases | GET /v1/use-cases | List guided-interview templates for use_case_id |
list_decisions | GET /v1/decisions | List your past decisions |
get_decision | GET /v1/decisions/{id} | Fetch a decision's state and any completed stages |
get_recommendation | GET /v1/decisions/{id}/recommendation | Get the framework's final-stage content |
interview_next_question | POST /v1/decisions/{id}/interview | Submit a message, returns a job_id for the next question |
synthesize_context | POST /v1/decisions/{id}/synthesize-context | Turn the interview conversation into a saved decision context |
update_decision_context | POST /v1/decisions/{id}/context | Directly replace the context (e.g. after editing the synthesis) |
assess_decision | POST /v1/decisions/{id}/assess | Recommend complexity/framework/title from the context (read-only) |
apply_decision_setup | POST /v1/decisions/{id}/setup | Commit the (possibly overridden) title/framework/complexity |
attach_document | POST /v1/decisions/{id}/documents | Attach a document (by URL) for use as context during analysis |
refine_stage | POST /v1/decisions/{id}/refine | AI-revise one completed stage — suggests only, doesn't save |
apply_stage_revision | POST /v1/decisions/{id}/refine/apply | Commit a (possibly edited) revision to a stage |
export_brief | POST /v1/decisions/{id}/export | Export the brief as Markdown, DOCX, or PDF |
advance_stage | POST /v1/decisions/{id}/advance | Recommended. Run exactly the next stage, returns a job_id |
generate_framework_analysis | POST /v1/decisions/{id}/analyze | Run every stage in one request, returns a job_id |
get_job | GET /v1/jobs/{id} | Poll an async job's status and result |
Tool descriptions are written for an AI planner — each one explains when to reach for it, not just what it does. You generally don't need to memorize this table; a capable client will pick the right tool from context.
Use advance_stage over generate_framework_analysis. advance_stage runs one framework stage per call and derives the stage index and prior-stage context automatically — call it repeatedly, checking is_complete in the job's output, until the analysis is done. generate_framework_analysis runs every stage in a single request and can exceed the request time limit on longer frameworks (SPADE, helix), leaving the decision stuck without a clear error. Reach for generate_framework_analysis only for short frameworks where one request comfortably covers every stage.
Building a decision context conversationally. start_decision_brief's decision_context is optional — if it isn't known yet, create the decision with just a title, then: interview_next_question (repeat until there's enough signal) → synthesize_context (saves a synthesized context to the decision, and logs it against the existing use-case catalog when it recognizes one) → optionally update_decision_context to edit the result → assess_decision (recommends complexity/framework/title, read-only) → apply_decision_setup (commits the recommendation, or your overrides) → advance_stage.
Guiding the interview with a use case. Pass an optional use_case_id (from list_use_cases) to start_decision_brief to steer interview_next_question toward that use case's guiding questions instead of a generic prompt — useful when the decision fits a known pattern (e.g. build-vs-buy, executive hiring). Some use cases require a Pro/Beta subscription; using a Free-tier account with a Pro use case returns a 403. This doesn't track question-by-question coverage — it only shapes the prompt.
Attaching documents. attach_document takes a file_url the server can fetch from — not raw file content — since MCP tool calls can't send multipart file uploads. Host the file somewhere reachable first (e.g. a signed URL), then call the tool with that URL, a file name, and a MIME type. Runs the same security validation and storage-quota checks as the web app's upload flow; poll get_job for the processing result. Free — no LLM call, subject to storage quota only.
Refining a stage. After a stage is generated, refine_stage takes a zero-based stage_index and plain-language instructions ("make it more concise", "add a risk analysis") and returns the original and revised content via get_job — it never saves anything. Show the revision to the user, then call apply_stage_revision with the content they approve (or edited); that overwrites the stage and records a new version in its history. refine_stage is metered by token usage; apply_stage_revision is free.
Exporting a brief. export_brief takes markdown, docx, or pdf. Markdown comes back inline as content; DOCX and PDF come back as a download url — treat it as sensitive, since anyone with the link can open the file. PDF is available on every plan (Free accounts get a branded footer); Markdown and DOCX require Pro, Beta, or Admin and return a 403 otherwise, matching the web app. Free — no LLM call.
Resources
Resources are read-only and cheaper for an agent to consult than a tool call:
| URI | Description |
|---|---|
deecee://frameworks | Same data as list_frameworks, as a resource |
deecee://use-cases | Same data as list_use_cases, as a resource |
deecee://decisions | Your past decisions, most recent first |
Prompts
run_full_decision — a guided prompt that walks a client through the entire lifecycle: create the brief, interview for context if needed, synthesize and confirm it, assess complexity and framework (pausing for your confirmation), let you choose stage-by-stage vs. all-at-once generation, run the analysis, then fetch and summarize the recommendation. Takes decision_title and decision_context arguments.
Auth and rate limits
The MCP server shares the same API keys, tier-based rate limits, and credit ledger as the REST API — a call through either transport counts against the same quota. See Errors & Rate Limits for the one difference: a rate-limited MCP call currently surfaces as a generic auth rejection rather than a distinct rate-limit error (the REST API returns a proper 429 with a retryAfter field).