Datos de Georgia, para tu código

https://georgiacivicdata.org/api/v1

• Pública y de solo lectura. Cada endpoint es un GET, excepto la consulta de zonas escolares, que también acepta un POST para que una dirección quede fuera de la URL. No hay nada que autenticar.
• Basada en contratos. Cada conjunto de datos se genera a partir de un contrato ODCS versionado, así que sus columnas, unidades, rangos y valores permitidos son estables y están documentados.
• Los mismos datos en todas partes. El Data Explorer y el servidor MCP leen esta misma API.

Los datos de hechos están en /api/v1/{main_topic}/{topic}. Pide los puntajes ACT compuestos de 2024 a nivel de distrito:

curl "https://georgiacivicdata.org/api/v1/education/act_scores?year=2024&test_component=composite&detail=districts"

Las respuestas JSON son un sobre: un arreglo data de filas más un bloque pagination. Las etiquetas de dimensión (nombres de distrito y escuela) se incluyen por ti.

{
  "data": [
    {
      "year": 2024,
      "district_code": "601",
      "district_name": "Appling County",
      "test_component": "composite",
      "num_tested": 234,
      "avg_score": 18.7
    }
  ],
  "pagination": { "limit": 1000, "offset": 0, "total": 181, "returned": 181 }
}

Agrega ?format= para elegir cómo se devuelven las filas:

• json (predeterminado). Sobre paginado con data + pagination.
• csv. Bytes CSV con un encabezado X-Total-Count.
• parquet. Bytes Parquet — ideal para análisis en polars/DuckDB.

• Año. year=2024 (exacto) o year_min / year_max (rango inclusivo). Usa uno u otro, no ambos.
• Nivel de detalle. detail=states, districts o schools — el que publique el conjunto de datos. Un conjunto documenta todos sus niveles.
• Geografía y datos demográficos. district_code, school_code y demographic aceptan listas de códigos separadas por comas.
• Filtros por columna. Cada columna categórica es su propio parámetro (p. ej. test_component=composite). Los valores separados por comas son OR dentro de un parámetro; varios parámetros se combinan con AND.

Cada página de conjunto de datos enumera sus parámetros de filtro exactos y sus valores permitidos.

Usa limit (predeterminado 1000, máximo 10000) y offset. El campo pagination.total siempre reporta el total de coincidencias para paginar de forma determinista.

Los errores devuelven { "error": { "code", "message", "details?" } } con el estado HTTP correspondiente — p. ej. TOPIC_NOT_FOUND (404), INVALID_FILTER_VALUE (400), RATE_LIMITED (429). La API tiene límites de tasa generosos; ante un 429, espera y reintenta.

No fijes las formas de los conjuntos de datos en tu código: descúbrelas:

• Catálogo. GET /api/v1/datasets lista cada conjunto de datos y dimensión.
• Esquema. GET /api/v1/datasets/{main}/{topic} devuelve columnas, filtros, rangos y valores permitidos como JSON.
• Contrato. .../contract?format=yaml devuelve el contrato ODCS sin procesar.

Consulta la referencia de endpoints para cada ruta, o explora el catálogo de conjuntos de datos.

Apunta un agente de programación a uno de estos — ambos se generan a partir de los mismos contratos:

• llms.txt Un índice de la API y de cada conjunto de datos.
• llms-full.txt La referencia completa y densa — cada columna, filtro, enum y rango en línea.
• openapi.json Esquema OpenAPI (nota: los filtros categóricos por columna se generan por solicitud y no se enumeran allí — usa los contratos o llms-full.txt para eso).