GenFlick

recipe plan run

native.recipe_plan_run

DestructiveIdempotent

Plan a run of a recipe in this project before starting it: one row per step (whether it runs once for every post or once per post), its credits, the total, and anything that stops it from running (an asked input still empty). Plans the first post (proof true) or the rest of the batch (proof false, once a proof exists). Spends nothing and starts nothing.

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_plan_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

A3.9/5.0

Behavior4/5

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

The annotations (openWorldHint=true, destructiveHint=true) leave an agent uncertain about side effects, and the description resolves this decisively with 'Spends nothing and starts nothing' while also describing the plan's contents (per-step rows, credit cost, total, blockers). It does not explain why the conservative destructive hint is set, so a small ambiguity remains.

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-loads the purpose and output shape, then the two modes, then the no-side-effect guarantee; nearly every clause carries new information. The parenthetical about once-per-post vs once-per-batch is slightly dense but warranted.

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 6-parameter, 5-required planning tool with an output schema, the description covers purpose, modes, output content, and side-effect profile. Missing only what the agent should do after blockers surface (e.g., fill the empty input and re-plan) and any relation to recipe_run_status.

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 50%, and the schema itself already documents proof, count, and inputs, so the description's paraphrase of proof/count adds little beyond it. It does add the useful notion of blockers being 'an asked input still empty' and implies the values must match between proof and rest runs, but says nothing about work_id, request_key, or read_skills.

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 ('plan') and resource ('a run of a recipe'), and distinguishes itself from the actual run by 'before starting it', so an agent can tell it apart from native.recipe_run without opening the schema. It never names that sibling explicitly, which keeps it just short of a 5.

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 clear sequencing guidance (plan before starting) and splits the two modes precisely: proof=true for the first post, proof=false for the rest of the batch 'once a proof exists'. It does not state when not to use it, nor name recipe_run as the tool that actually executes the plan.

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?