Skip to main content
Glama
CarlosJChileS

MCP Leyes Ecuador para Desarrolladores

MCP Leyes Ecuador para Desarrolladores

Servidor Model Context Protocol (MCP) en TypeScript para gobernanza de datos y leyes tecnológicas del Ecuador aplicadas a proyectos de software.

¿Qué es este proyecto?

Este proyecto conecta un asistente de inteligencia artificial con información jurídica ecuatoriana y herramientas técnicas para desarrolladores. Funciona como un servidor MCP local: el cliente MCP inicia el proceso y se comunica con él mediante stdio, sin abrir puertos ni exponer una API pública.

Su objetivo es ayudar a equipos de software a:

  • identificar normas ecuatorianas relacionadas con su producto;

  • traducir obligaciones jurídicas documentadas a controles técnicos y evidencias;

  • evaluar preliminarmente la gobernanza de datos;

  • auditar el repositorio y sus dependencias desde una perspectiva de seguridad y privacidad;

  • generar informes explicativos con brechas, responsables, fechas y acciones de remediación;

  • conservar el historial de auditorías y el estado de cada acción.

No es un sistema de asesoría legal ni reemplaza a un abogado, delegado de protección de datos, auditor de seguridad o autoridad competente.

Related MCP server: US Regulations MCP Server

Cómo funciona

Cliente MCP (Claude, Cursor, VS Code, etc.)
             │ stdio
             ▼
Servidor MCP local
   ├─ Catálogo jurídico verificable
   ├─ Evaluaciones de gobernanza
   ├─ Auditoría estática del repositorio
   ├─ Informes JSON / Markdown / HTML / PDF
   └─ Ciclo de vida persistente en .mcp-governance/

El servidor lee el catálogo incluido en data/normativa.json. Las auditorías de código son de solo lectura: no ejecutan el código del proyecto auditado. Las auditorías y acciones solo se guardan cuando se solicita explícitamente persist: true.

El producto es exclusivamente un servidor MCP local por stdio. Se utiliza desde un asistente o cliente compatible con MCP. Las herramientas, recursos y el prompt constituyen su interfaz; los reportes se devuelven como contenido de las respuestas MCP. Los scripts de catálogo y los workflows son utilidades internas de mantenimiento.

Aviso importante: este proyecto es una herramienta de investigación y preauditoría. No constituye asesoría legal, dictamen, certificación ni garantía de cumplimiento. La vigencia y aplicación de cada norma debe confirmarse en la fuente oficial y con un profesional competente.

Estado actual

  • Código actualizado en GitHub: 4d0da52.

  • Versión local preparada: 1.0.1.

  • Versión actualmente publicada en npm: 1.0.0.

  • La publicación de 1.0.1 requiere autenticarse con npm login y ejecutar npm publish --access public.

  • Las pruebas, compilación, validación del paquete y escáneres locales pasan en el entorno de desarrollo.

  • La cobertura jurídica continúa siendo preliminar: el catálogo no representa toda la legislación ecuatoriana y requiere revisión humana especializada.

  • El descargador revisa fuentes oficiales y, en la última ejecución, procesó 73 recursos: 60 documentos, 1 norma HTML, 5 fichas oficiales, 3 portales, 2 índices y 2 fuentes inaccesibles.

Instalación rápida desde npm

Requiere Node.js 20 o superior. Para clientes MCP que admiten npx, puede usar el paquete publicado:

{
  "mcpServers": {
    "leyes-ecuador-dev": {
      "command": "npx",
      "args": ["-y", "eculegaldev"]
    }
  }
}

Si npx no está disponible o desea controlar exactamente la versión, instale el paquete y use el ejecutable:

npm install -g eculegaldev
eculegaldev

En Windows, si el cliente no encuentra npx o node, configure la ruta absoluta al ejecutable, por ejemplo C:/Program Files/nodejs/npx.cmd o C:/Program Files/nodejs/node.exe.

Instalación desde GitHub

Úsela para desarrollar, modificar el catálogo o probar cambios que todavía no están publicados en npm:

git clone https://github.com/CarlosJChileS/eculegaldev.git
cd eculegaldev
npm ci
npm run build
npm run check

El cliente MCP debe apuntar a dist/server.js:

{
  "mcpServers": {
    "leyes-ecuador-dev": {
      "command": "node",
      "args": ["C:/ruta/eculegaldev/dist/server.js"]
    }
  }
}

También se puede instalar y probar con pnpm 10 o Bun:

pnpm install --frozen-lockfile
pnpm run check

bun install
bun run check

Windows

Instale Node.js 20 o superior desde nodejs.org y abra PowerShell:

git clone https://github.com/CarlosJChileS/eculegaldev.git
Set-Location eculegaldev
npm ci
npm run check

Opcionalmente, instale pnpm o Bun:

corepack enable
corepack prepare pnpm@10 --activate
pnpm install --frozen-lockfile
pnpm run check

