Skip to main content
Glama
Sign In
data-aggregator-mcp

data-aggregator-mcp

by musharna
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_sources

Read-only

Lists wired data sources with capabilities—layer, kinds, filters, auth, rate limits, and status—and can optionally probe selected sources for health.

Instructions

List wired data sources and their capabilities (layer, kinds, supported filters, auth requirement, rate limit, status). Tool names in this text are this server's own; your client may list them with a prefix (in Claude Code, mcp__data-aggregator__resolve): call the name it lists. filters_supported names the search parameters a source applies itself: cursor = it pages past page 1; published_after/published_before/kind = filtered upstream, so its total is filtered (any other source is filtered after fetch); organism/disease/tissue/chemical/assay = the synonym expansion reaches its query.

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

Input Schema

NameRequiredDescriptionDefault
check_healthNoWhen true, probe 5 sources (zenodo, datacite, omics, literature, huggingface) and attach a 'health' field ({status: up|down, latency_ms, detail}) to those entries; every other source gets health: null. Default false: returns the static catalog with no network.

Output Schema

NameRequiredDescriptionDefault
sourcesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.54.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv0.42.0
    • changedInput schema / properties / check_health / description
      Previous value: -"When true, probe 5 sources (zenodo, datacite, omics, literature, huggingface) and attach a 'health' field ({status: up|down, latency_ms, detail}) to those entries; the remaining 7 sources get health: null. Default false: returns the static catalog with no network."New value: +"When true, probe 5 sources (zenodo, datacite, omics, literature, huggingface) and attach a 'health' field ({status: up|down, latency_ms, detail}) to those entries; every other source gets health: null. Default false: returns the static catalog with no network."
  3. Changed1 schema field changedv0.40.0
    • changedInput schema / properties / check_health / description
      Previous value: -"When true, probe each source's base endpoint and attach a 'health' field ({status: up|down, latency_ms, detail}) to each source. Default false: returns the static catalog with no network."New value: +"When true, probe 5 sources (zenodo, datacite, omics, literature, huggingface) and attach a 'health' field ({status: up|down, latency_ms, detail}) to those entries; the remaining 7 sources get health: null. Default false: returns the static catalog with no network."
  4. Changed1 schema field changedv0.16.0
    • addedInput schema / properties / check_health
      Added value: +{
+  "default": false,
+  "description": "When true, probe each source's base endpoint and attach a 'health' field ({status: up|down, latency_ms, detail}) to each source. Default false: returns the static catalog with no network.",
+  "type": "boolean"
+}
  5. First observedv0.11.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations cover the read-only profile, and the description adds real context beyond them: it warns that tool names appearing in the text may be prefixed by the client (with a concrete Claude Code example), which prevents a common invocation mistake. It does not restate the no-network default, but that behavior is fully disclosed in the check_health schema description.

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?

Purpose is front-loaded in one sentence, then the dense second paragraph covers naming and filters_supported semantics, which are genuinely needed to interpret the output. Slightly wordy but no sentence is filler.

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?

An output schema exists, so return values need not be explained, and the description still goes further by decoding the most ambiguous returned field (filters_supported) and its per-value meaning. Nothing an agent needs to call or interpret this tool correctly is missing.

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?

With a single parameter and 100% schema description coverage, the schema already explains check_health's probing behavior, latency fields, and default. The description adds nothing about the parameter, so the baseline 3 applies.

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?

States a specific verb and resource ('List wired data sources and their capabilities') and enumerates exactly what a capability record contains (layer, kinds, filters, auth, rate limit, status). This is clearly distinct from the generic verb siblings (search, resolve, fetch), though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit 'use this before searching' or 'use X instead when…' statement; usage is only implied by the field inventory. The note that filters_supported reveals which search parameters a source applies upstream implicitly tells the agent to consult this before calling search, but the inference is left to the reader.

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

Deploy Server

Other Tools