GenFlick

recipe run

native.recipe_run

DestructiveIdempotent

Start a run of a recipe in this project; it spends credits up to credit_ceiling and saves its posts as drafts (Social) or ad creative awaiting approval (GenAds); nothing is published or launched. Always make the first post first (proof true) and show it. The rest (proof false) starts only from a finished first post the creator approved with the same inputs: set approve_proof true only when the creator has seen that first post and told you in this conversation to make the rest. Plan first with recipe_plan_run and keep credit_ceiling at or above its total. Reuse operation_id after an uncertain reply.

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": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.recipe_run"
  }
}

Input Schema

Name	Required	Description
`work_id`	Yes
`arguments`	Yes
`read_skills`	Yes	Exact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
`request_key`	Yes
`publication_proposal_id`	No	For native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
`expected_catalog_version`	Yes	For a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=true and openWorld=true, but the description adds the substantive context: credits are consumed up to a ceiling, output lands as Social drafts or GenAds creative awaiting approval, and nothing is published or launched. It also explains the idempotency semantics behind operation_id ('the same id is the same run'). It does not discuss failure modes or what happens when credit_ceiling is exceeded mid-run, which keeps it short of a 5. Note the 'nothing is published' line is not a contradiction of destructiveHint — the destruction is credit spend and draft creation, which the description discloses.

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 description is front-loaded with what the tool does and its side-effect profile before moving to the proof/approval protocol, and almost every clause carries an instruction the agent needs. It is dense with semicolons and parentheticals ('(proof true)', '(Social) or ad creative awaiting approval (GenAds)'), which costs a little readability, but nothing is filler.

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 six-parameter mutation with a nested arguments object and an output schema, the description covers the workflow, the approval gate, cost bounds and retry semantics, which is the bulk of what an agent needs to invoke it correctly. The remaining gap is the envelope parameters (work_id, request_key) and publication_proposal_id, which are neither described here nor fully described in the schema.

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?

With only 50% schema description coverage, the description does real work on the semantically hard parameters: proof is the first-post-only mode, approve_proof records creator approval and is only valid after they have seen the proof, credit_ceiling must be at or above the planned total, and the rest run must reuse the first post's inputs. It says nothing about work_id, request_key or publication_proposal_id, so it does not fully close the coverage gap.

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 clause names a specific verb and resource ('Start a run of a recipe in this project') and immediately states the two distinguishing consequences: it spends credits up to credit_ceiling and saves output as drafts rather than publishing. That cleanly separates it from recipe_plan_run (planning), recipe_run_status (polling) and recipe_list, so an agent can pick it 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?

The description gives an explicit operating sequence: plan first with recipe_plan_run and keep credit_ceiling at or above the planned total; run the first post with proof true and show it; only run the rest (proof false) after the creator approved that first post with the same inputs and said so in this conversation. It also covers the retry case ('Reuse operation_id after an uncertain reply'), which is the main ambiguous branch an agent will hit.

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

All GenFlick 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?