irm bun.sh/install.ps1 | iex
bun install
bun run check

Ejemplo de configuración MCP en Windows:

{
  "mcpServers": {
    "leyes-ecuador-dev": {
      "command": "C:/Program Files/nodejs/node.exe",
      "args": ["C:/ruta/eculegaldev/dist/server.js"]
    }
  }
}

Si se usa npm instalado globalmente, también puede configurarse npx.cmd como comando.

macOS

Con Homebrew, instale Node.js y Git:

brew install node git
git clone https://github.com/CarlosJChileS/eculegaldev.git
cd eculegaldev
npm ci
npm run check

Para pnpm y Bun:

corepack enable
corepack prepare pnpm@10 --activate
pnpm install --frozen-lockfile
pnpm run check

curl -fsSL https://bun.sh/install | bash
bun install
bun run check

Ejemplo de configuración MCP en macOS:

{
  "mcpServers": {
    "leyes-ecuador-dev": {
      "command": "/opt/homebrew/bin/node",
      "args": ["/Users/tu-usuario/eculegaldev/dist/server.js"]
    }
  }
}

En Mac Intel, la ruta habitual puede ser /usr/local/bin/node. Compruébela con which node.

Linux

En Ubuntu, Debian u otra distribución compatible, instale Git y Node.js 20 o superior. Por ejemplo, con nvm:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.bashrc
nvm install 20
nvm use 20
git clone https://github.com/CarlosJChileS/eculegaldev.git
cd eculegaldev
npm ci
npm run check

Instalación alternativa de pnpm y Bun:

corepack enable
corepack prepare pnpm@10 --activate
pnpm install --frozen-lockfile
pnpm run check

curl -fsSL https://bun.sh/install | bash
bun install
bun run check

Ejemplo de configuración MCP en Linux:

{
  "mcpServers": {
    "leyes-ecuador-dev": {
      "command": "/usr/bin/node",
      "args": ["/home/tu-usuario/eculegaldev/dist/server.js"]
    }
  }
}

Use which node, which npm, which pnpm o which bun para confirmar las rutas. En servidores sin entorno gráfico, el MCP funciona igualmente porque utiliza stdio y no necesita abrir un navegador ni un puerto.

Comprobación común en cualquier sistema

Después de instalar, confirme las versiones y ejecute la verificación:

node --version
npm --version
npm run verify:all

El resultado esperado es una compilación correcta, 51 pruebas correctas y validación del paquete. Si el cliente no muestra las herramientas, revise la ruta absoluta de node y dist/server.js, vuelva a ejecutar npm run build y reinicie el cliente MCP.

Configuración en clientes MCP

La configuración exacta depende del cliente. En todos los casos se debe registrar un servidor local con un comando y sus argumentos, reiniciar el cliente y verificar que aparezcan las 13 herramientas, los recursos jurídicos y los dos prompts.

  • Claude Desktop: agregue la entrada en el archivo de configuración MCP de Claude Desktop.

  • Cursor: agregue el servidor en la sección MCP de Cursor.

  • VS Code: registre el servidor en la configuración MCP de la extensión compatible.

  • Otros clientes: use el mismo comando node dist/server.js o npx -y eculegaldev siempre que soporten transporte MCP por stdio.

El archivo docs/clients.md contiene ejemplos adicionales. Las rutas deben ser absolutas y usar la sintaxis de rutas aceptada por el sistema operativo.

Qué resuelve

Conecta un asistente compatible con MCP con un catálogo jurídico ecuatoriano y un auditor estático local. Permite buscar normas, consultar obligaciones, revisar señales técnicas de riesgo y generar un checklist inicial para proyectos tecnológicos y de comercio electrónico.

Cobertura actual

El catálogo contiene un núcleo relevante de normativa nacional sobre protección de datos, comercio electrónico, firmas y mensajes de datos, propiedad intelectual, telecomunicaciones, transformación digital, fintech, defensa del consumidor, delitos informáticos, facturación electrónica, transparencia y resoluciones recientes de protección de datos.

  1. Cobertura de todas las leyes del Ecuador: todavía no. No es aún una recopilación exhaustiva de toda la legislación nacional, códigos, reglamentos, ordenanzas, resoluciones sectoriales, normas municipales ni reformas históricas.

  2. Verificación jurídica completa de vigencia: no automática. La herramienta comprueba accesibilidad y dominio oficial; no determina por sí sola derogaciones, reformas, suspensión, texto consolidado, ámbito de aplicación ni vigencia jurídica.

Las fuentes de descubrimiento son los índices oficiales de la Asamblea Nacional y el Registro Oficial. Una referencia descubierta nunca se incorpora automáticamente como norma vigente.

Herramientas MCP

Evaluación integral de cualquier proyecto

