Dapper

Get Country Health

get_country_health

Read-onlyIdempotent

Freshness status (ok / warning / stale / no_data / not_covered) for every data domain in ONE country — the same computation as get_health, scoped down. Check it before a bulk pull, or when a query comes back thinner than expected: a stale domain means the ingestion pipeline is behind, not that you queried wrong, and it is the difference between reporting 'nothing was filed' and 'Dapper has not ingested anything recent here'. No API key required.

Domains not listed here are withheld, not empty: votes, interventions have data but too little of it for a freshness claim to mean anything, so they are omitted until their ingestion improves. Query their endpoints directly.

not_covered means Dapper has no source for that domain in that country (for example consultations in PE, AR, VE, GT and DO): say the domain is not covered there, not that ingestion is behind. Each status is measured against that country's own publishing rhythm, so a congress that publishes weekly is not stale mid-week.

feeds (bills and schedules only) lists the sources behind a pair -- each chamber or congress -- newest first. A pair is stale when any counted source is stale even if another is current, so read feeds before saying a country's bills are up to date. counted: false sources (seasonal, retired, sporadic) are shown with a note and do not move the pair.

search_corpus is separate from freshness: it says how much of each domain is in the SEMANTIC index for that country. A domain absent from it has zero indexed documents, so q there is a plain title match — use the record listings (date, entity, code filters) instead of concluding a topic is absent. A null search_corpus means the summary was unavailable, not that coverage is zero.

Input Schema

Name	Required	Description	Default
`country_code`	Yes	ISO 3166-1 alpha-2 country code (e.g. BR, CO, MX). The legacy numeric id (e.g. 8) is also accepted. See GET /v1/countries for the full list.

Output Schema

Name	Required	Description	Default
`countries`	Yes
`generated_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedOutput schema / properties / countries / items / properties / domains / additionalProperties / properties / feeds

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "description": "One source (a chamber, a state congress) inside a country x domain pair.\n\nOnly bills and schedules are split (app/db/health.py FEED_DOMAINS). A\nsource with `counted: false` is shown but does not move the pair; `note`\nsays why (seasonal, retired, sporadic, misattributed).",
+        "properties": {
+          "age_hours": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "title": "Age Hours"
+          },
+          "counted": {
+            "default": true,
+            "title": "Counted",
+            "type": "boolean"
+          },
+          "last_updated": {
+            "anyOf": [
+              {
+                "format": "date-time",
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "title": "Last Updated"
+          },
+          "name": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "title": "Name"
+          },
+          "note": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "title": "Note"
+          },
+          "source_id": {
+            "anyOf": [
+              {
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "title": "Source Id"
+          },
+          "status": {
+            "title": "Status",
+            "type": "string"
+          }
+        },
+        "required": [
+          "status"
+        ],
+        "title": "FeedFreshness",
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Feeds"
+}

Changed1 schema field changedOct 26, 2026
- addedOutput schema / properties / countries / items / properties / domains / additionalProperties / properties / sla_hours
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Sla Hours"
+}
```
First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantial non-derivable behavior: no API key required, domains silently withheld (votes, interventions) rather than empty, `not_covered` vs `stale` distinction, per-country publishing-rhythm baselining, and the rule that `feeds` can make a pair stale via any single counted source. These are exactly the traps that would cause a wrong report.

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?

The core purpose and status set are front-loaded in the first sentence, and each subsequent paragraph covers a distinct semantic trap rather than restating. It is long, and some output-interpretation detail could sit in the output schema, but nearly 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?

For a single-param read tool with an output schema, the definition covers what the schema cannot: meaning of each status, null vs zero for `search_corpus`, why domains are omitted, and how `counted: false` feeds behave. An agent has everything needed to call it and interpret the result correctly.

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% and the single `country_code` param is fully documented in the schema, including ISO alpha-2 and legacy numeric acceptance. The description adds only the scoping emphasis ('ONE country') and incidental country mentions (PE, AR, VE, GT, DO), which are illustrative rather than parameter guidance; baseline 3 applies.

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?

States a specific verb and resource ('freshness status ... for every data domain in ONE country') and enumerates the exact status values returned. It also explicitly disambiguates from the sibling: 'the same computation as get_health, scoped down,' so an agent can choose between them without opening a schema.

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

Usage Guidelines5/5

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

Gives concrete when-to-use triggers ('before a bulk pull', 'when a query comes back thinner than expected') plus when-not reasoning ('a stale domain means the ingestion pipeline is behind, not that you queried wrong'). It also routes the agent elsewhere for withheld domains ('query their endpoints directly') and distinguishes `search_corpus` from freshness, telling the agent to use record listings instead of concluding a topic is absent.

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

All Dapper 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?