How do I use Gobernador IA MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gobernador IA MCP Server Audit this text against Ley 21.719 and EU AI Act" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Gobernador IA MCP Server

by CodexPromptusIuris

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Gobernador IA MCP Server

MCP server de auditoría de compliance de IA para VibeCodingChile — expone el motor de reglas de Gobernador IA como tools que cualquier agente Claude puede invocar, contra Ley 21.719 (Chile), ISO/IEC 42001:2023, y el EU AI Act.

⚠️ Disclaimer: las referencias normativas (artículos, cláusulas) fueron construidas desde memoria de un LLM, sin búsqueda ni verificación en vivo contra el texto legal oficial. Verifica cada referencia antes de usarla en un informe a cliente, regulador, o en el pitch de Anthropic. Trátalo como borrador de alta calidad, no como fuente legal certificada.

Tools expuestas

Tool	Qué hace
`gobernador_audit_text`	Analiza texto libre y detecta hallazgos de compliance contra 1 o los 3 frameworks
`gobernador_check_data_flow`	Vista rápida enfocada en transferencias internacionales y necesidad de DPIA
`gobernador_map_cross_framework`	Busca un concepto en la ontología y muestra su equivalente en las 3 normativas
`gobernador_generate_compliance_report`	Informe ejecutivo agregado, con resumen por severidad y conceptos relacionados

Related MCP server: attestix

Uso local (stdio)

npm install
npm run build
npm start

Config para Claude Desktop / Claude Code (claude_desktop_config.json o equivalente):

{
  "mcpServers": {
    "gobernador-ia": {
      "command": "node",
      "args": ["/ruta/absoluta/a/gobernador-ia-mcp-server/dist/index.js"]
    }
  }
}

Uso local (HTTP)

npm run build
npm run start:http
# Server en http://localhost:3000/mcp

Deploy a Vercel (remoto, para conectar como connector)

Mismo patrón que ya usas para el resto del stack (GitHub → Vercel):

# 1. Inicializar repo si no existe
git init
git add .
git commit -m "Gobernador IA MCP Server v1.0.0"

# 2. Crear repo en GitHub y hacer push
gh repo create vibecodingchile/gobernador-ia-mcp-server --private --source=. --push
# (o manualmente: crear repo en GitHub, git remote add origin ..., git push)

# 3. Deploy con Vercel CLI (o conectar el repo desde el dashboard de Vercel)
npx vercel --prod

El endpoint MCP remoto quedará en:

https://<tu-proyecto>.vercel.app/mcp

Health check en:

https://<tu-proyecto>.vercel.app/health

Conectar el server remoto a Claude

En claude.ai → Settings → Connectors → Add custom connector, usando la URL https://<tu-proyecto>.vercel.app/mcp.

O vía API con mcp_servers:

{
  "type": "url",
  "url": "https://<tu-proyecto>.vercel.app/mcp",
  "name": "gobernador-ia"
}

Extender la ontología

Los 51 conceptos completos de tu VibeCodingChile MCP Server no están en este build — aquí incluí 20 conceptos núcleo (src/data/ontology.ts) y 15 reglas de detección (src/data/rules.ts) como base sólida y verificable. Para escalar a los 51:

Agrega entradas a ONTOLOGY en src/data/ontology.ts siguiendo el mismo shape
Agrega reglas de detección correspondientes en src/data/rules.ts con sus triggers (regex)
Vincula relatedConceptIds en cada regla para que el reporte agregue el concepto correcto

Próximos pasos sugeridos

Verificar cada referencia de artículo/cláusula contra el texto oficial (BCN, DOUE, ISO)
Reemplazar el motor de regex por CheckWizard (Rust) vía llamada a proceso o API interna, si quieres el análisis semántico real que ya construiste
Agregar autenticación (API key o header secreto) al endpoint /mcp en Vercel antes de compartirlo con terceros
Sumar los 31 conceptos restantes de la ontología completa

Available Tools

4 tools

gobernador_audit_textAuditar texto de compliance de IAA

Read-onlyIdempotent

Analiza una descripción de un sistema de IA o flujo de datos y detecta posibles hallazgos de incumplimiento contra Ley 21.719 (Chile), ISO/IEC 42001:2023, y/o el EU AI Act.

Este tool NO reemplaza asesoría legal. Es un motor heurístico basado en patrones de texto que apunta a los artículos/cláusulas relevantes para investigación posterior.

