The Cure Protocol

get_trial_related_research

Read-only

USE WHEN you have a trial (canonicalId from search_world_trials) and need the PUBLISHED RESEARCH around it, or when you want to find related registrations in registries this index does not ingest. Returns three separately-labelled layers: (1) registryDeclared — publications the registry record itself declares, with kind=results/background/derived/protocol, the strongest available evidence that a trial reported; (2) literature — Europe PMC records whose indexed text or accession list mentions one of the trial’s registration identifiers, with journal, year, DOI/PMID, open-access flag and citation count; (3) crossRegistryMentions — OTHER registry identifiers (ANZCTR, ChiCTR, JPRN, DRKS, CTRI, CTIS and more) found in the title/abstract of that literature, each flagged inIndex true/false. THIS IS A SIDECAR: nothing it returns is in the trial index or in any count, and an identifier with inIndex=false is a literature mention only — never report it as a trial this index holds. NEXT: get_world_trial for the canonical record, find_trial_registrations to check for double-counting.

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": {
      "canonicalId": "<canonicalId>"
    },
    "name": "get_trial_related_research"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum literature hits per identifier searched.
`include`	No	Comma-separated sections: declared, literature, crossref. Default all three.
`canonicalId`	Yes	Canonical trial id, e.g. NCT04333823 or ISRCTN50189673.

Output Schema

Name	Required	Description	Default
`data`	No	The answer. Shape depends on the tool; describe_tool documents it.
`_meta`	No	source, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "_meta": {
+      "additionalProperties": {},
+      "description": "source, generatedAt, sources (per-source lastSyncedAt and ageHours), rateLimit, disclaimer.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "data": {
+      "description": "The answer. Shape depends on the tool; describe_tool documents it."
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedOct 24, 2026

addedInput schema / properties / canonicalId / maxLength
```
Added value: +20000
```

addedInput schema / properties / include / anyOf

Added value: +[
+  {
+    "maxLength": 2000,
+    "type": "string"
+  },
+  {
+    "items": {
+      "maxLength": 200,
+      "type": "string"
+    },
+    "maxItems": 100,
+    "minItems": 1,
+    "type": "array"
+  }
+]

removedInput schema / properties / include / type
```
Removed value: -"string"
```

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Although readOnlyHint/openWorldHint already mark it as a safe open read, the description adds substantial context the annotations cannot: the three-layer structure, the kind=results/background/derived/protocol taxonomy, the open-access and citation fields, and the critical inIndex true/false distinction with an explicit instruction never to report an inIndex=false identifier as a held trial. That is exactly the kind of provenance/destruction-adjacent warning the burden falls on the description to carry.

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?

Well front-loaded with the USE WHEN trigger, then returns, then the sidecar caveat, then NEXT routing. It is on the long side, and the enumeration of registries (ANZCTR, ChiCTR, JPRN, DRKS, CTRI, CTIS and more) is the one passage that could be trimmed without losing decision-relevant 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?

For a three-parameter read tool with an output schema, the description covers everything an agent needs: precondition, argument source, shape and semantics of each returned layer, the double-counting trap, and where to go next. No ambiguity remains about how to call it or how to interpret what comes back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns an extra point by naming the three layers in a way that maps onto the include sections (declared/literature/crossref) and clarifying that crossRegistryMentions comes from literature abstracts. It adds no syntax guidance for limit or include beyond what the schema already documents, so it stops short of 5.

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?

States a specific verb+resource (fetch published research and cross-registry mentions around a trial) and enumerates the three labelled output layers, each with the meaning of its fields. It explicitly separates itself from search_literature, get_world_trial and find_trial_registrations, so an agent can pick it without opening any schema.

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?

"USE WHEN you have a trial (canonicalId from search_world_trials)" gives a precise precondition and names the upstream producer of the argument. It also closes with explicit routing (get_world_trial for the canonical record, find_trial_registrations for double-counting) and warns that nothing returned here is in the index or any count.

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

All The Cure Protocol 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.

Resources

Need Help?