El catálogo está especializado en proyectos tecnológicos que operan en Ecuador: aplicaciones web y móviles, SaaS, comercio electrónico, plataformas con usuarios, tratamiento de datos, proveedores cloud, pagos, facturación y sectores regulados.

evaluar_proyecto acepta un perfil explícito o puede inferir señales técnicas desde un repositorio:

{
  "name": "Mi proyecto",
  "repositoryPath": "C:/ruta/al/repositorio",
  "inferProfile": true,
  "language": "es"
}

La respuesta incluye normas y obligaciones por artículo, aplicabilidad, evidencia, brecha, estado, prioridad, exposición, responsable, criterio de cierre y puntajes por cumplimiento legal, seguridad técnica, privacidad, gobierno de datos, tributación, comercio electrónico y gestión documental. Las inferencias se pueden corregir enviando valores explícitos del perfil; esos valores tienen prioridad.

Los estados y consecuencias regulatorias son conservadores: una obligación sin evidencia no se marca como cumplida, y una consecuencia o sanción ausente del catálogo se devuelve como no documentada y requiere validación profesional. Con persistencia habilitada, el ciclo de gobernanza conserva evidencias, responsables, excepciones e historial para comparar evaluaciones.

  • buscar_normativa: búsqueda local por título, resumen, etiquetas y ámbito.

  • consultar_obligacion: consulta obligaciones asociadas a una norma.

  • verificar_vigencia: muestra estado, fechas, fuente y advertencias.

  • evaluar_proyecto: relaciona el tipo de proyecto con riesgos preliminares.

  • generar_checklist_auditoria: genera controles sugeridos.

  • evaluar_gobernanza_datos: revisa 22 dominios y sus brechas de cobertura.

  • generar_inventario_datos: prepara el inventario inicial de datos y evidencias faltantes.

  • evaluar_transferencia_datos: identifica controles para transferencias nacionales e internacionales.

  • evaluar_evaluacion_impacto: preclasifica riesgos y estructura la evaluación de impacto.

  • generar_matriz_responsabilidades: propone funciones y asignaciones pendientes.

  • generar_informe_gobernanza: reúne las cinco herramientas anteriores en JSON, Markdown, HTML o PDF.

  • gestionar_ciclo_gobernanza: guarda auditorías, acciones, evidencias, excepciones, responsables, fechas e historial.

  • auditar_repositorio: escaneo estático local de solo lectura.

Recursos: legal://normativa y legal://normativa/{id}. Prompts: revision-privacidad y revision-gobernanza-datos.

Idiomas

Las trece herramientas aceptan language: "es" (predeterminado) o language: "en" cuando aplica. Las evaluaciones, checklists y descargos se generan en el idioma seleccionado. En la auditoría se traducen el resumen, los encabezados de reportes, las explicaciones y recomendaciones de las reglas y los títulos y descripciones de los controles.

Informe consolidado de gobernanza

generar_informe_gobernanza ejecuta y consolida evaluación de gobernanza, inventario, transferencias, impacto y responsabilidades. Incluye resumen ejecutivo, cobertura de los 22 dominios, brechas, evidencias, fuentes y descargo jurídico.

Cada problema detectado produce una acción GOV-### que explica:

  • qué está mal o incompleto y por qué importa;

  • prioridad crítica, alta, media o baja;

  • responsable sugerido;

  • pasos concretos y ordenados para solucionarlo;

  • documentos, registros o pruebas que deben conservarse;

  • criterio verificable para considerar cerrada la acción.

El plan cubre fuentes normativas pendientes, clasificación e inventario, calidad, accesos, retención, transferencias, evaluaciones de impacto y roles sin asignar. Las recomendaciones técnicas pueden automatizarse; la vigencia, aplicabilidad y suficiencia jurídica deben ser aprobadas por una persona competente.

Si se proporciona repositoryPath, la misma llamada ejecuta la auditoría, incorpora archivos y directorios recorridos, entradas omitidas y hallazgos con archivo y línea. Con dependencyScan: true también agrega vulnerabilidades, versiones detectadas y corregidas, escáneres ausentes y soluciones. Cada hallazgo técnico se convierte en una acción GOV-### con recomendación, pruebas esperadas y criterio de cierre.

“Repositorio completo” significa todos los archivos reconocidos y legibles dentro de maxDepth, maxFiles y maxFileSizeBytes, respetando exclusiones y enlaces seguros. El informe declara sus conteos y omisiones; no afirma revisar archivos fuera de esos límites, binarios, servicios externos, bases de datos activas ni secretos ausentes de los archivos examinados.

{
  "name": "API ciudadana",
  "dataTypes": ["cédula", "correo"],
  "systems": ["API", "PostgreSQL"],
  "owners": ["responsable del tratamiento"],
  "internationalTransfers": true,
  "retentionDays": 365,
  "repositoryPath": "C:/repos/api-ciudadana",
  "maxDepth": 12,
  "maxFiles": 2000,
  "maxFileSizeBytes": 1048576,
  "dependencyScan": true,
  "timeout": 120000,
  "format": "markdown"
}