Args:

content (string): descripción del sistema en español (10-20,000 caracteres)
framework (opcional): 'ley_21719' | 'iso_42001' | 'eu_ai_act'. Si se omite, evalúa contra los tres frameworks.

Returns: JSON con: { "totalFindings": number, "findings": [ { "framework": string, "reference": string, "title": string, "severity": "critical"|"high"|"medium"|"low"|"info", "matchedText": string, "guidance": string } ] }

Ejemplos de uso:

"Audita este flujo: recolectamos huella dactilar de empleados para control de asistencia" -> detecta uso de datos biométricos
"Tenemos un chatbot de atención al cliente sin aviso de que es IA" -> detecta falta de transparencia (Art. 50 EU AI Act)

No usar cuando: se necesita un informe ejecutivo completo con resumen por severidad — usar gobernador_generate_compliance_report en ese caso.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	Descripción en español del sistema, funcionalidad o flujo de datos de IA a auditar (ej. 'Chatbot que procesa datos de salud de pacientes y toma decisiones automáticas de derivación').
`framework`	No	Framework normativo a evaluar: 'ley_21719' (Chile), 'iso_42001' (gestión de IA), o 'eu_ai_act' (UE). Si se omite, se evalúan los tres.

TDQS

A4.8/5.0

Behavior4/5

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

Annotations already declare the tool as read-only and idempotent. The description adds behavioral context by explaining it is a heuristic engine based on text patterns, does not replace legal advice, and points to relevant articles/clauses. It does not contradict annotations.

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 well-structured: purpose and disclaimer first, then parameters, return format (with JSON structure), usage examples, and finally when-not-to-use. Every sentence adds value, no fluff. It is appropriately sized for the tool's complexity.

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?

Given the tool has 2 parameters and no output schema, the description provides a complete picture: explains what the tool does, how to use it (with examples), what the output looks like (JSON schema), and when to use an alternative. All relevant context is covered.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value: character limits (10-20,000), language requirement (español), explanation of the optional framework parameter with enum values, and detailed examples of usage. This goes well beyond the 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 clearly states the verb ('analiza') and resource ('descripción de un sistema de IA o flujo de datos'), specifies the compliance frameworks (Ley 21.719, ISO/IEC 42001:2023, EU AI Act), and distinguishes from sibling tools by noting that for executive reports one should use gobernador_generate_compliance_report.

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?

The description explicitly states when not to use ('No usar cuando: se necesita un informe ejecutivo completo'), provides a specific alternative tool ('usar gobernador_generate_compliance_report'), and includes a disclaimer that it does not replace legal advice. This provides clear guidance on appropriate usage context.

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

gobernador_check_data_flowVerificar flujo de datosA

Read-onlyIdempotent

Evalúa un flujo de datos descrito en texto libre, enfocándose específicamente en: transferencias internacionales, base de licitud aplicable, y necesidad de DPIA (evaluación de impacto).

Es una vista filtrada de gobernador_audit_text centrada en gobernanza de datos (Ley 21.719 principalmente), útil quiries rápidas de "¿puedo mover estos datos aquí?".

Args:

description (string): descripción del flujo de datos (origen, destino, tipo de dato, cruce de fronteras)

Returns: JSON con: { "requiresDpia": boolean, "internationalTransferDetected": boolean, "findings": [ { framework, reference, title, severity, guidance } ] }

Ejemplos de uso:

"Enviamos datos de salud de pacientes a un servidor en Europa" -> detecta transferencia internacional + dato sensible + probable DPIA
"Guardamos solo nombre y comuna de los usuarios en un servidor en Santiago" -> sin hallazgos críticos

No usar cuando: se necesita clasificar riesgo de un sistema de IA completo (usar gobernador_generate_compliance_report).

ParametersJSON Schema

Name	Required	Description	Default
`description`	Yes	Descripción del flujo de datos a evaluar: origen, destino, tipo de datos, y si cruza fronteras (ej. 'Recolectamos RUT y email de usuarios en Chile y los enviamos a un servidor en AWS us-east-1').

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: it's a 'vista filtrada' of another tool, and returns a structured JSON. No contradiction with annotations.

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 well-structured into sections: purpose, args, returns, examples, and when-not-to-use. Every sentence adds value with no redundancy. Front-loaded with the core purpose.

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

Completeness4/5

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

