Skip to main content
Glama
Sign In

Marcora

by ai.marcora.mcp
OverviewDiscussionsAdmin

create_content

Saves a new piece of content as a document in the user's Marcora workspace. Every successful call creates a new saved document, not a chat reply.

By default YOU write the content: call get_relevant_context with include_brand_foundation: true, write the piece from what it returns, then save it here with content. To save text the user already has ("save this exactly as written"), pass it as content unchanged: no context call, and not add_context, which stores reference material, not a document. If the user wants a draft in the chat instead, do not call this tool. To revise an existing document, use update_content (it edits in place; Marcora keeps version history), not a new document.

Pick exactly ONE input path. A call with both content and instructions is rejected.

  • content (the default): saves your markdown VERBATIM, synchronously, and consults NO context, so ground your draft with get_relevant_context first, as above. Cannot be combined with blueprint_uuid.

  • instructions: Marcora writes it. Use it only when the user asks Marcora to write it, a blueprint is used, or a plan is being fulfilled. It gathers the team's context itself, so on this path do NOT pre-fetch. Quick by default: synchronous, 45 seconds to about 3½ minutes (allow a long timeout); returns the content object.

  • instructions + generation_mode: "multi_model" (no blueprint): ASYNC; get_generation_status returns the finished document (3-5 minutes).

  • instructions + blueprint_uuid (from list_blueprints): ASYNC: returns a generation_id; poll get_generation_status until "completed" (3-5 minutes).

Title: there is no title parameter. The title is the document's first heading: start content with # <Title>, or state the title in instructions.

Present link_url to the user exactly as returned.

Building on existing documents: when you are writing it yourself, read them with get_content (find them with list_content) and write from them; reference_content_ids is rejected with content.

Referencing existing content when Marcora writes it (reference_content_ids): to have Marcora generate WITH REFERENCE to existing documents (a past post to echo, a brief to build on), pass their content UUIDs (from list_content, or list_content with search). The tool resolves each id server-side, pulls its full text and folds it into the generation prompt as reference material, so you do not need to paste document text into instructions. Valid only on the instructions paths (with or without blueprint_uuid); REJECTED with content. Unknown or inaccessible ids fail the whole call, so pass ids you got from a list/get tool.

Choosing a path for net-new content: write it yourself from get_relevant_context (with include_brand_foundation: true) and save it with content; this also covers text the user already wrote or approved. Use instructions only when (a) the user asks Marcora to write or generate it, (b) a blueprint is used (the user names one or asks for a template: instructions + blueprint_uuid), or (c) a plan is being fulfilled (produce_plan, or instructions + blueprint_uuid + plan_id). Do not call list_blueprints on every request to look for a template.

Title details: the title keeps following the first heading when the document is edited later. With instructions, if the user wants a specific title, say so in the instructions text (e.g. "Title it: Weekly Trends – Sept 16"). Never pass both content and instructions, not even to carry a title.

Optional inputs:

  1. category_id from list_content_categories.

  2. dimension_option_ids from list_targeting_dimensions.

  3. collection_ids from list_context_collections.

  4. generation_mode ("quick" or "multi_model"; default Multi-model with a blueprint, Quick without), and for Quick only ai_provider ("anthropic" default, or "openai") and use_extended_thinking (default true; slower, can cost more; false for a faster run). All three are instructions paths only; provider and thinking are ignored with Multi-model.

  5. reference_content_ids (see above; instructions paths only).

Studio Credits: the instructions paths use Studio Credits, charged when the document completes at the model's cost (1 credit = 5¢, rounded up; typically Quick 1-2, Multi-model 6-7). Starting needs 1 credit available for Quick, 5 for Multi-model; otherwise the call fails with an insufficient_credits error (code 402) and nothing is generated. Saving content uses none.

Plan integration (additive):

  • When the user has an active plan they want to fulfil, pass plan_id with the plan's UUID. The content is linked to the plan and the plan moves to In_Process automatically.

  • plan_id is purely associative: the endpoint does NOT look up plan parameters. Use get_plan to read prompt, blueprint_id, project_id, collection IDs and targeting dimension IDs, then pass them explicitly here alongside plan_id.

  • Do NOT pass plan_id if the plan is in Complete stage. Call get_plan first; if Complete, call update_plan with target_stage='Accepted' to re-open it (confirm with the user), then call create_content.

  • Linkage scope: plan_id links plan and content automatically ONLY with blueprint_uuid (the async path). The synchronous paths accept plan_id without error but do not establish the link. For the standard plan-fulfilment flow, pass blueprint_uuid from the plan.

  • An invalid plan_id (not found, wrong format) is logged and content creation still SUCCEEDS.

