Skip to main content
Glama
Sign In
ontopoc

ontopoc

by Longado
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

save_card

Records customer replies to data-interpretation card cells and open confirmation items, capturing only answers provided by a person and writing them after validation.

Instructions

记下客户对口径卡的答复，也可以记下“要确认的事”里能答复的事的答复。只记人说的客户答复：by（答复人）和 basis（出处）都来自人，不要自己填格，不要替客户答，不要按列名猜；只在人明确说了之后调用。校验不过整次不写，服务的说明原样返回。cells 每项 {id, value, note?, basis?}：id 来自 get_card，value 是那一格可选的值，null 表示清空。格的 value 只能是下面的值，种类看 id 冒号前的那段，等号后是意思：grain（一行是什么）：one_object=一行就是一个对象、event=一行是一次事件或一次修改（同一个东西有多行）、period=一行是一段时期的汇总、unsure=说不清；date（日期列是什么时间）：business=业务发生的日期、system=系统录入或修改的时间、fetched=取数的时间、unsure=说不清；amount（数值列能不能加）：flow=每行是这一笔自己的数，可以跨行相加、running=每次事件后的累计值、latest=截至最近一次的值、period_to_date=期初到期末的累计值、not_amount=不是数量（编号或代码）、unsure=说不清；complete（对象全不全）：full=数据里是全的、partial=数据里只有一部分、unsure=说不清。日期范围格 range 的 value 写 {"from": "YYYY-MM-DD" 或 null, "to": "YYYY-MM-DD" 或 null}。items 每项 {id, choice?, text?, basis?}：id 来自 run_overview 的 open_items，choice 的可选值看事的种类（unlinked：expected、incomplete；same_name、merged：distinct、same），没有 choice 时 text 必填。unlinked 答“数据没导全”（incomplete）时，服务会自动把另一端对象在卡上记成“只有一部分”，改答复时撤回，不用另发那一格。cells 和 items 至少给一样。写完返回 {card, items, answered}。

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>",
      "by": "<by>"
    },
    "name": "save_card"
  }
}

Input Schema

NameRequiredDescriptionDefault
byYes答复人，来自人，不要替人填
cellsNo口径卡上要记的格，形状见工具说明；只写人说了的
itemsNo要确认的事的答复，形状见工具说明；只写人说了的
saved_asYes运行的保存名，来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations the description carries the full load, and it does disclose real behavior: a failed validation writes nothing at all, the service's explanation is returned verbatim, and answering 'incomplete' on an unlinked item auto-marks the counterpart object as partial with automatic retraction if the answer changes. That is genuine side-effect disclosure beyond the schema. It stops short of stating permission/auth requirements or idempotency/overwrite semantics for re-saving the same cell.

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?

Purpose and the strictest constraints are front-loaded in the first three sentences, and nearly every clause carries information not present in structured fields (the enum vocabulary especially). It is still a dense single block of semicolon-separated enumerations that would be easier to act on if the value lists were broken out, but little of it is filler.

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 mutation tool with no annotations and no output schema, the description covers preconditions, write-failure semantics, side effects, cross-references for every id field, and even the return shape {card, items, answered}. What it leaves open is the behavior on repeated saves to the same cell and any authorization expectations — minor but not trivial for a write tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the schema carries zero enums, and the description supplies the entire value vocabulary that an agent cannot otherwise know: grain/date/amount/complete enumerations with meanings, the range object shape {"from","to"}, null meaning clear, items choice values by item type (unlinked vs same_name/merged), and the rule that text is required when choice is absent. This is substantial meaning added beyond the schema.

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: record the customer's answers on the 口径卡, and optionally answers to items in '要确认的事'. It also scopes what is NOT recorded ('只记人说的客户答复'), and the repeated pointers to get_card / run_overview as id sources make clear those are the read-side siblings while this is the write-side one.

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 an explicit precondition — '只在人明确说了之后调用' — plus repeated prohibitions against guessing or answering on the customer's behalf, and a minimum-content rule ('cells 和 items 至少给一样'). What is missing is differentiation from other write tools such as save_form or confirm_derived; the agent must infer that those handle forms/derived facts rather than the card.

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

Deploy Server

Other Tools