Skip to main content
Glama

Veridion Disclosures

get_status

Read-onlyIdempotent

Source freshness and bulk-snapshot health. This endpoint downgrades itself when its own arithmetic says stale — it never guesses green. When state is 'degraded', degraded_reasons names each cause with its measurement; sources[].index_reconciliation says whether the government's own index lists filings not yet served; bulk_export.merkle_root is the day's commitment over every row's content_hash. Check it before trusting a large pull.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cacheYesAlways no-store with zero max-age at every layer: a status page that could be served stale would defeat itself. age_header is null because no cache is permitted to add one.
stateYesready when no check below is failing. degraded when any source is stale or unavailable, the export is stale, unavailable or missing its merkle_root, coverage recovery is stale or unavailable, the Congress summary is stale, unavailable or unattested, a temporal-conformance contract fails, the temporal window is unreadable, the House index lists unaccounted filings, or a pipeline job is not delivering. unavailable when the status itself could not be measured. The endpoint never reports a state more optimistic than its own arithmetic: a stored 'ready' older than its threshold is reported stale.
detailNoPresent only on the unavailable body, naming what could not be read.
noticeNoStanding guidance on reading this block: what no_data means, what degraded does and does not imply, and how to verify a download.
sourcesYesFreshness of every source Veridion polls, measured from the same table the serving views read. One entry per source system, including the ones that publish nothing.
versionYesThe contract version this response was produced under; the same value as X-API-Version.
pipelineNoAttendance of the jobs that produce this API's data, from the cron attendance store. Absent only on the fail-closed 503 body. A missed, died or never-run job, a failed export run, or an unreadable store degrades the endpoint by name.
universeNoHow fresh the scored universe is. A buyer's first question about a score is how old it is, and the answer is a distribution: newest, median, oldest, and the share scored inside a day. Measured on a cron and read as one stored row; the block reports the age of its own measurement so a stale measurement cannot masquerade as a current one. Absent only on the unavailable body, where no read was attempted at all: this endpoint does not publish a block it did not measure.
bulk_exportNoThe daily bulk snapshot: its day, generation, size, file hash and Merkle commitment. Absent only on the unavailable body.
billing_gateYesA completed UTC day qualifies only when all 24 distinct hourly observations are present and operational. Operational means the public status evaluator returned ready with no degraded reasons. Missing hours break the streak; today's incomplete hour is not missing until it ends. A recorded non-operational sample today resets the streak immediately. No history is backfilled. Hourly samples do not establish continuous availability or a service-level guarantee.
generated_atYesWhen this response was computed. Every age_seconds below is measured from this instant, so the block is internally consistent even when read from a cache.
track_recordNoWhen the published track record was last successfully computed, and whether the latest run succeeded. The figures a buyer reads on /track-record are dated by published_at; this block lets a pipeline learn that date, and learn that a later run failed, without scraping the page. Read live from two indexed single-row lookups, so unlike universe it carries no measurement age of its own. Absent only on the unavailable body, where no read was attempted.
temporal_windowYesHow far back as_of reads can go. The floor is the activation instant of retained payload history; depth is the time since. Neither says anything about filing completeness before the floor, which is what /v1/coverage measures.
degraded_reasonsYesWhich checks pulled state down, and their measurements. Empty when ready. An unavailable response carries any observed read failures, including named timed_out deadlines; missing configuration has no measured read outcomes.
coverage_recoveryNoWhere House Clerk document recovery stands: how many documents are parsed, queued, failing, terminally failed, or withheld by the lossless-reparse check. Absent only on the unavailable body.
observation_delayNoHours from a filing's filed_date to Veridion's first observation, per source. Published only over rows with verified continuity; withheld with the reason otherwise. Absent only on the unavailable body.
temporal_conformanceNoThe four temporal contracts, verified against the pinned bulk snapshot. A failing contract degrades the endpoint by name. Absent only on the unavailable body.
institutional_deliveryYesA declared boundary, stated rather than discovered.
congress_public_summaryNoThe Congress public summary that /api/congress/summary serves, its age, and whether the newest owner outcome attests to it. Absent only on the unavailable body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses that the endpoint self-downgrades when its own arithmetic detects staleness and "never guesses green," and it explains what degraded_reasons, sources[].index_reconciliation and bulk_export.merkle_root actually mean. That is exactly the kind of trust/verification context an agent cannot get from the annotations.

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?

Front-loaded with the one-line purpose, then detail in descending priority, ending on the actionable precondition. It is dense with domain jargon (merkle_root, index_reconciliation) but every sentence carries information; it is not padded.

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 the description is not obliged to enumerate return fields, yet it still explains the semantics of the most consequential ones (degraded states and their causes, index reconciliation, the daily commitment). Combined with full annotation coverage and no parameters, nothing an agent needs in order to call this correctly is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter-level guidance is needed here.

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?

The opening line names a specific resource and scope — source freshness plus bulk-snapshot health — so an agent knows this is a health/status read rather than a data-retrieval call. It does not explicitly distinguish itself from the sibling get_coverage, which is the one tool an agent might plausibly confuse it with, so it stops short of a 5.

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?

"Check it before trusting a large pull" gives a concrete precondition for calling the tool, which is real usage guidance. There is no explicit when-not or named alternative (e.g. get_coverage), so it is clear context without full routing.

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.

Resources