Govparse Government Data Gateway

cms_timely_care_delta

Which hospitals' emergency-department throughput is degrading period-over-period? Windows the CMS Timely & Effective Care snapshots to compute each hospital's latest-vs-prior change on a measure (default OP_18b median ED time; higher = worse). Filter by measure, state, facility_id, direction (worse | better | any), min_pct_change, min_delta, and min_sample. Returns latest_score, prior_score, delta, and pct_change — the founder's ED-staffing-pressure tell. CMS Care Compare public-domain records. [price: $0.05/row]

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max rows (default 25, cap 100).
`state`	No	Hospital state code(s), CSV.
`offset`	No	Rows to skip.
`measure`	No	Measure id to compare across periods (default OP_18b).
`direction`	No	worse (default) \| better \| any.
`min_delta`	No	Minimum absolute change in the chosen direction.
`min_sample`	No	Minimum latest-period sample size.
`facility_id`	No	CMS CCN(s), CSV.
`min_pct_change`	No	Minimum period-over-period % change in the chosen direction.

Schema Changelog

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

AddedJul 27, 2026

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It explains the tool computes latest-vs-prior change and notes data is public-domain. It mentions pricing but does not disclose rate limits, error handling, or how periods are determined. It does not contradict any annotations.

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?

The description is three sentences, front-loads the purpose, and each sentence adds value: problem statement, computation explanation, filter/return summary including pricing. No redundant information.

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 9 parameters and no output schema, the description covers the main computation, defaults, and return columns. It lacks edge-case explanations (e.g., missing prior periods) but is fairly complete for its complexity.

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% with minimal descriptions. The description adds meaning by specifying default measure (OP_18b), default direction (worse), and the returned fields (latest_score, prior_score, delta, pct_change). This enhances understanding beyond the schema alone.

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 starts with a clear question 'Which hospitals' emergency-department throughput is degrading period-over-period?' and then explains the tool computes changes between periods. It distinguishes from sibling cms_timely_care_search by focusing on period-over-period delta rather than raw snapshots.

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?

The description mentions 'the founder's ED-staffing-pressure tell' implying a use case but does not explicitly state when to use this tool versus alternatives like cms_timely_care_search. No when-not or exclusions are provided.

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

All Govparse Government Data Gateway tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct domain and specific action (e.g., FDA approvals vs clearances vs recalls; firmstanding business360 dossier vs search vs screen). Even overlapping concepts like 'business360' vs 'business360_lookup' are distinguished by input (UUID vs name+state). No two tools appear to do the same thing.

Naming Consistency5/5

All tools use a consistent lowercase snake_case pattern with domain prefix (e.g., fda_*, firmstanding_*, fmcsa_*, govcon_*). Action words (search, lookup, screen, feed, stats) follow predictable usage. The naming is uniform and easy to parse.

Tool Count4/5

38 tools is on the higher end but appropriate for a comprehensive government data gateway spanning multiple agencies and datasets. Each domain has a reasonable number of tools (e.g., FMCSA: 7, OFLC: 6). Could potentially be trimmed slightly, but overall well-scoped for the stated purpose.

Completeness5/5

The tool surface covers the major government data sources comprehensively: FDA (approvals, clearances, recalls), FMCSA (carrier census, safety, insurance, etc.), FSIS, DOJ/OFLC, OSHA/EPA/DOL enforcement, SEC insider filings, clinical trials, VA facilities/opportunities/vendors, and federal contracting. No obvious gaps for the stated gateway purpose.

Resources

Need Help?