Skip to main content
Glama

xpay Academic Research Collection

get_trial_details_batched

Retrieve detailed clinical trial records in batches to reduce payload during discovery.

Accepts a list of NCT IDs and fetches details in batches (default 10). Preserves the order of input NCT IDs in the returned list. Use this after search tools which return a minimal field set.

Input:

  • nct_ids: List of NCT IDs to retrieve in batches.

  • fields: Specific fields to return. If not provided, returns DETAIL_TOOL_DEFAULTS (25 comprehensive fields covering: NCTId, BriefTitle, OfficialTitle, Acronym, Condition, Keyword, Phase, OverallStatus, InterventionType, InterventionName, InterventionDescription, ArmGroupLabel, ArmGroupType, ArmGroupDescription, EligibilityCriteria, MinimumAge, MaximumAge, Sex, PrimaryOutcomeMeasure, SecondaryOutcomeMeasure, BriefSummary, LocationFacility, LocationCountry, LeadSponsorName, CollaboratorName, HasResults).

  • batch_size: Number of trials to fetch per API call (default 10).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoSpecific fields to return for detailed view
nct_idsYesNCT IDs to retrieve in batches of 10
batch_sizeNoBatch size for each API call

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it discloses key behaviors: batching with a default size, preservation of input order, and the exact default field set. It also clarifies what happens when `fields` is not provided. It doesn't discuss errors or response envelope, but for a read-style batched lookup it is adequately transparent.

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?

The description is well-organized and front-loaded with the core purpose, then provides batching semantics, usage, and input details. The field list adds length but is valuable and directly relevant. There is slight redundancy between the intro and the input section, but 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?

Given the moderate complexity and absence of an output schema, the description covers batching behavior, ordering, default field set, and usage timing relative to search tools. It does not specify error handling or exact response structure, but the tool is simple enough that this is acceptable.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial value by enumerating the 25 default fields and clarifying the default batch_size and behavior. It explains that `fields` defaults to a specific list, which the schema only shows as null. This goes beyond the schema descriptions.

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 opens with a specific verb ('Retrieve'), names the resource ('detailed clinical trial records'), and highlights batching, which distinguishes it from the singular get_trial_details sibling. It also explains why batching is used ('to reduce payload during discovery').

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?

The description explicitly states when to use the tool: 'Use this after search tools which return a minimal field set.' This provides clear usage context as a follow-up enrichment step. It does not name alternatives or exclusions, but the context is sufficient.

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.

TDQS

C2.6/5.0
Disambiguation1/5

Multiple tools appear to serve the same purpose, such as search_arxiv and search-arxiv, or papers-search-basic, paper-search-advanced, search_papers, and search. The download/read tools for different sources follow similar patterns, but some return 'not supported' messages, making it unclear which tools are actually functional.

Naming Consistency1/5

Tool names mix snake_case, kebab-case, and bare verbs without a consistent pattern. For example, about_nanci, analysis-citation-network, download-full-paper-arxiv, fetch, and search_arxiv all coexist, and the same action for different sources alternates conventions (search-arxiv vs search_arxiv).

Tool Count1/5

With 53 tools, the server is heavily over-scoped. Many tools are redundant or near-duplicates, such as six source-specific search tools plus an aggregate search, and the inclusion of both paper and clinical trial tools in one server creates unnecessary bloat.

Completeness3/5

The server covers a wide range of research workflows, including search, download, read, citations, authors, and clinical trials. However, several tools (crossref/pubmed download/read) are non-functional dead ends, and the redundancy makes it harder to navigate the surface.

Resources