format admite json, markdown, html y pdf. HTML incluye estilos A4 para imprimir. Con persist: true y lifecycleActor, el informe se guarda en .mcp-governance/audits/ y actualiza .mcp-governance/lifecycle.json. Como MCP por stdio transporta texto, PDF devuelve un objeto con fileName, mimeType, encoding: "base64" y data; el cliente debe decodificar data para guardar el archivo indicado. El informe es una evaluación preliminar y no una certificación legal.

gestionar_ciclo_gobernanza permite listar, actualizar_accion, agregar_evidencia y agregar_excepcion. Conserva acciones abiertas y cerradas, responsables, fechas límite, evidencias, excepciones con expiración y un historial de actor, fecha y operación. Una excepción cambia la acción a aceptada_temporalmente.

El almacenamiento es local y auditable. La primera auditoría crea .mcp-governance/lifecycle.json y una copia inmutable en .mcp-governance/audits/. Las auditorías posteriores actualizan o reutilizan las acciones por su identificador, sin eliminar el historial anterior. Para cerrar una acción, el responsable debe actualizarla explícitamente y conservar evidencias suficientes.

Ejemplos conceptuales de operaciones:

{
  "repositoryPath": "C:/repos/api-ciudadana",
  "operation": "actualizar_accion",
  "actionId": "GOV-001",
  "status": "en_progreso",
  "owner": "Equipo de privacidad",
  "dueDate": "2026-10-15",
  "actor": "Carlos"
}

Una evidencia requiere description y uri. Una excepción requiere reason, approvedBy y expiresAt; no equivale a cumplimiento permanente y debe revisarse antes de su vencimiento.

Los títulos y textos normativos conservan el idioma de la fuente. Los identificadores, categorías y estados son valores estables del contrato y no se traducen; por ejemplo, transporte_inseguro y pendiente. Las evidencias, rutas, avisos de dependencias y detalles de errores conservan su contenido original. Los recursos jurídicos y el prompt revision-privacidad están en español.

Auditoría de repositorios

auditar_repositorio inspecciona archivos de texto sin ejecutar el código. Detecta señales sobre secretos, datos personales, logging, autenticación, seguridad, infraestructura y documentación de privacidad.

Reconoce JavaScript, TypeScript, Vue, Python, Java, Kotlin, Scala, Groovy, Gradle, C#, F#, VB.NET, Go, Rust, Ruby, C, C++, Swift, Dart, SQL, Shell, PHP, YAML, JSON, JSONC, TOML, .env, INI, Docker, Terraform, XML, HTML, CSS, Markdown y texto plano. También reconoce Dockerfile, Containerfile, Gemfile, Rakefile, README, LICENSE y .env*.

Ejemplo:

{
  "path": "C:/repos/mi-proyecto",
  "maxDepth": 6,
  "maxFiles": 500,
  "maxFileSizeBytes": 262144,
  "format": "json",
  "language": "es",
  "dependencyScan": true
}

El resultado incluye resumen, lenguajes detectados, hallazgos por severidad, controles sugeridos, referencias y descargo de responsabilidad. Puede generar JSON, Markdown o HTML y ejecutar escáneres locales disponibles como npm audit, pip-audit, cargo audit, herramientas .NET y osv-scanner.

El análisis estático no ejecuta código del repositorio: excluye dependencias y builds, evita enlaces simbólicos fuera de la raíz, limita profundidad/tamaño/cantidad de archivos y redacta valores sensibles. El escaneo de dependencias es opcional y ejecuta herramientas externas; estas pueden consultar servicios de vulnerabilidades y utilizar cachés locales.

Parámetros de auditar_repositorio

Parámetro

Valor por defecto

Uso

path

Obligatorio

Ruta del repositorio; se recomienda absoluta.

maxDepth

6

Profundidad del análisis estático, entre 1 y 12.

maxFiles

500

Máximo de archivos del análisis estático, entre 1 y 2000.

maxFileSizeBytes

262144

Tamaño máximo por archivo, entre 1024 y 1048576 bytes.

format

json

json, markdown, html o sarif; SARIF permite integrarlo con GitHub Code Scanning.

language

es

es o en.

dependencyScan

false

Activa los escáneres de dependencias instalados.

timeout

30000

Tiempo máximo por comando externo, entre 1000 y 120000 ms.

Por defecto, el servidor no guarda reportes automáticamente. Con persist: true, el informe consolidado se registra en el ciclo de vida local y el cliente recibe su auditId. El cliente también puede guardar el contenido que recibe; el HTML incluye estilos de impresión. Un error de auditoría devuelve isError: true y un objeto con error, detail, language y disclaimer.

Configuración del repositorio auditado

