OraFabric Medical Ontology Knowledge Base

Check relation

check_relation

Read-onlyIdempotent

Evidence for, against and null on one relationship between two named things. $0.03. If a name matches several concepts, returns ambiguous_concept and is not billed.

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": {
      "subject": "<subject>",
      "object": "<object>"
    },
    "name": "check_relation"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many findings to return per bucket. Raise it for a well-studied pair where 20 may only surface the most recent work.
`object`	Yes	The thing acted on.
`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.
`subject`	Yes	The acting thing.
`relation`	No	The specific claim to test. Use 'any' unless the question names a direction of effect. 'any' returns supporting, contradicting and null evidence across all relation types, which is usually more informative than confirming one.	any
`both_directions`	No	Also return evidence for the reverse relationship, object acting on subject. Set it when the direction of causation is itself the question, because the literature often reports both.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 9, 2026

addedInput schema / properties / both_directions / description

Added value: +"Also return evidence for the reverse relationship, object acting on subject. Set it when the direction of causation is itself the question, because the literature often reports both."

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 findings to return per bucket. Raise it for a well-studied pair where 20 may only surface the most recent work."

addedInput schema / properties / relation / description

Added value: +"The specific claim to test. Use 'any' unless the question names a direction of effect. 'any' returns supporting, contradicting and null evidence across all relation types, which is usually more informative than confirming one."

First observedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The annotations already establish the safe, read-only, idempotent profile, so the bar is lower. The description still adds real value beyond them: a stated cost of $0.03 and the failure mode that an ambiguous name returns ambiguous_concept and is not billed, which materially affects how an agent should retry. It stops short of describing latency, result size, or ranking.

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?

Three short sentences with zero waste; the core purpose is front-loaded and the cost and ambiguity caveat follow in the order an agent needs them. No restatement of the schema or annotations.

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 six parameters, a nested filters object and no output schema, the description should carry more of the return-value burden. 'Evidence for, against and null' plus the per-bucket limit hint at a three-bucket result, but the actual response shape, citation fields and ordering are never stated.

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 rich, including when to use evidence_from, min_evidence_strength and both_directions. The tool description itself adds nothing about subject, object, relation or filters, so it earns the baseline 3 rather than more.

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 gives a specific verb and resource: retrieve evidence for, against and null on one relationship between two named things. That is far more informative than the title 'Check relation'. It does not name or contrast with the sibling retrieve_evidence, which appears to overlap, so an agent cannot fully distinguish them from the description alone.

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?

Usage is implied by the framing (use it when you have two named things and want evidence about their relationship), and the ambiguous_concept clause tells the agent what happens when a name is not specific enough. However, there is no explicit when-not guidance and no comparison to explore_concept or retrieve_evidence, so routing between siblings is left to inference.

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.