Skip to main content
Glama
Sign In
ontopoc

ontopoc

by Longado
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ask_question

Answers business questions by translating them into data queries and returning computed results with status and evidence, flagging ontology gaps or derived metrics for human confirmation.

Instructions

用数据回答一个业务问题：模型把问题写成查询，代码在数据上算答案。不给 question 就让模型出一组题。会调用模型，慢且花钱。每道题有 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": "ask_question"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionNo要问的业务问题；不写就让模型出一组题
saved_asYes运行的保存名，来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations and no output schema, the description carries the full burden and does so thoroughly: it warns the call is model-backed and '慢且花钱', enumerates every status value (answered, no_data, query_limit, ontology_gap, needs_derived) and explains what each means. It also documents the evidence payload (filters with before/after and removed_measure, not_in_question, merged, found_elsewhere) and card-refusal behavior including the instruction not to rephrase around a refusal.

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 and cost warning are front-loaded, which is good, but the remainder is a single dense run-on paragraph chaining status values and evidence fields with semicolons. The content largely earns its place, but the lack of grouping or enumeration makes it hard to parse on a fast read.

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 complex, model-backed tool with no output schema, the description does the heavy lifting by explaining return semantics in place of a schema. It omits only secondary details such as the fact that a run is persisted under saved_as and any sense of expected latency or cost magnitude.

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 description coverage is 100%, so both parameters are already documented, and the description's note about omitting the question largely repeats the schema text. The saved_as parameter, which is the required one, gets no additional explanation in the description beyond what the schema states.

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 clause '用数据回答一个业务问题：模型把问题写成查询，代码在数据上算答案' gives a specific verb, resource, and mechanism in one sentence. It also implicitly differentiates itself by naming the follow-up siblings it hands off to (confirm_derived, drop_filter), so an agent knows this is the entry point for answering, not for fixing or confirming.

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 a clear operational mode ('不给 question 就让模型出一组题') and describes decision points that route to siblings, such as '人同意后才 confirm_derived' and '不加用 drop_filter 去掉重算'. It never states an explicit when-not-to-use case or contrasts the main path against siblings like fix_question or list_questions, so it falls short of a 5.

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