Coloque un archivo .mcp-audit.json en la raíz del repositorio que desea auditar:

{
  "limits": { "maxDepth": 6, "maxFiles": 500, "maxFileSizeBytes": 262144 },
  "excludePaths": ["fixtures", "generated"],
  "statuses": {
    "findings": {
      "byId": {},
      "byRuleId": { "missing-privacy-docs": "pendiente" },
      "byCategory": {}
    },
    "controls": {
      "byId": { "control-revision-fuentes": "pendiente" },
      "byCategory": {}
    }
  }
}

Los parámetros de límites de la llamada tienen prioridad sobre el archivo. excludePaths acepta rutas relativas o prefijos de directorio, no patrones glob. El filtro se aplica después del recorrido: los archivos excluidos pueden consumir el límite de archivos. Esta configuración corresponde al análisis estático, no al escaneo externo de dependencias.

Estados permitidos: cumple, no cumple, no aplica, pendiente. Para hallazgos, la prioridad es identificador, regla y categoría; para controles, identificador y categoría. El valor predeterminado es pendiente. El servidor lee estos estados; su actualización y persistencia requieren editar el archivo. Un estado asignado no modifica la severidad ni demuestra cumplimiento por sí mismo.

Escáneres opcionales

Deben estar disponibles en el PATH del proceso que inicia el cliente MCP:

Ecosistema

Herramienta invocada

Preparación

Node.js

npm audit --json

npm y un lockfile compatible en el proyecto.

Python

pip-audit --format json

Instalar pip-audit; los archivos requirements se pasan con --requirement.

Rust

cargo audit --json

Instalar Cargo y el subcomando cargo-audit; disponer de Cargo.lock.

.NET

dotnet list … package --vulnerable --include-transitive --format json

SDK compatible y proyecto con dependencias restauradas.

Varios

osv-scanner --format json --recursive …

Versión de OSV Scanner compatible con esos argumentos.

Una herramienta ausente o fallida queda reflejada en el reporte; no equivale a ausencia de vulnerabilidades. Las pruebas usan adaptadores simulados para estos comandos y no acreditan que estén instalados en su equipo. La conexión MCP y el análisis estático se prueban con un proceso real.

Para una coincidencia intencional, agregue mcp-audit-ignore en esa línea y explique el motivo. La excepción queda visible en el código y no debe usarse para ocultar vulnerabilidades reales.

Instalación y uso

Requiere Node.js 20 o superior. Para usar la versión local actual, el proyecto ya incluye configuración compatible con npm, pnpm 10 y Bun.

npm ci
npm run check
npm run verify:all

También funciona con pnpm y Bun:

pnpm install --frozen-lockfile
pnpm run check

bun install
bun run check

Para desarrollo, npm run dev, pnpm run dev y bun run dev son equivalentes. El servidor se ejecuta por stdio; no se abre un puerto HTTP.

npm run check compila el servidor y ejecuta todas las pruebas, incluida la conexión real por stdio. Configure su cliente MCP para lanzar directamente el archivo compilado con Node:

{
  "mcpServers": {
    "leyes-ecuador": {
      "command": "node",
      "args": ["C:/ruta/al/proyecto/dist/server.js"]
    }
  }
}

El catálogo está en data/normativa.json y se resuelve relativo al servidor compilado.

Reemplace la ruta de ejemplo por la ruta absoluta de su copia. Conserve dist/ y data/ dentro de la carpeta del proyecto; el cliente puede iniciar el proceso desde otro directorio. Si el cliente no encuentra node, use la ruta absoluta del ejecutable en command. Reinicie o reconecte el cliente después de recompilar.

Al conectarse deben aparecer trece herramientas, el recurso legal://normativa, la plantilla legal://normativa/{id} y los dos prompts. Puede pedir al asistente: «Genera el informe consolidado de gobernanza de API ciudadana en PDF» o «Audita el repositorio C:/repos/mi-proyecto en español, sin escanear dependencias».

Para diagnosticar el arranque, ejecute node dist/server.js. Es normal que espere sin mostrar texto: recibe mensajes MCP por la entrada estándar y reserva la salida estándar para el protocolo. Los errores de inicio se escriben en la salida de errores. npm run dev permite trabajar con el código TypeScript; vuelva a compilar antes de usar la configuración de producción del cliente.

Catálogo y verificación

npm run catalog:discover
npm run catalog:verify
npm run catalog:import
npm run catalog:review
npm run catalog:coverage
npm run catalog:legal-review
npm run catalog:download

catalog:legal-review genera data/legal-review-report.json, consulta las fuentes registradas y detecta indicios textuales de reformas o derogaciones. Estos indicios nunca cambian automáticamente una norma a vigente, reformada o derogada. Para publicar un estado confirmado, la entrada debe incluir verification.legalReviewedAt y verification.reviewer; el servidor rechaza el catálogo si faltan.

