Oliver's mTOR Atlas

Find contested claims

find_contradictions

Read-onlyIdempotent

Relations the Atlas marks as contested or that carry conflicting studies, with both sides of the evidence. status says which; breakdown splits the total. conflict carries WHY the studies disagree (Opposing result / Different context / Field dispute) with its basis. A contested relation with no conflicting study listed is flagged conflicting_studies_missing, and data_note says whether that is a real gap (Opposing result) or the recorded state because two published models compete (Field dispute, Different context); relations named in its note or boundary are shown in named_in_text (a mention is not evidence). Paged: pass next_offset as offset for the rest. Optionally limited to one entity.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_contradictions"
  }
}

Input Schema

Name	Required	Description
`brief`	No	Shorten the long boundary and note text (text_truncated is set); get_relation has the full text.
`limit`	No	Maximum 50; a larger value is capped at 50.
`dedupe`	No	Send a repeated study in full only once. Pass false for a full card every time.
`entity`	No
`offset`	No	For the next page: pass next_offset from the previous answer.
`only_contested`	No	Keep only relations the Atlas flags contested, not those that merely carry conflicting studies.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 13, 2026
- addedInput schema / properties / limit / description
```
Added value: +"Maximum 50; a larger value is capped at 50."
```
- changedInput schema / properties / limit / maximum
```
Previous value: -50New value: +9007199254740991
```

Changed4 schema fields changedOct 13, 2026

addedInput schema / properties / brief

Added value: +{
+  "default": false,
+  "description": "Shorten the long boundary and note text (text_truncated is set); get_relation has the full text.",
+  "type": "boolean"
+}

addedInput schema / properties / dedupe

Added value: +{
+  "default": true,
+  "description": "Send a repeated study in full only once. Pass false for a full card every time.",
+  "type": "boolean"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "For the next page: pass next_offset from the previous answer.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / only_contested

Added value: +{
+  "default": false,
+  "description": "Keep only relations the Atlas flags contested, not those that merely carry conflicting studies.",
+  "type": "boolean"
+}

First observedOct 1, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered; the description goes further by explaining what the result fields mean (status, breakdown, conflict reasons and their basis, conflicting_studies_missing, data_note) and that a mention in note/boundary is not evidence. Pagination via next_offset is also disclosed. It loses a point only for not stating result ordering or the practical cap interaction beyond what the schema already says.

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 resource and scope, then behavioral detail, with no filler sentences. It is dense to the point of being hard to parse in places — nested parentheticals ('Field dispute, Different context') and long run-on clauses — but every clause carries substantive information.

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

Completeness5/5

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

There is no output schema, so the description carries the full burden of explaining the return shape, and it does: it names the status, breakdown, conflict/basis, conflicting_studies_missing, data_note and named_in_text fields and their semantics. An agent can interpret the response and page through it without further documentation.

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 83%, so the parameters are largely self-documenting and the baseline is 3. The description only echoes two of them ('Optionally limited to one entity' for entity, 'pass next_offset as offset' for paging) and adds no meaning for only_contested, dedupe or brief beyond what the schema already states.

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?

Opens with a specific verb+resource+scope: relations the Atlas marks contested or that carry conflicting studies, returned with both sides of the evidence. That is clearly distinguishable from a generic relation listing, though it never names the sibling tools (find_relations, get_relation) it is being chosen over.

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 rather than stated: you call it when you want contested/conflicting relations, and 'Optionally limited to one entity' gives the scoping case. The only explicit routing cue is buried in a schema field ('get_relation has the full text'), and there is no statement of when to prefer find_relations or evidence_between instead.

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

All Oliver's mTOR Atlas 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.