sitecite

Find trial sites with comparable completed trials

find_trial_sites

Read-onlyIdempotent

Find clinical trial sites for a condition and phase from ClinicalTrials.gov, ranked by completed comparable trials, every site with NCT links. Counts are trials that list the site, not patients enrolled. Returns sites in ClinicalTrials.gov trial-count order, each with the NCT numbers of the comparable trials listed there, completion and termination counts, how many competing trials are recruiting there now, and a second-column evidence score. Read-only, registry data only, every line cited. Use when someone asks where a Phase 1-3 trial in a condition has been run before. The result has a link to save and re-run this comparison for a programme.

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": {
      "conditions": "<conditions>",
      "phases": "<phases>"
    },
    "name": "find_trial_sites"
  }
}

Input Schema

Name	Required	Description	Default
`sort`	No	trial_count is the registry's own count of comparable trials per site (default). score orders by the evidence score instead; both columns are always returned.	trial_count
`detail`	No	summary (default) returns the 3 most recent trials per site as NCT id, status, completion date and whole-trial enrollment (open any at trial_url_template), with trials_total for the rest, so the result stays small enough for a chat context. full adds up to 10 trials per site with title and link, up to 5 competing trials per site, and more merged spellings.	summary
`phases`	Yes	Trial phases to compare against, for example ["2", "2/3"].
`country`	No	Optional. Only sites in this country, named as the registry spells it ("Germany", "United States").
`max_sites`	No	How many sites to return, 1 to 25.
`conditions`	Yes	Registry condition terms as ClinicalTrials.gov spells them, for example ["psoriasis", "plaque psoriasis"]. Synonyms are OR-ed.

Output Schema

Name	Required	Description
`as_of`	Yes	Date the registry was read.
`query`	Yes	The normalised input that was run.
`sites`	Yes
`notice`	Yes	Standing note: a cited data summary of public registry records, not a site recommendation.
`totals`	Yes
`method_url`	Yes
`normalised_to`	No	Present only when the call was written with other spellings (condition, phase, a single string, PHASE2): the conditions and phases that actually ran.
`reading_guide`	Yes	What each count means. Read before quoting a number: trials_listed counts trials that list the site, not patients the site enrolled.
`open_in_app_url`	Yes	Opens the same indication and phases pre-filled in the Sitecite app, to save and re-run the comparison for a programme.
`trial_url_template`	No	Replace {nct_id} to open a trial on ClinicalTrials.gov.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

addedOutput schema / properties / normalised_to

Added value: +{
+  "description": "Present only when the call was written with other spellings (condition, phase, a single string, PHASE2): the conditions and phases that actually ran.",
+  "type": "object"
+}

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that counts are trials listing the site rather than patients enrolled, that results come in ClinicalTrials.gov trial-count order, what each row contains, and that a link is returned to save and re-run the comparison. It also states the data provenance ('registry data only, every line cited'), which is real behavioral context the annotations cannot convey.

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?

Purpose, ranking basis, and caveat about counts land in the first two sentences, and the use case is placed last where it belongs. Every clause carries information; the mild overlap between 'Read-only, registry data only, every line cited' and the readOnly annotation is the only redundancy.

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 six-parameter, enum-heavy tool with a full output schema, the description covers what is returned, how it is ordered, and the caveat that counts are trials not patients. Return-value detail is appropriately delegated to the output schema rather than padded into the prose.

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 the baseline is 3; the description adds meaning on top by clarifying that the two sort columns are always returned, that trial counts are registry counts of comparable trials rather than enrollments, and by pointing at trial_url_template for opening trials. It does not restate the conditions/phases/country semantics, but the schema already handles those thoroughly.

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 ('Find clinical trial sites for a condition and phase from ClinicalTrials.gov, ranked by completed comparable trials') plus the ranking basis, so the tool is unambiguous. It does not name or contrast with the sibling crosscheck_site_list, so an agent must infer which tool wins when both could apply.

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 someone asks where a Phase 1-3 trial in a condition has been run before' gives a clear triggering context. There is no when-not guidance and no explicit routing to the sibling crosscheck_site_list for the case where the caller already has a site list to verify.

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

All sitecite 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?