Marcora

produce_plan

Produces (generates) the content a plan describes: the MCP equivalent of the plans board's Generate button. It writes a new document, saved to the user's Marcora workspace and linked to the plan.

When to use: the user asks to generate, produce or create the content for an existing plan ("produce that plan"). To create a NEW plan use create_plan; to edit plan fields use update_plan.

⚠️ Credits and duration: it uses team Studio Credits (charged at completion, cost-based: typically Quick 1-2, Multi-model 6-7) and takes 1-5 minutes. Too few credits (Quick needs 1, Multi-model 5) fails with insufficient_credits (402), nothing generated. Confirm with the user before producing a plan they didn't explicitly ask to produce.

Mode (optional, omit for defaults): generation_mode "quick" (one model) or "multi_model" (two drafts plus a synthesis); default Multi-model with a blueprint, Quick without. Quick only: ai_provider ("anthropic" default, "openai") and use_extended_thinking (default true; slower, costlier); ignored with Multi-model.

Requirements: the plan must be "Accepted". A Suggested plan needs update_plan { target_stage: "Accepted" } first; In_Process / Complete plans already have content (produced_content_id). The plan's prompt, targeting dimensions, context collections and project are used automatically, so set them with update_plan BEFORE producing.

Asynchronous on both paths, chosen from the plan: it returns at once with path ("blueprint" or "freeform") and a generation_id. Poll get_generation_status. On completion the plan moves to In_Process (produced_content_id set); the content reaching ready moves it to Complete.

Errors: Missing param: plan_uuid; NotFound; InputError: plan is in stage {stage}; invalid mode, provider or thinking value.

Present link_url exactly as returned; never retype, shorten, or rebuild a link.

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": {
      "plan_uuid": "<plan_uuid>"
    },
    "name": "produce_plan"
  }
}

Input Schema

Name	Required	Description
`plan_uuid`	Yes	Required. UUID of the Accepted plan to produce (from list_plans / get_plan / create_plan).
`ai_provider`	No	Optional. Quick mode only (ignored with multi_model): which provider writes the document. Default: anthropic.
`generation_mode`	No	Optional. "quick" writes the document with one model; "multi_model" writes two drafts and a synthesis. Default when omitted: multi_model for a plan with a blueprint, quick for one without.
`use_extended_thinking`	No	Optional. Quick mode only (ignored with multi_model): whether the model reasons at length before writing. Slower, and can use more Studio Credits. Default: true; pass false for a faster run.

Output Schema

Name	Required	Description
`path`	Yes	Which produce path ran: blueprint (generated from a blueprint) or freeform (no blueprint). Both are async.
`stage`	Yes	The plan's stage as of this response: Accepted on both paths — flips to In_Process when generation completes.
`message`	Yes	What happened + what to do next.
`link_url`	Yes	Shareable deep-link that opens the plans screen with this plan's detail overlay. Give this to the user.
`generation_id`	No	Both paths — poll get_generation_status with this id.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite annotations covering safety hints, the description adds substantial behavior the annotations cannot: Studio Credit consumption with typical costs, 1-5 minute duration, the specific `insufficient_credits` 402 failure with no output, asynchronous execution on both paths, and the returned `generation_id`/`path` with polling via `get_generation_status`. It also documents the state transitions to In_Process and Complete.

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-loads the core purpose, then organizes guidance into labeled sections (When to use, Credits, Mode, Requirements, Errors) making it scannable. It is dense but nearly every sentence adds operational detail; a few clauses (mode/provider repeats) restate the schema and could be trimmed.

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 4-parameter, non-idempotent, credit-consuming async mutation, the description covers preconditions, cost, latency, mode selection, polling, state transitions, and enumerated errors. With an output schema present, it correctly omits return-value documentation while still warning that `link_url` must be presented verbatim.

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 goes further by spelling out default derivation for `generation_mode` (multi_model with a blueprint, quick without), noting `ai_provider` and `use_extended_thinking` are ignored under multi_model, and flagging that extended thinking is slower and costlier. Only minor overlap with schema wording keeps it from a 5.

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?

Uses a specific verb+resource ('Produces (generates) the content a plan describes') and anchors it to a concrete analogy (the plans board's Generate button), clarifying that it writes a new document tied to an existing plan. It explicitly distinguishes itself from `create_plan` and `update_plan`, so an agent can separate the three without opening schemas.

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?

Provides an explicit 'When to use' (user asks to generate/produce content for an existing plan) plus named alternatives for adjacent intents (`create_plan`, `update_plan`). It also states prerequisites (plan must be 'Accepted', use `update_plan` with target_stage first) and a caution to confirm with the user before producing unrequested plans.

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

All Marcora 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?