Given the tool has only one parameter, no output schema, and comprehensive annotations, the description covers return format and provides examples. No output schema makes the return description necessary, and it is provided adequately. Minor improvement could include more edge cases.

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% with a detailed description of the 'description' parameter. The main description reiterates the parameter's purpose but adds examples that illustrate usage. However, since schema already defines the parameter clearly, the description adds marginal semantic value beyond the 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 clearly states the tool evaluates a data flow description focusing on international transfers, legal basis, and DPIA. The title 'Verificar flujo de datos' and description distinguish it from siblings like 'gobernador_audit_text' (general audit) and 'gobernador_generate_compliance_report' (AI system compliance).

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?

Provides explicit when-to-use context ('útiles queries rápidas de "¿puedo mover estos datos aquí?"') and when-not-to-use ('No usar cuando: se necesita clasificar riesgo de un sistema de IA completo'). Names the alternative tool 'gobernador_generate_compliance_report'.

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

gobernador_generate_compliance_reportGenerar informe de compliance estructuradoA

Read-onlyIdempotent

Genera un informe ejecutivo de compliance para un sistema de IA, agregando hallazgos por severidad y framework, más los conceptos de la ontología relacionados a cada hallazgo.

Este es el tool de mayor nivel: internamente corre el mismo motor que gobernador_audit_text pero agrega resumen ejecutivo y deduplica hallazgos, pensado para entregarse como base de un informe a cliente o para revisión interna previa a lanzamiento.

Args:

system_description (string): descripción completa del sistema (mínimo 20 caracteres)
frameworks (opcional): array con 'ley_21719' | 'iso_42001' | 'eu_ai_act'. Si se omite, evalúa los tres.

Returns: JSON con: { "summary": { "totalFindings": number, "bySeverity": {...}, "byFramework": {...} }, "findings": [ {...} ], "relatedConcepts": [ { "id", "name", "description" } ], "disclaimer": string }

Ejemplos de uso:

Describir un sistema completo de scoring crediticio con datos de terceros y servidores en el extranjero -> informe con hallazgos en las 3 normativas, priorizados por severidad

No usar cuando: solo se necesita chequear un fragmento de texto puntual — usar gobernador_audit_text para eso (más rápido y granular).

ParametersJSON Schema

Name	Required	Description	Default
`frameworks`	No	Lista de frameworks a incluir en el informe. Si se omite, incluye los tres.
`system_description`	Yes	Descripción completa del sistema de IA: propósito, tipos de datos que procesa, decisiones que toma, usuarios afectados, proveedores/infraestructura involucrada.

TDQS

A4.6/5.0

Behavior4/5

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

The description explains that the tool internally runs the same engine as audit_text but adds an executive summary and deduplicates findings. It aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and provides additional context about aggregation behavior.

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 well-structured with a clear purpose, internal workings, argument details, examples, and a usage guideline. It is slightly verbose in repeating schema descriptions but overall each section adds value.

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?

The description covers all necessary aspects: purpose, differentiation from siblings, parameter details with examples, return structure (since no output schema), and usage guidelines. It provides sufficient information for an agent to select and invoke the tool correctly.

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 coverage is 100% with descriptions, and the description adds further context: system_description requires at least 20 characters and should include purpose, data types, decisions, users, etc. Frameworks are clarified with allowed values and default behavior (all three if omitted).

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 clearly states the tool generates a structured compliance report for AI systems, aggregating findings by severity and framework. It distinguishes itself from siblings by being the highest-level tool that adds executive summary and deduplicates findings.

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?

The description explicitly tells when not to use this tool (e.g., for checking a specific text fragment) and recommends gobernador_audit_text as a faster alternative. It also implies use cases like client reports or internal pre-release reviews.

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

gobernador_map_cross_frameworkMapear concepto entre frameworks normativosA

Read-onlyIdempotent

Busca un concepto de compliance en la ontología de 51 conceptos y muestra cómo se traduce entre Ley 21.719 (Chile), ISO/IEC 42001:2023, y el EU AI Act.

Útil para responder: "¿cómo se llama en el EU AI Act lo que la Ley 21.719 exige en materia de X?"

Args:

concept (string): nombre o id del concepto a buscar (búsqueda parcial, ej. "supervisión", "biométric", "menores")

Returns: JSON con: { "results": [ { "conceptId": string, "conceptName": string, "description": string, "mappings": [ { "framework": string, "frameworkLabel": string, "references": string[] } ] } ] }

