Skip to main content
Glama

List registered trials

list_trials
Read-onlyIdempotent

Use when asked about clinical trials. Registered trials from the Greencyclepedia snapshot of ClinicalTrials.gov (trials whose intervention is named cannabis, a cannabinoid, cannabidiol, THC or a related medicine): identifier, title, status, phase, enrolment, conditions, countries, start date, the Greencyclepedia compounds involved and the registry link, newest snapshot first. Intervention names that state an amount are left out. Titles are third party text. Educational reference, not medical advice. Example arguments: {"query":"epilepsy","limit":5}.

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": "list_trials"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many items to return, at most 25.
phaseNoPhase as registered.
queryNoWords in the title, the conditions or the MeSH terms, for example "epilepsy" or "chronic pain".
offsetNoSkip this many matching trials (for paging).
statusNoOverall status as registered.
compoundNoGreencyclepedia compound id or name, for example "cbd".
conditionNoGreencyclepedia condition id, name or other name, for example "cancer", "glioblastoma" or "sleep": the trials Greencyclepedia counts for that condition (only conditions with a tally; the answer says when there is none).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / compound / description
      Previous value: -"Atlas compound id or name, for example \"cbd\"."New value: +"Greencyclepedia compound id or name, for example \"cbd\"."
    • changedInput schema / properties / condition / description
      Previous value: -"Atlas condition id, name or other name, for example \"cancer\", \"glioblastoma\" or \"sleep\": the trials the atlas counts for that condition (only conditions with a tally; the answer says when there is none)."New value: +"Greencyclepedia condition id, name or other name, for example \"cancer\", \"glioblastoma\" or \"sleep\": the trials Greencyclepedia counts for that condition (only conditions with a tally; the answer says when there is none)."
  2. Changed1 schema field changed
    • addedInput schema / properties / condition
      Added value: +{
      +  "description": "Atlas condition id, name or other name, for example \"cancer\", \"glioblastoma\" or \"sleep\": the trials the atlas counts for that condition (only conditions with a tally; the answer says when there is none).",
      +  "maxLength": 120,
      +  "type": "string"
      +}
  3. First observed

TDQS

A3.6/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 covered and the description's job is to add context. It does add real behavior: newest-snapshot-first ordering, an exclusion rule (interventions naming an amount are dropped), a warning that titles are third-party text, and a note that the condition filter only covers conditions with a tally. It still says nothing about paging behavior or the response envelope, which matters for a 7-parameter list tool.

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?

It is front-loaded with the trigger condition, then the data provenance, then the returned fields, which is the right order for an agent skimming. The intervention-name enumeration and the long field list make it dense, but each clause carries information and there is no filler.

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, listing the returned fields is the right compensating move and it does so. Seven optional parameters and a snapshot-ordering guarantee are covered adequately; only pagination semantics across offset/limit and the empty-result shape are left implicit.

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%, so every parameter including the two enums is already documented, which sets the baseline at 3. The description contributes a concrete example invocation and re-states the condition-tally nuance that also lives in the schema, but adds no query syntax, matching semantics, or interaction rules between filters (e.g. compound plus condition) beyond what the schema says.

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 a specific resource (registered clinical trials from a named ClinicalTrials.gov snapshot) and scopes it tightly to trials whose intervention is cannabis, a cannabinoid, cannabidiol, THC or a related medicine, then enumerates the returned fields. That is well beyond restating the title. It stops short of a 5 because it never distinguishes itself from the sibling find_studies, so an agent must still guess which search surface to pick.

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

Usage Guidelines4/5

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

"Use when asked about clinical trials" gives an explicit entry condition, and "Educational reference, not medical advice" sets a real usage constraint. No when-not conditions and no alternatives are named, so there is nothing to route the agent between this tool and find_studies or search.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.