Skip to main content
Glama
Sign In

Marcora

by ai.marcora.mcp
OverviewDiscussionsAdmin

get_generation_status

Read-onlyIdempotent

Checks the status of an async generation by generation_id. Read-only. These flows return a generation_id you can poll here:

  • create_content with a blueprint_uuid or generation_mode: "multi_model" (document generation), and produce_plan;

  • ask_content_assistant (the in-document Content Assistant);

  • apply_grounding_fix (each job in jobs[]; jobs whose fixes land in the same document share one generation_id, so poll each distinct id once).

The response always includes status, generation_id and flow_type, plus generation_mode ("quick" or "multi_model") when known. content is null until the run finishes: keep polling.

Document generation (flow_type != "ai_assistant"): finishes at status "completed". content = { content_id, name, link_url } (plus blueprint_id with a blueprint). Give link_url to the user to review in Marcora; you don't need get_content unless they later ask about the body.

Content Assistant flow (flow_type == "ai_assistant", also used by apply_grounding_fix): finishes at status "complete". content = { content_id, name, link_url, assistant_summary, document_updated, current_content }. document_updated says whether the turn this run produced changed the document body (false for a reply-only run, or a grounding fix that was already covered).

status tracks THIS run; content is the document's LIVE current state (including the user's own later edits), while assistant_summary and document_updated describe the turn this run produced.

Statuses: pending, processing, streaming, complete (Content Assistant) / completed (blueprint), failed.

Present link_url exactly as returned.

Content fields:

  • assistant_summary: the assistant reply this run produced, as the sidebar thread shows it. Null if the run has written no reply, or it was written before runs were tracked; a reply that used sources you cannot open comes back as a notice.

  • document_updated: whether the turn this run produced changed the document body. For a shared generation_id from apply_grounding_fix, it covers every finding in that run.

  • current_content: the document's current markdown.

Returning the live document is deliberate: a stale snapshot isn't useful, the current version is. When the user has the document open in Marcora, the reply and any edits already streamed in live via the realtime channel; polling here is for headless callers, or to retrieve the current document and this run's reply text.

Links: copy link_url 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": {
      "generation_id": "<generation_id>"
    },
    "name": "get_generation_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
generation_idYesThe generation ID (UUID) returned by create_content (with blueprint_uuid or generation_mode multi_model), produce_plan, or ask_content_assistant.

Output Schema

NameRequiredDescriptionDefault
statusNoStatus of THIS generation_id. Terminal is "completed" for blueprint runs, "complete" for Content Assistant runs; "failed" on error.
contentNoNull until the run completes. For ai_assistant, reflects the CURRENT document, with the assistant turn THIS run produced. Shape depends on flow_type.
flow_typeNoWhich flow produced this generation: "blueprint" (generated from a blueprint), "document" (generated without a blueprint, e.g. Multi-model create_content or produce_plan without a blueprint) or "ai_assistant" (ask_content_assistant).
generation_idNoThe generation ID being checked (UUID).
generation_modeNoHow the document is generated: quick (one model) or multi_model (two drafts and a synthesis). Omitted when not recorded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses a lot: status names, content is null until completion, the difference between run status and live document content, and the meaning of document_updated and assistant_summary. It also warns about shared generation_ids for apply_grounding_fix jobs and live-editing overlap.

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?

The purpose is front-loaded and the response semantics are organized into clear sections. The definition is long because the async behavior is complex, but the repeated link-copy instruction is slightly redundant and could be tightened.

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 polling tool with a real output schema and complex flow-specific behavior, the description covers the essential decision points: when to poll, what statuses mean, what the returned fields mean, and when not to chase content. No material gap is apparent.

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?

The schema already documents the single generation_id parameter at 100% coverage, so the baseline is 3. The description adds provenance by naming the upstream tools and the apply_grounding_fix shared-ID nuance that the schema does not mention.

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?

The first sentence names the exact operation: checks the status of an async generation by generation_id. It distinguishes the tool from siblings by flagging it read-only and by showing which upstream flows return IDs that should be polled here.

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?

It explicitly lists the flows that produce IDs (create_content, produce_plan, ask_content_assistant, apply_grounding_fix) and says when polling is necessary versus when realtime streaming already covers it. It also explains that get_content is not needed for document generation unless the user later asks about the body.

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