Skip to main content
Glama
Sign In
ontopoc

ontopoc

by Longado
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_card

Retrieve a run's data card showing each table's row grain, date ranges and nulls, numeric column types, answered cells, and remaining blanks so analysts can confirm what the data means.

Instructions

一次运行的口径卡（数据是什么意思）：每张表一行是什么、日期列的最早最晚和空值、数值列的类型，以及已答复的格（answer：value、says、by、basis、at）和对象全不全。代码能算的已经算好，只有人能答的留空；blank 是还没说清的格数。文档运行没有卡，返回空的 tables。格的 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}。

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": "get_card"
  }
}

Input Schema

NameRequiredDescriptionDefault
saved_asYes运行的保存名，来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/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 burden and does well: it discloses that computed cells are pre-filled and only human-answerable cells are left blank, that blank is a count of unresolved cells, and that documentation runs return an empty tables collection. It omits any explicit read-only statement or description of the returned table/cell container shape, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, which is good, but the body is a long semicolon-chained block that crams the card contents and a five-category value glossary into one paragraph. Every element is arguably necessary (there is no output schema), yet the lack of structure makes it harder to scan than it needs to be.

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 one-parameter read tool with no output schema and no annotations, the description supplies the essential interpretive context: what the card holds, the allowed value vocabularies for grain/date/amount/complete, and the range object format. Only the outer return structure (how tables and cells are nested) is left implicit.

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?

There is a single parameter, saved_as, and schema coverage is 100% with the schema already stating it comes from list_runs or build_ontology. The description adds no further meaning about this parameter, so the baseline of 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 states the resource concretely: a per-run semantics card containing one row per table, date-column min/max and null counts, numeric column types, and answered cells with their value/says/by/basis/at fields. An agent knows exactly what it retrieves. It does not distinguish itself from siblings such as run_overview or ask_question, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: you fetch the card to learn what the data means, and the 'blank' count tells you what still needs a human answer (which hints at ask_question/save_card). The one explicit conditional is that documentation runs have no card and return empty tables, which is a useful edge case but not a when-to-use rule. No alternatives are named.

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