catalog:download intenta descargar el documento o página oficial de cada fuente HTTPS registrada en el catálogo. Guarda los archivos accesibles en data/downloads/ y genera data/download-manifest.json con fuente, URL, fecha, HTTP, tipo MIME, tamaño, hash SHA-256 y error detallado cuando corresponde. La descarga está limitada a dominios oficiales *.gob.ec, 20 MiB por archivo y 20 segundos por solicitud.

El manifiesto clasifica cada recurso como documento_normativo, norma_html, ficha_oficial, indice_normativo, portal_institucional o inaccesible. Cuando una ficha o portal contiene enlaces oficiales a PDF, DOC o DOCX, el descargador los sigue y registra los documentos derivados por separado.

Una descarga exitosa demuestra que el recurso estaba accesible, pero no que su contenido sea un texto normativo consolidado ni que la norma esté vigente. Las páginas HTML de portales se conservan como evidencia de consulta; los PDF u otros documentos deben relacionarse manualmente con artículos, Registro Oficial, reformas y derogaciones antes de usarlos para confirmar cumplimiento.

Informes:

  • data/discovered-sources.json: referencias pendientes de revisión.

  • data/verification-report.json: accesibilidad y dominio oficial.

  • data/catalog-pending.json: referencias oficiales importadas como pendientes de clasificación y revisión jurídica.

  • data/catalog-review.json: clasificación preliminar y verificación documental de accesibilidad; no certifica vigencia.

  • data/coverage-report.json: tamaño, estados, tipos, temas, historial y revisiones jurídicas documentadas.

.github/workflows/catalog-monitor.yml ejecuta semanalmente pruebas, compilación, descubrimiento y verificación. Si encuentra cambios, abre un Pull Request para revisión humana.

Roadmap jurídico

Se debe incorporar un catálogo histórico y actualizado del Registro Oficial, con:

  • control de reformas y texto consolidado;

  • registro de derogaciones, sustituciones y vigencia temporal;

  • relación entre ley, código, reglamento y resolución;

  • clasificación por sector: tecnología, comercio electrónico, financiero, laboral, tributario, consumo, salud, educación y otros;

  • trazabilidad a número, suplemento, fecha y página del Registro Oficial;

  • estados separados para accesibilidad técnica, revisión documental y vigencia jurídica;

  • revisión humana antes de publicar cambios normativos.

El modelo de datos ya admite officialGazette, history, relatedSourceIds y verification, para conservar número/edición/página del Registro Oficial, reformas, derogaciones, relaciones y trazabilidad de los revisores.

Este trabajo requiere fuentes oficiales completas, reglas de consolidación y revisión jurídica. No se debe inferir vigencia únicamente desde una URL accesible.

La importación automática prepara referencias para revisión; no las mezcla con data/normativa.json hasta completar sus metadatos y confirmar su estado.

Desarrollo

npm test -- --run
npm run build
npm run catalog:verify

La suite valida catálogo, búsquedas, obligaciones, gobernanza, auditoría, detección multilenguaje, reportes y límites de seguridad. La prueba de integración inicia el servidor compilado desde un directorio temporal, negocia el protocolo MCP, valida las trece herramientas, lee el índice y una ficha jurídica, obtiene los prompts y comprueba formatos y errores.

Responsabilidad

Las normas enlazadas pertenecen a sus fuentes oficiales. Este proyecto no sustituye la revisión legal, técnica, contractual ni de seguridad necesaria para operar un sistema en producción.

Privacidad y uso responsable

El servidor procesa localmente el repositorio y los parámetros que el usuario envía. No mantiene telemetría propia ni envía el código a un modelo desde el servidor. El cliente MCP y sus proveedores pueden aplicar políticas independientes al contenido de las respuestas. Las verificaciones, descargas de fuentes y escáneres de dependencias pueden conectarse a internet.

El servidor no guarda informes por defecto. Cuando se activa persist: true, las auditorías, evidencias, responsables, fechas, excepciones e historial se almacenan en .mcp-governance/ bajo el control del usuario. Revise los reportes antes de compartirlos y no incluya secretos, datos personales o repositorios privados sin autorización. Consulte la Política de privacidad y Seguridad.

Esta documentación no constituye una política corporativa, asesoría legal ni certificación de cumplimiento. Cada organización debe definir su responsable, base jurídica, plazos de conservación, controles de acceso y procedimiento para atender derechos de titulares conforme a su tratamiento real.

Available Tools

6 tools
auditar_repositorioA

Ejecuta una auditoría estática local y de solo lectura sobre un repositorio con límites seguros.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
formatNo
timeoutNo
maxDepthNo
maxFilesNo
dependencyScanNo
maxFileSizeBytesNo

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does disclose key behavioral traits: read-only, local, static, and bounded by safe limits. This is valuable safety information, though it does not detail what those limits are or how failures are handled.

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?

