Blossom Research

Count clinical trials

count_trials

Read-onlyIdempotent

Count clinical trials matching filters, including registrationNumbers, supported trialState/trialStates values, and deviceFamily='pacemaker_or_icd' for recorded protocol-eligibility mentions. Returns { count: , sample: <top 5 representative trials for citation> }; a city count may also include non-citable locationResolution metadata with a server-derived fallbackState. State samples include matchedSites and device-family samples include bounded eligibilityEvidence. Eligibility criteria do not establish direct medical safety. Use for 'how many Phase X trials of compound Y?' / 'how many trials in country Z?' / single-bucket aggregate questions. State and device-family filters are intentionally unavailable in aggregate_trials.

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

Input Schema

Name	Required	Description
`limit`	No
`phase`	No	Trial phase as Roman numerals: "I", "II", "III", "IV", or "NA". Also accepts "Phase 1"/"Phase 2"/etc. and "1"/"2"/"3"/"4" — they are normalized internally.
`query`	No
`status`	No	Trial status. Accepts schema strings ("Recruiting", "Completed", "Active not recruiting", etc.) AND common shortcuts like "active", "recruiting", "completed".
`topics`	No	Topic slugs (e.g. "depressive-disorders", "post-traumatic-stress-disorder"). Common abbreviations like "PTSD", "TRD", "OCD" and short names like "depression", "anxiety" are auto-mapped.
`compounds`	No	Compound slugs (e.g. "psilocybin", "mdma"). Street names ("shrooms", "ecstasy") and brand/program names ("COMP360", "MM-120") are auto-mapped.
`trialCity`	No	City name (e.g. "Berlin", "London", "Boston"). Filter scans only trialSites within the matched country, so you must ALSO set trialCountry (or pass a city in the auto-pair list — Berlin→Germany, London→United Kingdom, etc.). Forgiving prefix match.
`designType`	No	Trial design type. Use ["crossover"] for "crossover trials"; ["single-arm"] for uncontrolled trials.
`enrollsAge`	No	Age in years that the trial would enroll (matches ageMinYears <= X AND (ageMaxYears IS UNDEFINED OR ageMaxYears >= X)). Use 16 for "trials enrolling adolescents", 70 for "trials enrolling elderly".
`generation`	No
`trialState`	No	Single supported country-qualified state. "Colorado" and "CO" normalize to "us-co" and pin the search to United States trial sites.
`trialCities`	No	Multiple city names or supported local regions. "Orange County" expands to Orange, Santa Ana, San Juan Capistrano, and Garden Grove. Country scope is inferred only when every entry maps to the same country; otherwise also pass trialCountry.
`trialStates`	No	Multiple supported country-qualified states. State aliases are normalized and deduplicated. Do not combine with trialCity or trialCities.
`deviceFamily`	No	Recorded trial eligibility mentions for the pacemaker/implantable-cardioverter-defibrillator family. This retrieves protocol criteria, not a medical-safety conclusion.
`isRandomized`	No
`maskingLevel`	No	Blinding level. "none" = open-label, "double" = double-blind, etc.
`studyStartTo`	No	Inclusive upper bound for studyStartDate (YYYY-MM-DD).
`trialCountry`	No	Single country slug (e.g. "united-states", "germany"). ISO codes ("US", "UK", "DE") and common names ("USA", "Britain") are auto-mapped. For multi-country / regional questions use trialCountries instead.
`sexesEligible`	No	Sexes eligible for study. "all" matches trials with no sex restriction.
`studyStartFrom`	No	Inclusive lower bound for studyStartDate (YYYY-MM-DD).
`trialCountries`	No	Multiple country slugs OR region names. Regions ("Scandinavia", "Nordics", "EU", "Europe", "North America", "Latin America", "Oceania", "Asia-Pacific") expand to their constituent countries automatically. Use this for "trials in Scandinavia", "European psilocybin trials", etc.
`controlStrategy`	No	Control / comparator strategy. ["placebo"] for placebo-controlled, ["comparator"] for active-comparator, ["waitlist"] for waitlist control.
`researcherSlugs`	No	Slugs of investigators / researchers attached to the trial (Person docs).
`resultsPublished`	No
`primarySponsorSlug`	No	Stakeholder slug of the primary sponsor (e.g. compass-pathways, maps).
`registrationNumbers`	No	Exact ClinicalTrials.gov IDs (for example NCT03537014). Case and whitespace after NCT are normalized.
`psychotherapyProvided`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered and the description's remaining job is return-shape context. It does add value with non-citable locationResolution metadata, the server-derived fallbackState, matchedSites/eligibilityEvidence on samples, and the "eligibility criteria do not establish direct medical safety" caveat. However the return contract is largely duplicated from the output schema, so the increment over structured data is moderate rather than rich.

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 purpose, then return shape, then usage examples and the sibling exclusion — a sensible ordering with little filler. It is dense and packs multiple clauses per sentence (the locationResolution/fallbackState sentence in particular), but nearly every clause carries actionable information.

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?

Rich structured coverage (output schema, four annotations, 27 documented params) lowers the burden, and the description still supplies the count semantics, sample composition, and the safety caveat an agent needs before citing results. Missing pieces are minor: how limit affects the returned sample, and what happens with zero matches.

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 78% (baseline 3), and the description adds genuine meaning on specific parameters: which values registrationNumbers accepts, the trialState/trialStates supported-value constraint, and that deviceFamily retrieves recorded protocol-eligibility mentions rather than a safety conclusion. With 27 parameters there are still gaps (limit/pagination behavior, how query interacts with typed filters), but the added semantics on the exotic enums is meaningful.

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?

Opens with a specific verb+resource ("Count clinical trials matching filters") and immediately scopes what can be counted, including named fields like registrationNumbers, trialState/trialStates and deviceFamily. It explicitly names the sibling it differs from ("intentionally unavailable in aggregate_trials"), so an agent can route between count_trials, aggregate_trials and search_trials without opening schemas.

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?

Gives concrete trigger questions ("how many Phase X trials of compound Y?", "how many trials in country Z?") and characterizes the right shape of question as "single-bucket aggregate". It also states a negative condition via the aggregate_trials exclusion, but never mentions search_trials as the alternative for retrieving individual trial records rather than a count.

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

All Blossom Research 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?