Marcora

get_blueprint

Read-onlyIdempotent

Retrieves the full details of a specific blueprint by its UUID. Returns the blueprint's content, AI-generated analysis, and metadata.

Use list_blueprints to list all available blueprints and find the blueprint_uuid.

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": {
      "blueprint_uuid": "<blueprint_uuid>"
    },
    "name": "get_blueprint"
  }
}

Input Schema

Name	Required	Description	Default
`blueprint_uuid`	Yes	The blueprint's UUID, exactly as returned in the `blueprint_uuid` field of list_blueprints (or by create_blueprint / finalize_blueprint_draft). It is not the community-library id and not a name. The blueprint must belong to your current team or have been created by you, and blueprints marked private are only readable by their creator.

Output Schema

Name	Required	Description
`name`	Yes	Blueprint name.
`summary`	No	AI-generated summary of what this blueprint produces.
`web_url`	No	Direct URL to view this blueprint in Marcora.
`category`	No	Content category, or null.
`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 blueprint identifier.
`source_content`	No	The original template content.
`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.
`exchange_visibility`	No	Community exchange visibility (e.g. public, none).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, and an output schema exists, so the description's note that it returns content, analysis and metadata is largely redundant. The team-ownership and private-blueprint access restrictions appear only in the schema parameter text, not here, so the description itself adds little behavioral context.

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

Conciseness5/5

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

Two short sentences, purpose first, the lookup aid second, with no filler or restated title. Nothing could be removed without losing information.

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 one-parameter read tool with full annotation coverage and an output schema, the description covers purpose and how to obtain the UUID adequately. A note on when to prefer get_community_blueprint_details over this tool would close the only remaining gap.

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 coverage is 100% and the parameter description is unusually rich, explicitly ruling out the community-library id and names and spelling out team/creator permission rules. The description only echoes that the UUID comes from list_blueprints, so baseline 3 is appropriate.

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?

States a specific verb and resource ('Retrieves the full details of a specific blueprint by its UUID') and enumerates what comes back (content, AI-generated analysis, metadata). It separates itself from list_blueprints, but never mentions get_community_blueprint_details, the other single-blueprint reader, so sibling differentiation is only partial.

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?

Gives a concrete lookup path: 'Use list_blueprints to list all available blueprints and find the blueprint_uuid,' which tells the agent how to get the required argument. It stops short of any when-not-to-use guidance or naming the community-blueprint alternative for the same underlying blueprint.

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?