MnogoReels MCP server

Create article from clip job

create_article

Idempotent

Generate a long-form article from a completed clip job's source video, including title, summary, chapters, transcript, and illustrations. Use for blog posts or show notes; free.

Instructions

Turns the source video of a completed clip job into a long-form article: title, SEO title and description, summary, sections, key takeaways, chapters with timestamps, up to 4 frames from the video as illustrations, and the full timed transcript. Free: spends no credits.

Use it for blog posts, show notes, chapter lists or the full transcript of a video that has already been clipped. It needs a clip job with status completed (create one with create_clip_job first). There is one article per source video per account: calling it again with any clip job of the same video returns the existing article instead of creating a new one; an article that failed cannot be regenerated through the API.

Returns article_id, status and the clip job the article was made from. Writing usually takes 1 to 3 minutes. Next, call get_article with wait_sec=50.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`clip_job_id`	Yes	Completed clip job whose source video the article is about (32 hex characters).

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes
`existing`	Yes	True when an article for this video already existed and was returned.
`next_step`	Yes
`article_id`	Yes
`clip_job_id`	Yes	Clip job the article was created from; may be another job of the same video.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations: it discloses cost ('Free: spends no credits'), the one-article-per-video-per-account constraint with re-call behavior returning the existing article, that failed articles cannot be regenerated via the API, and the 1-3 minute latency. These are exactly the side-effect and lifecycle facts an agent needs beyond idempotentHint/destructiveHint.

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 capability, then the output inventory, cost, prerequisites, uniqueness rule and next step. Dense but every sentence carries distinct information; the long enumeration of article fields is the only mildly excessive part given an output schema exists.

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?

An output schema exists, yet the description still names the key return fields (article_id, status, source clip job) and gives the timing and follow-up call. Combined with the failure and idempotency rules, an agent has everything required to invoke it correctly.

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 schema already documents the single clip_job_id parameter, making 3 the baseline. The description adds meaning beyond the schema by requiring the job be 'completed' and by explaining that any clip job of the same source video resolves to the same article, which affects how the parameter should be chosen.

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 ('turns the source video of a completed clip job into a long-form article') and enumerates exactly what the article contains. It is clearly distinguishable from siblings like get_article (retrieval) and create_clip_job (prerequisite).

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?

Explicit about when to use it ('blog posts, show notes, chapter lists or the full transcript of a video that has already been clipped'), the prerequisite ('needs a clip job with status completed, create one with create_clip_job first'), and the follow-up ('call get_article with wait_sec=50'). No ambiguity about routing.

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