OraFabric Medical Ontology Knowledge Base

Retrieve evidence

retrieve_evidence

Read-onlyIdempotent

Search the whole knowledge base for a research question. Returns an evidence pack: findings, a subgraph and the papers. $0.03. The model writes the answer.

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": {
      "query": "<query>"
    },
    "name": "retrieve_evidence"
  }
}

Input Schema

Name	Required	Description
`query`	Yes	The research question, up to 1,000 characters.
`filters`	No	Narrow the evidence before it is returned. Filtering here is better than filtering the result afterwards, because the retrieval budget is then spent on evidence that qualifies.
`max_evidence`	No	How many findings to retrieve. Lower it to around 20 for a narrow factual question; raise it towards 100 when the question spans several mechanisms or you are looking for contradictions, which only appear once coverage is wide enough.
`include_hypotheses`	No	Include author interpretations and hypotheses alongside observed findings, returned in a separate bucket. Keep it on when the question is about mechanism; turn it off when you need only what was measured.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 9, 2026

changedInput schema / properties / filters / description

Previous value: -"Optional. Narrow the evidence by subject, study design, year or strength."New value: +"Narrow the evidence before it is returned. Filtering here is better than filtering the result afterwards, because the retrieval budget is then spent on evidence that qualifies."

addedInput schema / properties / filters / properties / evidence_from / description

Added value: +"Restrict to findings from these experimental systems. This is the most useful filter: a relationship shown in a cell line and the same relationship shown in human tumour samples are not equally strong. Use ['human','tumor_sample'] for clinical questions, ['cell_line','organoid'] for mechanism."

addedInput schema / properties / filters / properties / min_evidence_strength / description

Added value: +"Drop findings below this strength. Leave unset on a first pass. Most mechanistic findings in this corpus are rated low or very_low because they come from single in vitro studies, and filtering to 'high' can empty the result. Raise it only when too much weak evidence is coming back."

addedInput schema / properties / filters / properties / study_designs / description

Added value: +"Restrict to these study designs, for example randomized controlled trial or cohort study. Use it when the question is about clinical effect rather than mechanism."

addedInput schema / properties / filters / properties / year_from / description

Added value: +"Earliest publication year. The knowledge base covers PubMed Central open access from 2020, so a value below that has no effect."

addedInput schema / properties / filters / properties / year_to / description

Added value: +"Latest publication year. Set it only when the question is explicitly historical. Excluding recent work usually removes the best evidence."

addedInput schema / properties / include_hypotheses / description

Added value: +"Include author interpretations and hypotheses alongside observed findings, returned in a separate bucket. Keep it on when the question is about mechanism; turn it off when you need only what was measured."

addedInput schema / properties / max_evidence / description

Added value: +"How many findings to retrieve. Lower it to around 20 for a narrow factual question; raise it towards 100 when the question spans several mechanisms or you are looking for contradictions, which only appear once coverage is wide enough."

First observedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real context the annotations cannot: a stated cost of $0.03, the composition of the returned evidence pack, and the important clarification that no answer is generated -- the model must write it. It omits failure modes and any note on result size beyond the schema's max_evidence.

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?

Four short sentences, front-loaded with the core action and scope before pricing and return details. Every sentence carries information, though 'The model writes the answer' is terse enough to be slightly ambiguous on first 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?

With no output schema, the description must sketch the return value, and it does so at the right level: findings, a subgraph, and papers. Pricing and the no-generated-answer caveat fill the gaps an agent would otherwise have to discover by calling. There is no output schema, but the description is sufficient for correct invocation.

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% and the filter sub-properties carry unusually rich guidance (when to set year_to, why min_evidence_strength should stay unset on a first pass, which evidence_from values suit clinical vs mechanism questions). The description adds nothing about parameters itself, 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?

States a specific verb and resource -- 'Search the whole knowledge base for a research question' -- and names the return shape (findings, subgraph, papers). This is clearly distinguishable from the sibling tools get_paper, explore_concept and check_relation, though it never names them explicitly to reinforce that contrast.

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 phrase 'for a research question' implicitly scopes usage to question-answering rather than concept lookup or paper fetch, and 'The model writes the answer' signals this is a retrieval step, not a QA endpoint. However, there is no explicit when-to-use/when-not guidance and no sibling is named as the alternative for narrower lookups.

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

All OraFabric Medical Ontology Knowledge Base tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.