Ejemplos de uso:

"¿Cómo se traduce 'supervisión humana' entre las tres normativas?" -> devuelve Art. 4 ter (21.719), Cláusula 8.3 (ISO 42001), Art. 14 (EU AI Act)
"Busca conceptos relacionados a 'menores'" -> devuelve protección de menores de edad

Error Handling:

Si no hay coincidencias, devuelve una lista vacía con sugerencia de términos alternativos.

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes	Concepto de compliance a mapear entre frameworks, en español (ej. 'supervisión humana', 'transferencia internacional', 'dpia', 'decisiones automatizadas').

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and non-mutating. The description adds valuable behavioral details: partial search capability, expected return format (JSON with mappings), and error handling (empty list with suggestions). No contradictions exist between description and 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?

The description is moderately long but well-organized with explicit sections (purpose, args, returns, examples, error handling). It is front-loaded with the core purpose and each section contributes useful information. Minor redundancy could be trimmed, but overall it is efficient.

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

Completeness4/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, the description fully explains the return JSON format with an example structure. The tool is simple (one parameter) and the description covers purpose, parameters, return, examples, and error handling. Annotations provide safety context. The description is sufficiently complete for an agent to use correctly.

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 input schema has 100% description coverage for the single required parameter 'concept', including examples and constraints. The description goes beyond the schema by explaining that searches are partial and accepts both name or ID, and provides additional usage examples, adding meaningful value.

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 clearly states the tool's purpose: searching for a compliance concept in a 51-concept ontology and showing how it translates across three frameworks (Chile's Law 21.719, ISO/IEC 42001:2023, and the EU AI Act). It uses a specific verb ('Busca') and resource, and the focus on cross-framework mapping distinguishes it from sibling tools like audit text or data flow checking.

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?

The description provides explicit usage context with example questions ('¿cómo se llama en el EU AI Act lo que la Ley 21.719 exige en materia de X?') and concrete use cases. It does not explicitly state when not to use the tool or mention alternatives, but the purpose is clear enough to guide appropriate use.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: granular text audit, focused data flow check, executive report, and cross-framework mapping. The descriptions explicitly guide when to use each, eliminating ambiguity.

Naming Consistency5/5

All tools follow a consistent 'gobernador_verb_noun' pattern (e.g., audit_text, check_data_flow), making it easy to infer functionality from names.

Tool Count5/5

With 4 tools, the server is well-scoped for AI compliance auditing, covering essential operations without unnecessary bloat.

Completeness4/5

The tool set covers core audit lifecycle: raw analysis, specific data flow checks, and report generation. However, missing direct comparison of findings across frameworks (map_cross_framework only maps concepts, not results).

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-agentcore A
com.geiant
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Legal & Compliance AI & Machine Learning Government Data
32
Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
NORMA MCP Server A
io.github.kynosure-ai
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
Legal & Compliance Security
2
Mercado Pago
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2

Related MCP Servers

hivelaw
Legal & Compliance AI & Machine Learning Monitoring
srotzin
A
license
Not graded
quality
C
maintenance
MCP server for AI compliance auditing. Scores agent outputs for hallucination liability under the EU AI Act, issues verifiable compliance stamps, and tracks audit history by agent.
Updated 4 months ago (2026-05-01 22:57 UTC)
MIT
attestix
Legal & Compliance Security
VibeTensor
A
license
Not graded
quality
B
maintenance
MCP server for compliance automation of AI agents, enabling EU AI Act compliance, verifiable credentials, and decentralized identity management with 47 tools across 9 modules.
Updated 8 days ago (2026-08-27 00:37 UTC)
17
Apache 2.0
AI Act Companion
Legal & Compliance Security
JKasteele
A
license
Not graded
quality
A
maintenance
An MCP server that provides tools for deterministic EU AI Act risk classification and documentation generation, enabling human-in-the-loop AI system assessments inside Claude Code.
Updated 5 days ago (2026-08-30 02:52 UTC)
1
MIT
agent-audit-trail
Security Legal & Compliance
dtjohnson83
A
license
Not graded
quality
C
maintenance
MCP server providing immutable audit logging, policy enforcement, and compliance reporting for AI agent workflows, enabling regulatory compliance and chain integrity verification.
Updated 8 days ago (2026-08-26 22:28 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodexPromptusIuris/Gobernador-ia-mcp-server-'

If you have feedback or need assistance with the MCP directory API, please join our Discord server