GenFlick

recipe save

native.recipe_save

DestructiveIdempotent

Save a recipe from a full graph. Without recipe_id this makes a new recipe in this project (in an account chat, name made_in and made_in_host_id); with recipe_id and the expected_revision you read, it saves the next revision, and a stale expected_revision is refused. The graph is checked before it is saved and the refusal lists what to fix. Read the recipes skill's steps section for the step kinds and ports. Saving runs nothing and spends nothing. 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_save"
  }
}

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.2/5.0

Behavior4/5

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

Annotations already declare mutation, destructiveness, idempotency and open-world access; the description adds genuinely new behavior — graph validation happens before save with a refusal listing fixes, stale revisions are rejected, saving neither runs nor spends, and operation_id can be reused after an uncertain reply. The one unexplained gap is why destructiveHint=true (whether the prior revision's graph is retained), which the description never addresses.

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?

Opens with the core action, then lays out create vs. update, failure behavior, prerequisites, cost, and retry in short declarative sentences. Every sentence carries operational information; nothing is padding.

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 tool with heavy nested graph schema, an output schema, and rich annotations, the description covers mode selection, validation, failure reporting, side-effect cost, and idempotent retry. The residual gap is scoping and lifecycle detail around work_id and what a successful save returns, though the output schema partially covers the latter.

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 description compensates for the key discriminators — recipe_id selects create vs. update, expected_revision is a concurrency guard, made_in/made_in_host_id apply only in account chats, operation_id is a retry token. It adds nothing about work_id or the arguments.graph structure, leaving that to the schema and the external skill reference.

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 ("Save a recipe from a full graph") and then splits the operation into its two distinct modes — new recipe vs. next revision — so the agent knows exactly what it is invoking. The mention of made_in/made_in_host_id for account chats pins down scoping that no sibling tool name conveys.

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 explicit conditional guidance: omit recipe_id to create, supply recipe_id plus the expected_revision you read to update, and points to the recipes skill's steps section for step kinds and ports. It stops short of naming alternatives (recipe_read, recipe_list, recipe_plan_run, recipe_run), so the agent must infer that reading precedes revision-saving.

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?