Blossom Research

Summarize the trial catalogue

aggregate_trials

Read-onlyIdempotent

Group-by count of trials across one or two axes. Single axis: set groupByPrimary to 'compound' | 'topic' | 'country' | 'phase' | 'status' | 'year' | 'sponsor' | 'researcher'. Two axes: also set groupBySecondary (e.g. groupByPrimary='compound', groupBySecondary='topic') for a 2D matrix — perfect for 'what conditions is each psychedelic studied for'. Returns ranked buckets with sample citations. 1D buckets: {key, label, count, sample}. 2D buckets: {rowKey, rowLabel, colKey, colLabel, count, sample}. Same filter shape as search_trials; filters are optional.

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": {
      "filters": "<filters>",
      "groupByPrimary": "<groupByPrimary>"
    },
    "name": "aggregate_trials"
  }
}

Input Schema

Name	Required	Description
`filters`	Yes	Same supported filter shape as search_trials, except registrationNumbers, trialState/trialStates, and deviceFamily. Filters are OPTIONAL for aggregates — pass `{}` to group across all trials. `limit` is ignored.
`groupByPrimary`	Yes	Primary axis to group by ("compound" \| "topic" \| "country" \| "phase" \| "status" \| "year" \| "sponsor" \| "researcher"). Required.
`groupBySecondary`	No	Optional second axis for a 2D matrix. Set this for "compounds × topics" or "phase × country"-style breakdowns. Result has rowKey/colKey/count cells. 2D output caps at 50 buckets after sort.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.4/5.0

Behavior4/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. The description adds genuinely new behavior: ranked output ordering, sample citations per bucket, the 2D 50-bucket cap, and that filters are optional while `limit` is ignored. It omits any cap or ordering rule for 1D results.

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?

Front-loads the operation, then mode selection, then output shape, in a tight sequence with no filler. The inline bucket shapes partially duplicate the output schema but are short enough to serve as a quick scan.

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?

Covers the essentials for a 3-parameter aggregation tool: optional filters, both grouping axes, and the 2D bucket cap. The only gap is that 1D result limits and cross-axis constraints (e.g. repeated axes) go unmentioned.

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% and the schema description already carries the heavy filter documentation, so the baseline would be 3. The description earns above baseline by pairing axes into a concrete example (groupByPrimary='compound', groupBySecondary='topic') and by stating the '{}' pass-through for aggregating across all trials.

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 ('Group-by count of trials') and immediately bounds scope to 'one or two axes', then enumerates the exact axis values. An agent can distinguish this from count_trials (single total) and search_trials (record list) without opening any schema.

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 explicit selection logic between 1D and 2D modes and anchors it with a concrete question ('what conditions is each psychedelic studied for'). It does not explicitly say when to prefer count_trials or search_trials instead, so the routing against siblings is implied rather than stated.

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?