Skip to main content
Glama

export_pipeline_spec

Export a pipeline requirements spec as Markdown and JSON: per-table cleaning, joins, schedules, computed columns and validations, each with its source. No processing is executed.

Instructions

生成编排需求单,交给搭管道的人:把体检、要确认的事、口径卡、派生指标和采纳的规则里已经说了的“这份数据要怎么加工才能算对”合成一份清单——每张表要做的清洗、表之间怎么关联、按期取数、计算列、编排后的校验、还没说清的;每条写明来源(代码查出、客户答复、人确认)。写出 编排需求单.md 和 编排需求单.json。只描述要做什么,不执行加工,不调用模型,没有模型 key 也能导出。文档运行和没通过核验的运行没有需求单,服务的说明作为工具错误原样返回。文件写到本机的一个文件夹(out_dir,默认在下载文件夹里),同名覆盖,只返回文件的路径和字节数 {dir, files: [{name, path, bytes}], total_bytes, removed},不返回文件内容。文件夹里会留一份清单 .ontopoc-export.json,记着这一类导出这次写了哪些文件;再导出到同一个文件夹时,上次清单里有、这次没有的文件会被删掉(removed 是删掉的文件名),清单以外的文件不碰。文件名必须是单纯的文件名,否则整次导出报错、一个文件也不写。

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": {
      "saved_as": "<saved_as>"
    },
    "name": "export_pipeline_spec"
  }
}

Input Schema

NameRequiredDescriptionDefault
out_dirNo导出文件写到哪个文件夹,必须是绝对路径;不写就是 ~/Downloads/OntoPoc/<运行保存名去掉 .json>/<forms|ttl|mermaid|pipeline>/
saved_asYes运行的保存名,来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations present the description carries the full burden and does so: no execution, no model invocation, no key required, error behavior for unverified runs, files written to a local folder with same-name overwrite, and only paths plus byte counts returned rather than content. It also discloses the .ontopoc-export.json manifest and the deletion of files from a previous manifest (reported in `removed`) while leaving files outside the manifest untouched, and the all-or-nothing failure when a file name is not a plain name.

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?

It is a single dense block, but it is front-loaded with the artifact and its purpose before the behavioral constraints, and each clause (what gets merged, what gets written, what is returned, what gets removed) carries distinct information. Minor cost: it reads as one long run-on sentence rather than separated sections.

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 non-trivial export tool with no annotations and no output schema, the description covers the source content, the two output files, the non-execution guarantee, the error path, the default directory, the overwrite/cleanup semantics and the exact return shape {dir, files, total_bytes, removed}. Nothing an agent needs in order to call it correctly is missing.

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 100%, so both `out_dir` (absolute path, default under ~/Downloads/OntoPoc/...) and `saved_as` (from list_runs or build_ontology) are already documented in the schema. The description only restates the default folder location and does not add syntax or resolution detail beyond it, so baseline 3 applies.

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?

The description opens with a specific verb and artifact: generating an orchestration requirement document that consolidates health checks, items to confirm, caliber cards, derived metrics and adopted rules into a per-table checklist. That makes it distinguishable in content from the format-export siblings (export_forms, export_ttl, export_mermaid), though it never names them explicitly to draw the contrast.

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?

It gives usable conditions: it only describes what to do and never executes processing or calls a model, so no model key is needed, and runs whose documents failed verification have no requirement sheet (the service's explanation comes back as a tool error). What is missing is an explicit statement of when to pick this over the other export_* tools.

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