Skip to main content
Glama

Cross-check a proposed site list against the registry

crosscheck_site_list
Read-onlyIdempotent

Check a CRO's proposed site list against ClinicalTrials.gov, every matched site with its comparable trials and NCT links. Counts are trials that list the site, not patients enrolled. For each pasted site name, returns the matching registry site with confidence, its comparable trials with NCT links and its competing load, plus strong registry sites in the same countries that the list does not include. Read-only, no data stored. Use when you hold a CRO or sponsor site list and want it verified. 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": {
      "sites": "<sites>",
      "conditions": "<conditions>",
      "phases": "<phases>"
    },
    "name": "crosscheck_site_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
sitesYesOne proposed site per entry, "Name, City, Country" or the name alone.
detailNosummary (default) returns the 3 most recent trials per matched site, the 3 closest suggestions without trials and 5 missing strong sites with 3 trials each, so the result stays small enough for a chat context. full adds up to 10 trials per site with title and link, trials for suggestions, and up to 15 missing strong sites.summary
phasesYesTrial phases to compare against.
conditionsYesRegistry condition terms for the indication, as in find_trial_sites.

Output Schema

NameRequiredDescriptionDefault
rowsYes
statsYes
noticeYes
method_urlYes
reading_guideYesWhat each count means. Read before quoting a number: trials_listed counts trials that list the site, not patients the site enrolled.
open_in_app_urlYesOpens the same indication and phases pre-filled in the Sitecite app, to save and re-run the comparison for a programme.
trial_url_templateNoReplace {nct_id} to open a trial on ClinicalTrials.gov.
missing_strong_sitesYesRegistry sites with many comparable trials, in the list's countries, that the list omits: 5 with detail summary (3 trials each), up to 15 with full (10 trials each).
missing_strong_sites_totalNoHow many such sites exist; missing_strong_sites holds the top of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds useful context beyond them: counts represent trials listing the site rather than patients enrolled, and the result contains a link to save and re-run the comparison for a programme.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence and the "For each pasted site name..." sentence restate the same matched-site/trials/NCT-links content twice, and the fragment "Check a CRO's proposed site list... every matched site with..." is grammatically loose. Front-loading is fine, but the repetition costs it.

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?

Since an output schema exists, the description need not enumerate return values, and it covers the main behaviors an agent needs: verification framing, what counts mean, read-only persistence, and the re-runnable link. Slightly fuller guidance on choosing summary vs full would complete it.

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 100%, including a detailed detail-enum description, so the baseline is 3. The description only echoes that sites are "pasted" names and that counts are trial counts; it adds no format or semantic detail beyond the schema.

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?

The description states a specific verb and resource (check a proposed CRO/sponsor site list against ClinicalTrials.gov) and the scope of the result (matched sites, comparable trials with NCT links, competing load, plus strong sites missing from the list). It is clearly distinct from find_trial_sites, which it references only for condition-term conventions.

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 you hold a CRO or sponsor site list and want it verified" gives a clear triggering situation. It does not state exclusions or explicitly contrast with find_trial_sites for the case where the agent has no existing list, so it stops short of full when/when-not guidance.

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.

Resources