Skip to main content
Glama
Sign In

Healthdata

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Search Datasets

search_datasets
Read-onlyIdempotent

Search HealthData.gov for public-health datasets by keyword (e.g. "COVID hospitalizations", "Medicare spending", "opioid prescriptions"). Returns each dataset's Socrata id (a 4x4 like "g62h-syeh"), title, description, owning agency, tags, when the data was last updated, and its page-view count. Pass the id to get_dataset for full metadata or to get_rows to read the actual rows.

Input Schema

NameRequiredDescriptionDefault
limitNoMax results, 1-50 (default 10).
queryYesSearch query, e.g. "vaccination rates", "hospital readmissions".
offsetNoSkip this many results, for paging (default 0).

Output Schema

NameRequiredDescriptionDefault
totalYesTotal number of datasets matching the search query
resultsYesArray of matching datasets

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Max results to return (1-50, default 10)"New value: +"Max results, 1-50 (default 10)."
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Skip this many results, for paging (default 0).",
+  "type": "number"
+}
    • changedInput schema / properties / query / description
      Previous value: -"Search query (e.g., \"vaccination rates\", \"hospital readmissions\", \"air quality health\")"New value: +"Search query, e.g. \"vaccination rates\", \"hospital readmissions\"."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, openWorld and non-destructive, so the safety profile is handled. The description adds real context beyond them: the concrete shape of returned records, the Socrata 4x4 id format, and the routing contract to sibling tools.

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?

Three tight sentences with zero filler, front-loaded with the action and corpus, then return shape, then next-step routing. Every sentence earns its place.

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 agent knows what it will get back, what the id looks like, and which sibling tools consume it. With an output schema present, the return-field listing is a bonus rather than a necessity, and the search-to-retrieve workflow is fully closed.

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%, so limit and offset are already fully documented in the schema, and the query examples in the description largely duplicate the schema's own examples. Baseline 3 is appropriate; the description adds little parameter-level meaning beyond what is structured.

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?

Specific verb (Search) + resource (datasets) + named corpus (HealthData.gov) + domain scope (public-health). Concrete query examples make the intended input unambiguous, and the mention of get_dataset/get_rows makes it distinguishable from sibling retrieval tools.

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?

Explicitly routes the follow-up step: use the returned id with get_dataset for full metadata or get_rows to read rows. That is clear downstream guidance. It stops short of stating when NOT to use this tool (e.g. versus search_within for searching inside a dataset's rows).

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

All Healthdata toolsInspect
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