Skip to main content
Glama

export_forms

Export ontology object forms as one CSV per object plus a readme, saving them to a local folder and returning file paths and byte counts.

Instructions

按对象表单导出:每个对象一张 CSV(主键、展示、中文名称、英文名称、描述、类型、长度、属性类型)和一份说明。导入契约还没实测,说明里写着导入前要测。文件写到本机的一个文件夹(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_forms"
  }
}

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.6/5.0
Behavior5/5

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

No annotations are provided, so the weight of behavioral disclosure falls on the description, and the description meets that challenge: it states that same-named files are overwritten, that a manifest file .ontopoc-export.json causes stale files from previous exports to be deleted (listed in 'removed'), that files outside the manifest are untouched, that invalid file names abort the entire export with no files written, and that the return value omits file content.

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 definition is dense and front-loaded, with the export shape first, then write behavior, then the error condition. Every clause contributes information, but it is delivered as one long paragraph rather than broken into discrete points, which slightly hurts scanability.

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?

Given the two-parameter schema, the absence of an output schema, and the need to explain a side-effecting file write, the description covers everything that an agent needs: output shape, the deletion and manifest semantics, the overwrite rule, the all-or-nothing failure mode, and the untested import caveat.

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 100%, so both parameters are already documented; the description still adds value by stating out_dir's default location and the overwrite semantics that apply to it, and by tying saved_as to a run name. This goes beyond restating the schema, though it does not add new syntax details for the paths.

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 opening phrase '按对象表单导出' names both the verb and the resource and immediately specifies what the output is: one CSV per object, listing its columns plus a readme file. This distinguishes it from siblings such as export_ttl, export_mermaid, and export_pipeline_spec without having to name them.

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?

The context for using this tool is clear: export object forms as CSV files into a local folder, with a note that the import contract is untested and should be tested before use. It does not explicitly compare when to choose this tool over the other export_* siblings, but the format-specific framing makes the choice self-evident.

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