OraFabric Medical Ontology Knowledge Base

Explore concept

explore_concept

Read-onlyIdempotent

What is known around one gene, drug or disease: upstream, downstream and associations. $0.03.

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": {
      "concept": "<concept>"
    },
    "name": "explore_concept"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many relationships to return per direction. Raise it for a hub concept such as TP53 or EGFR, where 20 will only show the most common edges.
`concept`	Yes	One gene, drug or disease to walk outward from. A single entity, not a question. Use retrieve_evidence for a question. If the name may be ambiguous, resolve it first with the free resolve_concept.
`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.
`direction`	No	Which way to walk. 'downstream' returns what this concept acts on: what it causes, inhibits or treats. 'upstream' returns what acts on it: what regulates, inhibits or induces it. 'both' returns each separately and is the right default when the mechanism is not yet known.	both
`relations`	No	Restrict the walk to these relation types. Use it when the question is about one kind of link, ['inhibits','activates'] for regulation, ['treats','prevents'] for therapeutic claims. Leaving it unset returns every relation type and is usually what you want on a first pass.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 9, 2026

addedInput schema / properties / concept / description

Added value: +"One gene, drug or disease to walk outward from. A single entity, not a question. Use retrieve_evidence for a question. If the name may be ambiguous, resolve it first with the free resolve_concept."

addedInput schema / properties / direction / description

Added value: +"Which way to walk. 'downstream' returns what this concept acts on: what it causes, inhibits or treats. 'upstream' returns what acts on it: what regulates, inhibits or induces it. 'both' returns each separately and is the right default when the mechanism is not yet known."

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 / limit / description

Added value: +"How many relationships to return per direction. Raise it for a hub concept such as TP53 or EGFR, where 20 will only show the most common edges."

addedInput schema / properties / relations / description

Added value: +"Restrict the walk to these relation types. Use it when the question is about one kind of link, ['inhibits','activates'] for regulation, ['treats','prevents'] for therapeutic claims. Leaving it unset returns every relation type and is usually what you want on a first pass."

First observedNov 7, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description needn't repeat it. What the description does add is genuine and valuable: a per-call cost of $0.03, which is decision-relevant for an agent managing budget. It omits result size, ordering and whether the walk is bounded or exhaustive, which for a graph traversal would be useful additional context.

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

Conciseness5/5

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

Two clauses and a price, front-loaded with the resource and the scope. Nothing is spent on restating the title, the annotations or the schema, and the cost is placed where an agent will read it before committing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, a nested filters object and no output schema, an agent needs some sense of what the traversal returns — directions separated or merged, how relations are grouped. The description gives only a one-line orientation, leaning heavily on the rich schema to carry the rest. It is adequate but thin for a tool of this complexity.

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 parameter descriptions are unusually substantive, covering direction semantics, filter rationale and limit tuning. The tool description adds nothing about concept, direction, limit, relations or filters, so the baseline of 3 applies — the schema, not the description, is doing all of the semantic 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 names the resource precisely ('one gene, drug or disease') and the scope of the operation ('upstream, downstream and associations'), which is a clear verb-in-effect plus resource. It stops short of naming a sibling, so an agent cannot tell from the description alone how this differs from check_relation or retrieve_evidence, but the single-entity vs. question distinction is strongly implied.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance in the description text itself. The 'use for a question instead' and 'resolve ambiguous names first' guidance that would serve this purpose lives entirely in the schema parameter descriptions, so the top-level description provides no routing between this tool and its siblings.

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.