Skip to main content
Glama
Sign In
ontopoc

ontopoc

by Longado
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

drop_filter

Removes an approved model-added condition from a saved question, recomputes the answer with local code, and appends it as a new record attempt.

Instructions

去掉模型自己加在一道题上的一个条件，用本机代码重算，不调模型；新答案作为这道题新的一次追加到记录里并返回，想固定它再用 fix_question。用在人同意去掉模型自己加的条件之后（evidence.filters 里 not_in_question 的那些）。field、equals 两种写法都认：照 evidence.filters 里那一条写（字段不带表名），或照这道题 query.where 里那一条原样写（字段带不带表名以查询为准）。

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>",
      "question": "<question>",
      "field": "<field>",
      "equals": "<equals>"
    },
    "name": "drop_filter"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldYes要去掉的条件的字段：照 evidence.filters 里那一条写（不带表名），或照 query.where 里那一条原样写
equalsYes要去掉的条件的取值，和 evidence.filters 或 query.where 里那一条的取值一致，类型照原样
questionYes题目原文，来自 list_questions 或 ask_question
saved_asYes运行的保存名，来自 list_runs 或 build_ontology

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/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 recomputation is local with no model call (cost/determinism), and that the new answer is appended as a new attempt rather than overwriting existing records (non-destructive semantics). It does not cover failure behavior or what happens to prior attempts on error, which keeps it 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.

Conciseness4/5

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

Front-loaded with the core action and outcome, then the precondition, then the two input forms. It is a fairly long single paragraph and the field/equals explanation repeats the schema, but no sentence is pure 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?

No output schema and no annotations, so the description must cover return and behavior — it does state that the new answer is returned and appended as a new attempt. Precondition, provenance of saved_as/question (list_runs, build_ontology, list_questions) is left to the schema, which is adequate.

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%, so the baseline is 3. The description restates the two accepted ways to write field/equals (matching evidence.filters without table prefix, or query.where verbatim), but this duplicates what the schema property descriptions already say, adding little new meaning.

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?

Names a specific verb and resource: removes a condition the model added to a question, recomputes with local code (no model call), appends and returns a new answer. It also explicitly distinguishes itself from fix_question, which is named as the follow-up for locking the result in.

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

Usage Guidelines5/5

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

States the trigger condition precisely — only after the person has agreed to drop a model-added condition, specifically the not_in_question entries in evidence.filters — and names fix_question as the alternative for persisting the change. Both when-to-use and the next-step alternative are explicit.

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