A single, front-loaded sentence communicates the core purpose and behavioral character with no filler. Every phrase earns its place, even if 'límites seguros' is somewhat vague.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description is too sparse for an agent to call the tool reliably without guessing. It does not mention return format, how to use path, what dependencyScan implies, or the meaning of the safety limits in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate. Phrases like 'límites seguros' hint at timeout and max* parameters but explain none of the 7 parameters, including format, dependencyScan, or path semantics.

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 states a specific action ('auditoría estática local y de solo lectura') on a clear resource ('repositorio'), using a distinct verb and scope. It differentiates from sibling tools like evaluar_proyecto or generar_checklist_auditoria by focusing on a local, read-only repository audit.

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?

Usage is implied: an agent would select this tool when needing to audit a repository. However, there is no explicit guidance on when to prefer this over siblings, no exclusion criteria, and no mention of prerequisites or context.

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

buscar_normativaA

Busca normativa ecuatoriana verificable por texto y tema. Use language=es o language=en.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo
topicNo
languageNo

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It indicates a search/read operation and mentions the language enum, but it does not describe result format, scope limitations, pagination, or prerequisites. 'Verificable' hints at source quality but is ambiguous.

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 compact: the primary action is front-loaded, and the second sentence provides immediately actionable parameter guidance. Every word earns its place without filer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter search tool, the core calling information is present, including language selection. However, there is no output schema and the description does not state what the tool returns, nor clarify how an empty call behaves given that all parameters are optional. This leaves some ambiguity for an agent.

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 descriptions are absent (0% schema description coverage), but the description maps 'texto' to the query parameter and 'tema' to the topic parameter. The phrase 'Use language=es o language=en' explicitly explains the language enum. It does not clarify how query and topic interact or whether at least one is needed, but it compensates for the bare schema.

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 uses a specific verb, 'Busca', and a clear resource, 'normativa ecuatoriana', with two search dimensions: text and topic. This clearly distinguishes it from sibling tools like generar_checklist_auditoria or auditar_repositorio, which are not search tools.

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 context is implied: use this when searching Ecuadorian regulations by text or topic. However, there is no explicit comparison to siblings such as consultar_obligacion or verificar_vigencia, and the language instruction is parameter guidance rather than when-to-use guidance.

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

consultar_obligacionB

Consulta una ficha normativa por identificador.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
languageNo

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description bears the full burden of disclosing behavior, yet it only states the core operation. It does not mention return format, whether the operation is read-only, error behavior, or how the language parameter affects results. The Spanish verb 'Consulta' weakly implies a read operation, but critical behavioral context is missing.

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 description is a single front-loaded sentence with zero filler, stating the verb and resource immediately. It is appropriately concise for a simple lookup tool, though the brevity leaves out useful guidance that would push it higher.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description should explain what the call returns and any caveats; it does neither. The language parameter's effect on the response is also absent. The core purpose is clear, but an agent lacks essential information about response shape and optional behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only clarifies that 'id' is the identifier. The 'language' parameter and its es/en enum are completely unexplained. This is insufficient compensation for the complete lack of schema descriptions.

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 uses a specific verb ('Consulta'), a precise resource ('ficha normativa'), and a clear lookup method ('por identificador'). This differentiates it from siblings like buscar_normativa (text search) and verificar_vigencia (validity check), so an agent can tell them apart.

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 phrase 'por identificador' implies this tool should be used when the agent already has a regulatory record ID, but it never explicitly states when to prefer it over alternatives or mentions exclusions. Usage guidance is present but only implicit.

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

evaluar_proyectoC

Genera riesgos y controles preliminares para un proyecto.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
languageNo
sellsOnlineNo
usesProvidersNo
storesSensitiveDataNo
processesPersonalDataNo

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavior. It indicates the tool generates preliminary risks and controls, but does not clarify whether it persists results, requires special permissions, or produces AI-generated output that should be reviewed. The word 'preliminares' adds a small degree of context but not enough.

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 description is a single, direct sentence with no filler. It is appropriately front-loaded with the main action and result, though it sacrifices helpful detail for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, no annotations, and six parameters with zero schema documentation, this description is incomplete. An agent does not know the output format, whether the operation has side effects, how parameters affect results, or what 'preliminary' means operationally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should compensate by explaining parameter meaning, but it does not. The booleans are reasonably self-explanatory from their names, but the description fails to confirm how they influence the generated risks/controls or what 'name' and 'language' fully contribute.

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 description clearly states a specific verb ('Genera') and resource ('riesgos y controles preliminares para un proyecto'), which distinguishes it from siblings focused on regulation lookup and auditing. It could be slightly more explicit about the supporting inputs, but the core purpose is understandable.

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

Usage Guidelines2/5

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

No guidance is given on when to prefer this tool over siblings like generar_checklist_auditoria or auditar_repositorio. The context implies it is for project risk evaluation, but there are no stated conditions, exclusions, or alternative routing.

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