Links: copy link_url character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentNoPre-written text to save directly as a document (no AI generation). Mutually exclusive with `instructions` — never send both, not even to carry a title — and cannot be combined with `blueprint_uuid`. Prefer markdown-formatted content. Start with the title as a level-1 heading (`# <Title>` on the first line): the document title is taken from the first heading. Use a markdown conversion tool first if you have a url or html.
plan_idNoOptional plan UUID (from create_plan / list_plans / get_plan — use plan_uuid, not the integer id). Associates the new content with the plan and triggers an automatic stage transition to In_Process. Linkage applies only when used WITH blueprint_uuid (the async blueprint-generation path); sync paths accept the field without error but do not auto-link. Invalid plan_id is logged but does NOT fail content creation. Do NOT pass if the plan is in Complete stage — call update_plan target_stage='Accepted' first.
project_idNoOptional project UUID (from list_projects) to associate the new content with. When set, the project's Project Context (brief + project context items) is automatically included in generation.
ai_providerNoOptional. Quick mode only (ignored with multi_model): which provider writes the document. Default: anthropic.
category_idNoOptional content category id from list_content_categories. Organizational only — does not change generation behavior.
instructionsNoAI prompt describing what to create. Mutually exclusive with `content`. Required if `content` is omitted. If the user wants a specific document title, state it in this text — the title is taken from the generated document's first heading.
blueprint_uuidNoUUID of a blueprint to generate from (get from list_blueprints). When set, this becomes an ASYNC call — poll get_generation_status with the returned generation_id. Only valid with `instructions`.
collection_idsNoOptional context collection IDs (from list_context_collections) to include during generation, on top of the always-on Brand Foundation + Reference Library + Project Context.
generation_modeNoOptional, with `instructions` only. "quick" writes the document with one model; "multi_model" writes two drafts and a synthesis (asynchronous: returns a generation_id to poll). Default when omitted: multi_model with `blueprint_uuid`, quick without.
dimension_option_idsNoOptional targeting dimension OPTION IDs (from list_targeting_dimensions — drill into each dimension's options) to shape the generation for a specific audience (e.g. persona, industry, buying stage).
reference_content_idsNoOptional content UUIDs (from list_content, or list_content with `search`) whose full text is folded into the generation prompt as reference material. The canonical way to have Marcora write with reference to existing documents — no need to paste their text into `instructions`. Valid only on the generation paths (`instructions`, with or without `blueprint_uuid`); rejected with the verbatim `content` path. An unknown or inaccessible id fails the whole call (never silently skipped).
use_extended_thinkingNoOptional. 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.
confirm_private_sourcesNoPass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document only, and expires in 5 minutes. Once released, those items stay released for that document, so later writes there will not ask again.

Output Schema

NameRequiredDescriptionDefault
titleNoDocument title (only present when the document is returned directly, not with generation_id).
contentNoDocument content in markdown (only present when the document is returned directly, not with generation_id).
link_urlNoDirect URL to view/open this content in Marcora (only present when the document is returned directly, not with generation_id).
content_idNoUnique identifier — use as content_id in get_content and share tools (only present when the document is returned directly, not with generation_id).
generation_idNoUUID to track async generation — pass to get_generation_status to poll for completion (only present with a blueprint_uuid or generation_mode multi_model).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / confirm_private_sources / description
      Previous value: -"Pass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document and that one write, and expires in 5 minutes."New value: +"Pass only after the user agrees. A write that would put Only me material this session read into a team-visible document is refused with a confirmation token; repeat the same call with that token here only once the user has said yes. The token releases only the items it names, for that document only, and expires in 5 minutes. Once released, those items stay released for that document, so later writes there will not ask again."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the write/safety profile; the description goes well beyond with sync vs async behavior and durations, the 402 insufficient_credits failure and its credit pricing, invalid plan_id being logged without failing, and the private-source confirmation-token flow with its 5-minute expiry. These are exactly the operational traits an agent needs and none are recoverable from annotations.

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

Conciseness3/5

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

It is front-loaded and organized under bold headings, but there is real redundancy: the title-as-first-heading rule appears twice (under 'Title:' and again under 'Title details:'), and the content-vs-instructions choice is restated three separate times. For a 13-parameter tool some length is warranted, yet pruning the repeated path guidance would lose nothing.

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?

Thorough for a complex branching tool with 13 parameters and optional ones: it covers path selection, title handling, plan linkage scope, credit preconditions, and the private-source confirmation flow. An output schema exists, so it correctly does not spend words explaining return values beyond telling the agent to poll get_generation_status.

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, but the description adds relational semantics the schema cannot express well: 'Pick exactly ONE input path', the rejection of content+instructions and content+blueprint_uuid, and the rejection of reference_content_ids with content. It also adds cost and latency consequences per path. Some of this is duplicated in the schema descriptions, so it is not a full 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?

Opens with a specific verb and resource — 'Saves a new piece of content as a document in the user's Marcora workspace' — and immediately distinguishes the output from a chat reply. It also names the sibling tools it is not (add_context, update_content), so an agent can route correctly without opening a 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 rules per path, explicit when-NOT rules ('If the user wants a draft in the chat instead, do not call this tool'; 'Do not call `list_blueprints` on every request'), and names the alternatives with their conditions (update_content for revisions, add_context for reference material). The 'Choosing a path for net-new content' block reduces the decision to three enumerated cases.

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

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