Skip to main content
Glama
ChengZiiii

opera-houdini-mcp

by ChengZiiii

save_recipe

Captures workflow knowledge as a searchable recipe, storing usage steps and fixes in a recipes file for future reference.

Instructions

把一条用法/流程知识写入指定 root 的 recipes 文件 (add-workflow-knowledge-capture,write,bridge-local 不连接 Houdini)。

触发时机(advisory):用户完成工作流后说"沉淀这些知识"时,agent 先用
get_selection 定位,再调 capture_workflow_snapshot 取快照;用法/流程
文档("怎么用这个 HDA""这个网络怎么搭")走本工具 save_recipe(写入即被
search_lessons 检索,无 draft 门槛),错误经验走 save_lesson(draft
门槛 + 指纹累积)。本工具是 advisory,不替代 verify_hou_api /
get_houdini_help / get_best_practices,也不替代目标 Houdini 版本的
live verification。

参数说明:
- title / problem / symptom / fix / category / severity /
  affected_versions: 必填;title 渲染为块上方 ``> title`` 注释行。
- severity: 必填,recipes severity 合法取值 low / medium / high
  (3 值,与 lesson 的 4 值不同)。
- verified_versions: 可选;缺省 "unknown"。
- recipe_id: 可选;引用**既有** ``### BP-NNN`` 块 id(格式
  ``BP-\d{3}``,非自定义新 id)。提供时**原地替换**该块 9 字段、
  不新增块(首块 ``> title`` 行同步更新),响应 action=updated;
  未提供时维持自增追加,响应 action=created。
- root: 可选 root 名;缺省 personal(唯一默认可写 root)。

返回:{status:success, recipe_id, root, severity, source,
immediately_searchable:true, action:created|updated};recipe_id 为
BP-NNN 自动生成(扫描既有块最大序号 + 1),**不接受自定义 id**;团队
root 写入 source 自动附 ``@<用户名>``(系统标注)。错误为 status=error
+ error={code,message,details}(非法 severity → ls_write_error 并列出
合法值;recipe_id 格式非法 → ls_write_error;引用不存在的 id →
ls_recipe_not_found 且 message 附既有 id 列表;只读团队 root →
root_not_writable;未知/不可用 root → ls_unknown_root)。整体过
apply_response_cap。

方法论沉淀协议(advisory,非强制):
- 沉淀内容是工作流的**原理 / 设计意图 / 方法论**(为什么这么搭),
  不是节点名与参数的复制粘贴;参数仅在用户要求或直接影响复现时收录。
- 正文索引用资产级标识(capture_workflow_snapshot 的 type_full / hda
  资产全名 + 版本),实例名仅辅助。
- **禁止本机路径入正文**:不写 HDA 库路径 / hip 完整路径(团队知识库
  跨机器误导源)。
- 改造 / 加深既有知识时先 search_lessons 定位既有 id,再传 recipe_id
  **原地更新**,**不得新增一条重复知识**。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctxYes
fixYes
rootNo
titleYes
problemYes
symptomYes
categoryYes
severityYes
recipe_idNo
affected_versionsYes
verified_versionsNo
Behavior5/5

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

With no annotations, the description fully discloses behavior: it performs a write, has no draft threshold, is immediately searchable, auto-generates recipe_id, conditionally replaces blocks, attaches @username for team roots, and details error codes. It also warns against storing local paths and notes advisory limitations relative to live verification.

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?

The description is long but every section earns its place: core purpose, trigger context, parameter semantics, return format, error handling, and methodology protocol. It is well-structured with clear subsections, front-loading the primary function, and avoids fluff or redundancy.

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 tool with 11 parameters, no output schema, and no annotations, the description is remarkably complete. It specifies return values ({status, recipe_id, root, severity, source, immediately_searchable, action}), every error scenario and code, and the methodology protocol. The only omission is ctx, but overall it fully compensates for missing structured metadata.

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 0%, so the description must explain parameters. It does so thoroughly for title/problem/symptom/fix/category/severity/affected_versions, severity value domain, verified_versions default, recipe_id format and replacement behavior, and root default. However, the required 'ctx' parameter is never mentioned in the 参数说明, leaving a small but real 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 description clearly states this tool writes a usage/workflow knowledge entry to a specified root's recipes file. It explicitly distinguishes itself from save_lesson ('用法/流程文档走本工具 save_recipe', '错误经验走 save_lesson'), demonstrating a specific verb+resource+scope and sibling differentiation.

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?

Provides explicit trigger timing ('用户完成工作流后说"沉淀这些知识"时'), a prescribed sequence (get_selection → capture_workflow_snapshot → save_recipe), and clear alternatives (save_lesson for error experiences; verify_hou_api / get_houdini_help / get_best_practices as non-substitutes). Also explains when to update existing recipes via recipe_id instead of creating duplicates.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ChengZiiii/opera-houdini-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server