generar_checklist_auditoriaC

Genera una lista reproducible de evidencias para auditoría.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes
languageNo
sellsOnlineNo
usesProvidersNo
storesSensitiveDataNo
processesPersonalDataNo

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool generates a reproducible evidence list, but it does not explain whether the operation has side effects, how the boolean parameters affect behavior, what output format to expect, or whether anything is persisted.

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 description is a single concise sentence with no filler words. It is front-loaded with the core purpose, though it lacks any structured elaboration about parameters or output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters, no output schema, and no annotations, this description is far too sparse to allow an agent to invoke the tool correctly. It doesn't explain how the inputs map to an audit checklist or what the returned 'lista de evidencias' contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention any of the six input parameters. It does not clarify the role of 'name', the meaning of 'language', or how 'sellsOnline', 'usesProviders', 'storesSensitiveData', and 'processesPersonalData' shape the generated checklist.

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 description clearly states the tool's action and resource: 'Genera una lista reproducible de evidencias para auditoría.' This is specific enough to distinguish it from siblings that search regulations, consult obligations, or audit repositories, though it does not explicitly name a sibling or scope the audit type.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus the sibling tools such as 'auditar_repositorio' or 'evaluar_proyecto.' The description implies use when an audit evidence list is needed, but it provides no exclusions, prerequisites, or context for choosing among alternatives.

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

verificar_vigenciaC

Devuelve estado y fecha de verificación de una fuente.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
languageNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses the return payload (status and verification date) but says nothing about mutation guarantees, error behavior, permissions, or what happens when an id is not found. For a verification-style tool this is only partially transparent.

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 description is a single front-loaded sentence with no filler; every word contributes to the core message. It is appropriately minimal for a simple tool, even though it could convey more useful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without annotations or an output schema, the description should provide enough information for correct invocation. It omits id semantics, language behavior, and failure handling, and never explicitly connects the tool to the apparent legal-norm domain suggested by the sibling names.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain what 'id' identifies or how 'language' affects the result. Neither 'fuente' nor the return statement clarifies parameter meaning or expected formats. The agent is left with only the property names and schema constraints.

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 description uses a specific return verb ('Devuelve') and identifies the resource ('estado y fecha de verificación de una fuente'), making the core function clear. It is not a tautology of the name and its focus on status/verification date distinguishes it from siblings like buscar_normativa or auditar_repositorio, though 'fuente' is somewhat vague.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as consultar_obligacion or buscar_normativa. There are no stated conditions, exclusions, or prerequisites. An agent would need to infer usage from the tool name and sibling context, which the description itself does not support.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.0
    • First observedauditar_repositorio
    • First observedbuscar_normativa
    • First observedconsultar_obligacion
    • First observedevaluar_proyecto
    • First observedgenerar_checklist_auditoria
    • First observedverificar_vigencia

TDQS

B3.3/5.0

Scored across 6 tools

Disambiguation4/5

Cada herramienta tiene un propósito recognoscible: búsqueda normativa, consulta por identificador, verificación de vigencia, evaluación de proyecto, checklist y auditoría. Sin embargo, evaluar_proyecto, generar_checklist_auditoria y auditar_repositorio están relacionados y podrían generar dudas sobre cuál usar según el resultado esperado.

Naming Consistency5/5

Todas las herramientas usan verbo en infinitivo en español seguido de un sustantivo, con snake_case uniforme: buscar_, consultar_, verificar_, evaluar_, generar_, auditar_. La convención es predecible y no hay mezcla de estilos.

Tool Count5/5

Con 6 herramientas el servidor cubre un espectro razonable para consulta legal y auditoría de cumplimiento: búsqueda, consulta, vigencia, evaluación, checklist y ejecución de auditoría. La cantidad está bien proporcionada al propósito declarado.

Completeness4/5

El conjunto cubre el ciclo de consulta normativa (buscar, consultar, verificar vigencia) y su aplicación práctica (evaluar, checklist, auditar). Faltaría quizá una función para listar o exportar todas las obligaciones de una norma, pero los flujos principales no quedan en punto muerto.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Multi-jurisdictional legal AI MCP server for Spanish, Latin American, and European law. 11 tools: analyze, audit, draft, jurisprudencia search (CENDOJ ~141k + Colombian courts ~106k), cross-border comparison, Monte Carlo litigation simulation, doctrina, redteam, and more. ISO 31000 certainty locks. Zero Retention. GDPR/LGPD compliant. Install: npx -y @nexus-legal/mcp
    11
    120
    2
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables natural language queries on technical specifications and automated code compliance checks using local RAG with vector search, integrated via MCP.
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables MCP-compatible AI agents to scan code for leaked secrets, copyleft licenses, unprotected routes, missing privacy policies, and risky card handling before committing or shipping.
    63
    MIT