Marcora

create_blueprint

*SYNCHRONOUS — takes 1-3 minutes. This is expected; do not retry or assume an error.*
Use this tool to create a reusable blueprint template for generating content at scale. Blueprints define the structure and AI instructions for a document type.

Workflow:
1) Get category_id from list_content_categories.
2) Write content as a markdown template with structure and instructions for the AI.
3) After creating, use the returned blueprint_uuid with create_content (passing it as blueprint_uuid) to generate content.

The source_content field should be well-structured markdown with clear sections which represents your template. This is an example of the content you want this blueprint to output. The AI will analyze it and generate reference_content (a polished version), blueprint_dna (template analysis), input_instructions (guidance for users), and a summary. AI analyzes your content and generates multiple supporting fields.

If the user wishes to have more control over the creation of the blueprint itself, use the create_blueprint_draft tool instead. This tool will output a link_url for the user to iterate on the blueprint draft with the help of AI before publishing it as a blueprint.

**Links:** present `link_url` to the user exactly as returned — copy it character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

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": {
      "name": "<name>",
      "category_id": "<category_id>",
      "source_content": "<source_content>"
    },
    "name": "create_blueprint"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Name for the new blueprint (e.g. "Customer Case Study Template").
`category_id`	Yes	Content category id. Get valid IDs from list_content_categories.
`source_content`	Yes	Markdown template content. The AI analyzes this to derive structure, tone, and the polished reference_content. Use clear section headers and example text representative of what generated content should look like.

Output Schema

Name	Required	Description
`name`	Yes	Blueprint name.
`summary`	No	AI-generated summary of what this blueprint produces.
`category`	No	Content category this blueprint belongs to.
`link_url`	Yes	Direct link to view this blueprint in Marcora.
`created_at`	No	Unix timestamp of creation.
`blueprint_dna`	No	AI-generated analysis of the template structure, tone, and section descriptions.
`blueprint_uuid`	Yes	Unique identifier — use as blueprint_uuid in create_content.
`source_content`	No	The original template content you provided.
`team_visibility`	No	Visibility within your team (e.g. team, private).
`reference_content`	No	AI-polished reference version of the template content.
`input_instructions`	No	AI-generated guidance for users on what context to provide when generating from this blueprint.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare the operation is not read-only, not destructive, and not open-world; the description adds genuinely non-inferable behavior: the call is SYNCHRONOUS and takes 1-3 minutes, and the agent must not retry or treat that as an error. It also discloses the side effect that AI derives reference_content, blueprint_dna, input_instructions, and a summary from source_content, plus a strict rule about copying link_url verbatim.

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-loaded with the most operationally important fact (the sync latency warning) and organized into a scannable workflow. There is minor redundancy — "AI analyzes your content and generates multiple supporting fields" restates the field list given one sentence earlier — but nothing obscures the core instruction.

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 non-idempotent mutation with a 3-minute latency, the description covers prerequisites, downstream usage, latency, and the link_url handling contract. Small gaps remain: nothing is said about failure modes or whether name must be unique, though an output schema exists so return values need no explanation.

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?

All three parameters are already 100% described in the schema, so the baseline is 3. The description earns above baseline by explaining how source_content is consumed downstream (it is the example output the AI analyzes to derive structure, tone, and reference_content) and by reiterating the category_id provenance, which clarifies what a good value looks like rather than just its type.

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?

States a specific verb and resource ("create a reusable blueprint template for generating content at scale") and explains what a blueprint is ("structure and AI instructions for a document type"). It explicitly separates itself from the closest sibling by naming create_blueprint_draft as the alternative for user-driven iteration.

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 a numbered three-step workflow that names the prerequisite tool (list_content_categories for category_id) and the downstream consumer (create_content with blueprint_uuid). It also gives an explicit routing rule: use create_blueprint_draft instead when the user wants more control over iteration.

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?