Skip to main content
Glama
Sign In
ontopoc

ontopoc

by Longado
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_questions

List model-generated, human-asked, and acceptance questions for a saved run, with answers, query paths, status, and evidence to review results.

Instructions

这次运行里模型出的题（model_round）、人问过的题（asked）和固定的验收问题（acceptance），带答案和查询路径。每道题有 status：answered 答出来了；no_data 数据里没有满足条件的对象；query_limit 查询写不出来、ontology_gap 本体缺回答它要的东西（reason_from_model 为 true 时是模型的判断；否则是代码查出来的原因，照 reason 告诉人）；needs_derived 要一个派生指标，derive 里是公式和试算，人同意后才 confirm_derived。evidence 是代码给的核对依据：filters 是查询里的筛选条件（before、after 是筛前筛后的对象数，removed_measure 是筛掉的那部分的合计），其中 not_in_question 的是模型自己加的、题目没提，该不该加由人定，不加用 drop_filter 去掉重算；merged 是被算成同一个的对象组（同一个名字下有几个不同的识别值）；found_elsewhere 是 no_data 时，这个值在别的对象里能找到的地方。口径卡：refused_by_card 是被卡上的哪一格拒答的（status 是 query_limit，reason 是代码给的），照 reason 告诉人，不要换问法绕过；evidence.card 是答案用了哪张表、数据到哪天（tables）、按哪几条口径（lines），incomplete 是对象在数据里只有一部分，要转告人。

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

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?

No annotations are provided, so the description has full responsibility for behavioral disclosure, and it delivers unusual depth: it defines every status value (answered, no_data, query_limit, ontology_gap, needs_derived), explains when reason_from_model is true versus when code supplied the reason, and describes the evidence branches (filters with before/after/removed_measure, merged, found_elsewhere, card.refused_by_card/tables/lines/incomplete). It does not say whether the operation is read-only or comment on result volume, but the benefit of what it does disclose outweighs these omissions.

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?

It is one dense block with no headings or bullets, so status semantics, evidence structure and 口径卡 handling run together. Almost every clause carries real information, but the undifferentiated layout makes it hard to scan, and some handling instructions (for example, don't rephrase to bypass) feel like operational policy rather than list-reading context.

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?

There is no output schema and no annotations, yet the description still thoroughly documents the response shape: categories, statuses, reason fields, evidence sub-fields and card metadata. For a single-parameter read tool, this is nearly complete; the only remaining unknowns are pagination and result size.

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% for the single saved_as parameter, and the schema itself notes it comes from list_runs or build_ontology. The description body adds nothing about saved_as, so the schema already does all the work here.

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 exactly what is returned: the questions from this run, split into model_round, asked and acceptance, each with its answer and query path. A specific resource and scope are given, but the description never uses a verb like "list" or "get", and it does not say how this tool differs from ask_question or fix_question, which sounds similar.

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?

The description implies usage: to read the current run's questions and their statuses, you call it with saved_as, which comes from list_runs or build_ontology. It also provides conditional handling for results: tell the human the reason instead of rephrasing to bypass refused_by_card; if the human agrees, call confirm_derived; and use drop_filter to drop a model-added filter. Yet it gives no explicit instruction on when to use this tool instead of ask_question or fix_question.

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