> ## Documentation Index > Fetch the complete documentation index at: https://docs.fhiron.cl/llms.txt > Use this file to discover all available pages before exploring further. # Cómo se cuentan las validaciones > Qué cuenta como una validación, qué no, y qué pasa cuando se agota la cuota mensual del plan. Cada plan incluye una cantidad definida de validaciones por mes. La regla es transparente y consistente entre los tres canales: Inspect UI, API REST y MCP connector. ## Resumen rápido | Acción | Cuesta | | ----------------------------------------------------------- | -------------- | | Validar un recurso (Patient, Encounter, MedicationRequest…) | 1 validación | | Validar un Bundle de N entries | N validaciones | | Validar el mismo recurso dos veces | 2 validaciones | | Comparar el mismo recurso contra FHIR® R4 y CL Core | 2 validaciones | | Linter local en el editor | 0 | | Buscar terminología (DEIS · TFC · CIE-10 · identificadores) | 0 | | Pedir un ejemplo CL Core válido | 0 | | Aplicar un quick-fix sobre tu JSON | 0 | | Escanear un endpoint FHIR público (FHIR Score) | 0 | | Pedir explicación pedagógica de un código de error | 0 | Las acciones con costo 0 corren localmente en el connector MCP o en el cliente. No tocan el motor de validación de Fhiron. ## Por canal Las tres rutas para validar contra CL Core pasan por el mismo endpoint `POST /api/validate` y descuentan idéntico de la cuota: | Canal | Cómo se invoca | | ------------------------------ | ------------------------------------ | | **Inspect UI** (dashboard web) | Pegando el JSON en el editor | | **API REST** | `POST /api/validate` con `X-API-Key` | | **MCP connector** | Tu agente IA llama `fhiron_validate` | No hay canal privilegiado: la validación que hace tu agente IA en Cursor cuesta exactamente lo mismo que la que hace tu pipeline de CI con cURL. ## Tabla detallada por tool del MCP El connector `@fhiron/mcp-connector` expone 10 tools. Cada una tiene un costo claro: | Tool | Costo | Comentario | | --------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | `fhiron_validate` | 1 validación | El caso default cuando le pides al agente "valida esto". | | `fhiron_validate_file` | 1 validación | Igual que `fhiron_validate` pero leyendo un `.json` del filesystem. | | `fhiron_validate_bundle` | 1 validación por entry validada (cap 50 por defecto, configurable hasta 200) | El cap protege la cuota cuando un Bundle tiene cientos de entries. | | `fhiron_compare_profiles` | 2 validaciones | Valida en paralelo contra el perfil R4 base y contra CL Core. | | `fhiron_lint` | 0 | Reglas locales `cl-*` ejecutándose en el connector. Sin red. | | `fhiron_apply_fix` | 0 | Aplica un parche RFC 6901 sobre tu JSON. Sin red. | | `fhiron_get_example` | 0 | Devuelve un ejemplo CL Core vendorizado en el connector. | | `fhiron_search_terminology` | 0 | Búsqueda en catálogos vendorizados (DEIS, TFC, CIE-10, identificadores). | | `fhiron_explain_code` | 0 | Catálogo `cl-*`/`hapi-*`/`mcp-*` vendorizado. | | `fhiron_score_endpoint` | 0 | Lee el `CapabilityStatement` de un endpoint público y calcula score local. | ## Bundle: el caso que más confunde Un `Bundle` en FHIR puede contener cientos o miles de recursos. Fhiron valida **cada entry contra su propio perfil**. Por eso: * Bundle con 12 entries → 12 validaciones. * Bundle con 200 entries → 200 validaciones. * Bundle con 5 000 entries → 5 000 validaciones (en MCP requiere subir explícitamente el `max_server_calls`). Para evitar consumir la cuota sin querer, `fhiron_validate_bundle` por defecto valida hasta **50 entries** por llamada. Si necesitas más, pídele al agente "valida hasta 200 entries": el modelo le pasa `max_server_calls: 200` (límite duro 200 por llamada). ## Pipelines de IA con datasets grandes Si tu agente IA está iterando sobre cientos o miles de recursos para validar un dataset, ten en cuenta: * Cada iteración del agente que llame `fhiron_validate` cuenta 1 validación. * Si el agente vuelve a validar el mismo recurso después de aplicar un quick-fix, cuenta 1 más. * El linter local (`fhiron_lint`) es la tool gratuita y determinística para descartar errores estructurales antes de gastar cuota. Pídele al agente "valida con lint primero, después en servidor solo si pasa el lint". Esa práctica baja drásticamente el consumo. Las reglas locales `cl-*` cubren la mayoría de los errores de migración inicial (campos `required` ausentes, ValueSets mal pegados, fechas no ISO-8601). ## Qué pasa al agotar la cuota Cuando se agota la cuota mensual del plan: * La API responde HTTP `429` con un cuerpo JSON describiendo la cuota agotada. * Los headers `X-RateLimit-*` indican el detalle: * `X-RateLimit-Limit`: cuota mensual del plan (ej: `10000`). * `X-RateLimit-Remaining`: validaciones restantes (`0` cuando se agotó). * `X-RateLimit-Reset`: timestamp Unix del próximo reseteo. * En el dashboard recibes un aviso por email cuando llegas al 80% del límite. La cuota se reinicia el primer día de cada mes calendario. ## Lo que **no** cuenta como validación Para mantener la regla limpia, esto **no descuenta** del plan: * Listar las API keys del tenant. * Consultar el dashboard de uso (`/dashboard`). * Recibir webhooks de billing. * Que tu IDE descargue un esquema CL Core a través del MCP. * El handshake inicial del MCP connector con el servidor. ## Headers de respuesta Cada `POST /api/validate` exitoso incluye: ```http theme={null} HTTP/1.1 200 OK X-RateLimit-Limit: 10000 X-RateLimit-Remaining: 9847 X-RateLimit-Reset: 1748737200 ``` Tu pipeline puede leer esos headers para decidir si conviene seguir validando o esperar al reseteo. ## Resumen para tu plan | Plan | Validaciones / mes | Caso típico | | ---------- | ------------------ | ------------------------------------------------------------- | | Free | 100 | Probar el conector y validar recursos puntuales en el editor. | | Basic | 1 000 | Dev individual o equipo chico iterando contra CL Core. | | Pro | 10 000 | Equipo mediano con CI/CD que valida en cada commit. | | Team | 50 000 | Producto en producción con tráfico real de varios sistemas. | | Enterprise | A convenir | Volumen alto sostenido o batch de IA contra datasets enormes. | Si tu uso supera el plan Team de forma sostenida, contáctanos para Enterprise. Los volúmenes negociados por contrato salen más baratos por validación que el overage automático. ## Preguntas frecuentes **¿Validar y volver a validar el mismo recurso cuesta dos validaciones?** Sí. Cada llamada al motor cuenta. Si solo necesitas confirmar que un cambio menor no rompió nada, usa `fhiron_lint` primero (gratuito) y reserva la validación de servidor para el final. **¿El MCP cuenta distinto que la API REST?** No. Ambos llegan al mismo `/api/validate` y descuentan idéntico. La diferencia es que el MCP, además, expone tools locales (`fhiron_lint`, `fhiron_apply_fix`, etc.) que no descuentan. **¿Hay descuentos por volumen?** Los planes mayores ya incluyen un costo por validación más bajo (Team es \~5x más barato por validación que Basic). Para volúmenes Enterprise el descuento se negocia por contrato. **¿Pierdo validaciones no usadas al fin de mes?** Sí. La cuota se reinicia el primer día de cada mes calendario, no acumula. **¿Qué pasa si mi agente IA valida 10 000 recursos de un dataset por error?** Si tu plan tiene cuota suficiente, se descuentan y listo. Si no, recibes HTTP `429` y el agente puede actuar (avisarte, parar, o esperar). Para batch grande planeado conviene un plan Team o Enterprise, y siempre pasar primero por `fhiron_lint` para no malgastar cuota en errores estructurales. ## Más sobre planes * [Pricing detallado](https://fhiron.cl/pricing) en el sitio web. * [API reference](/inspect/api) con headers, errores y rate limits. * [Cookbook MCP por tool](/mcp/ejemplos) con costos en cada sección.