MCP server for querying Spain's BOE (official gazette) — daily summaries, consolidated legislation, document texts and topic alerts — read-only and key-free.
sumario_boe(fecha, incluir_anuncios?, filtro?) — Daily gazette summary by section and department, with id, title and HTML/PDF URLs; accepts hoy, ayer or AAAA-MM-DD; optionally includes section V notices or filters by text.
buscar_legislacion(texto, materia?, desde?, hasta?, rango?, limite, solo_vigentes?, donde?) — Search consolidated legislation, returning id, title, rank, dates, validity status and URL; filter by subject, date range, norm type or currently-in-force only.
leer_norma(id, bloque?) — Read a consolidated norm's metadata, subjects and references plus its current text; long norms return an index so you can request specific blocks (a1,a2, max 15 per call).
leer_documento(id) — Read the text of a daily-gazette provision by its BOE-A-AAAA-NNNN id, with pagination via inicio/max_caracteres — useful for newly published items not yet consolidated.
novedades(materias, dias) — What's been published in the last N days (1–31) on given topics, using built-in profiles (fiscal, laboral, mercantil, vivienda, datos) or free keywords; excludes personnel and notices by default.
Practical use cases for accounting, tax, labour and law professionals: check today's IVA or Social Security news, locate the norm in force on a matter, read a specific article in its current wording, or see what a newly published norm amends.
Limits to note: not legal advice (official boe.es text prevails), covers only BOE and the consolidated legislation it maintains (no DOUE, regional gazettes, case law or DGT rulings), consolidation may lag the daily gazette, and partly repealed norms may still show as in force.
Servidor MCP para que Claude consulte el BOE (Boletín Oficial del Estado) con la API oficial de datos abiertos de boe.es: sumarios diarios, legislación consolidada y disposiciones del diario.
Está pensado para el trabajo diario de gestorías, asesorías fiscales y laborales y despachos de abogados en España: saber qué se ha publicado hoy sobre IVA o Seguridad Social, localizar la norma vigente, leer un artículo concreto con su redacción actual o ver qué modifica una norma recién publicada.
Sin claves ni cuentas: la API del BOE es pública.
Una sola dependencia propia (httpx) además del SDK oficial de MCP.
Respetuoso con boe.es: User-Agent identificable, timeouts, reintentos suaves, pausa entre peticiones y caché opcional.
No envía tus consultas a ningún sitio que no sea boe.es.
Hecho por Proxera, empresa de inteligencia artificial de Barcelona que desarrolla e implanta agentes de IA operativos para gestorías y asesorías, despachos y otras pymes de servicios.
Built by Proxera, an artificial intelligence company from Barcelona that builds operational AI agents for accounting and advisory firms, law firms and other service SMEs.
MCP server for the Spanish Official State Gazette (BOE): daily summaries, consolidated legislation, document text and topic alerts (tax, labour, corporate, housing, data protection). Built for Spanish accounting firms, advisors and law firms. It uses the official, public BOE open data API (no API key) and is read-only.
Tools: sumario_boe, buscar_legislacion, leer_norma, leer_documento, novedades. Install and run with Python 3.11+:
claude mcp add boe -- uvx --from git+https://github.com/Proxera-Group/boe-mcp boe-mcpTool names, descriptions and the rest of this README are in Spanish, because the BOE and its users are. This is a research aid, not legal advice: the official text at boe.es prevails. MIT licensed.
Related MCP server: es-eli-mcp
Herramienta | Qué hace |
| Sumario del BOE de un día, agrupado por sección y departamento, con id, título y URLs (html/pdf). |
| Búsqueda en la legislación consolidada: id, título, rango, fechas, vigencia y URL. |
| Metadatos, materias, referencias y texto vigente de una norma consolidada. Si es larga devuelve el índice y se piden bloques ( |
| Texto de una disposición del diario por su |
| Lo publicado en los últimos N días sobre unos temas, filtrando los sumarios por palabras clave. |
Perfiles de novedades: fiscal (IVA, IRPF, tributos…), laboral (Seguridad Social, convenios…), mercantil (sociedades, concursal, registros…), vivienda (alquiler, arrendamientos, hipotecas…) y datos (protección de datos). También acepta palabras libres.
Necesitas Python 3.11 o superior. La forma más cómoda es uv, que descarga y ejecuta el servidor sin instalar nada a mano.
Se instala directamente desde GitHub. (Pronto también en PyPI como
boe-mcp-es.) El ejecutable se llamaboe-mcp.
claude mcp add boe -- uvx --from git+https://github.com/Proxera-Group/boe-mcp boe-mcpDescarga boe-mcp.mcpb de la última release y ábrelo con Claude Desktop (o arrástralo a Ajustes → Extensiones). Necesita uv instalado; el resto lo gestiona Claude Desktop.
Edita claude_desktop_config.json (Ajustes → Desarrollador → Editar configuración) y añade:
{
"mcpServers": {
"boe": {
"command": "uvx",
"args": ["--from", "git+https://github.com/Proxera-Group/boe-mcp", "boe-mcp"]
}
}
}Reinicia Claude Desktop. Si prefieres pip:
pip install git+https://github.com/Proxera-Group/boe-mcpy usa "command": "boe-mcp" (sin args) en la configuración.
export BOE_MCP_CACHE_DIR=~/.cache/boe-mcpEn Claude Desktop se añade con "env": { "BOE_MCP_CACHE_DIR": "/ruta/a/la/cache" }. Guarda sumarios pasados, normas y búsquedas durante un tiempo corto (el sumario de hoy, 10 minutos). Sin la variable no se cachea nada.
«¿Qué ha salido hoy en el BOE sobre IVA?» → sumario_boe / novedades(["fiscal"], 1).
«Resume los cambios del Real Decreto-ley 27/2026 en arrendamientos.» → buscar_legislacion + leer_norma: ve qué artículos de la LAU modifica y su redacción.
«¿Cuál es la redacción actual del artículo 10 de la Ley de Arrendamientos Urbanos y entra algún cambio en vigor próximamente?» → leer_norma(id, bloque="a10") distingue la versión vigente hoy de la que entra en vigor más adelante.
«Dame las novedades laborales y de Seguridad Social de las últimas dos semanas.» → novedades(["laboral"], 14).
«¿Qué normas regulan la protección de datos y siguen vigentes?» → buscar_legislacion(texto="protección de datos", solo_vigentes=true).
Pide siempre que cite el identificador BOE (BOE-A-2026-20385) y el enlace: así puedes comprobar la fuente en segundos.
Para normas largas (la LIVA tiene más de 300 bloques) Claude lee el índice y luego solo los artículos que necesita.
novedades filtra por palabras clave en el título: sirve para vigilar, no para garantizar que no se escapa nada.
No es asesoramiento jurídico ni fiscal. Es una herramienta de consulta. La fuente oficial manda: contrasta siempre con el texto en boe.es antes de actuar o de asesorar a un cliente.
Claude puede resumir o interpretar mal un texto legal. Revisa lo importante contra el original.
Cubre lo que ofrece la API del BOE: el BOE y la legislación consolidada que el BOE mantiene (incluye parte de la normativa autonómica publicada en el BOE). No incluye DOUE, boletines autonómicos propios, jurisprudencia ni doctrina administrativa (consultas de la DGT, etc.).
La legislación consolidada puede ir por detrás del diario: una norma publicada hoy puede tardar en consolidarse. Para lo recién publicado, usa leer_documento.
El campo «vigencia» es el que declara el BOE (vigente / vigencia agotada / derogada). Las normas derogadas solo en parte figuran como vigentes: lee siempre la norma y sus referencias.
Los domingos no se publica BOE; el sumario del día suele estar disponible a primera hora.
Un texto consolidado puede contener modificaciones publicadas que aún no han entrado en vigor; el servidor devuelve la versión vigente a fecha de hoy y avisa de la siguiente, pero comprueba las fechas.
Los anuncios (sección V) y el personal (sección II) se omiten por defecto en sumarios y novedades por volumen.
Se hace una petición cada ≥0,4 s como máximo y pedir muchos días en novedades tarda unos segundos. Sé amable con el servicio.
git clone <este repositorio> && cd boe-mcp
uv venv && uv pip install -e ".[dev]"
.venv/bin/pytest # no usa red: respuestas reales grabadas en tests/fixtures/Los tests usan respuestas reales de boe.es guardadas en tests/fixtures/ y fallan si intentan abrir un socket.
Los datos proceden de la API de datos abiertos del BOE y están sujetos a su aviso legal. Este proyecto no está afiliado a la Agencia Estatal Boletín Oficial del Estado.
Código bajo licencia MIT © Proxera AI Solutions Group S.L.
Hecho por Proxera (proxera.es) — IA para gestorías y despachos. Equipo: Robert Graf (CEO, @robertgraf-dotcom) y Miller Espinosa (CTO, @milleresp).
Busca en la legislación consolidada (título y texto). Devuelve id, título, rango, fechas, vigencia y URL.
texto: palabras que deben aparecer (todas). materia: tema del vocabulario del BOE, p. ej. 'Arrendamientos urbanos' o 'Impuesto sobre Sociedades'. desde/hasta: fecha de publicación (AAAA-MM-DD). rango: Ley, Ley Orgánica, Real Decreto, Real Decreto-ley, Orden, Resolución… limite: 1-50. Por defecto ordena por relevancia. donde: 'auto' (título y, si no hay resultados, texto completo), 'titulo', 'texto' o 'ambos'.
| Name | Required | Description | Default |
|---|---|---|---|
| desde | No | ||
| donde | No | auto | |
| hasta | No | ||
| rango | No | ||
| texto | No | ||
| limite | No | ||
| materia | No | ||
| solo_vigentes | No | ||
| ordenar_por_fecha | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return fields and the 'auto' fallback behavior (search title, then full text if no results), but says nothing about read-only safety, pagination, rate limits, or permissions for a 9-parameter search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and return fields, then moves efficiently through parameters in a compact block. No wasted sentences, though the parameter prose could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be re-explained, and most parameters are covered, but the two undocumented boolean filters (solo_vigentes, ordenar_por_fecha) leave a real gap given zero schema coverage and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it does for 7 of 9 parameters: texto, materia, desde/hasta formats, rango examples, limite range, and donde modes are all explained. Only solo_vigentes and ordenar_por_fecha are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Busca en la legislación consolidada') and clarifies the search surface (título y texto), so an agent knows exactly what it does. However, it never distinguishes itself from siblings like novedades or sumario_boe, which also relate to BOE legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives such as sumario_boe or novedades, nor any exclusions. Usage can only be inferred from the parameter list and the note that relevance ordering is the default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texto de una disposición publicada en el diario por su id (BOE-A-AAAA-NNNN), con materias y referencias.
Útil para lo recién publicado (que quizá aún no esté consolidado). Para textos largos use
inicio (desplazamiento en caracteres) para paginar.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| inicio | No | ||
| max_caracteres | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior and the returned content (text, subjects, references), but does not mention permissions, auth needs, rate limits, or other operational traits beyond the obvious read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose and followed by a focused pagination tip. No unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with an output schema, the description covers content, id format, recency use, and pagination. The omission of `max_caracteres` is a minor gap, but the rest is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains the `id` format (BOE-A-AAAA-NNNN) and `inicio` as a character offset for pagination, but omits `max_caracteres` entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: returns the text of a provision published in the official gazette by its BOE id, including subjects and references. The sibling `leer_norma` is not named or contrasted, so the agent must infer the distinction from the recency hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is useful for recently published texts that may not yet be consolidated, and explains that long texts should be paginated with `inicio`. It does not name `leer_norma` or other alternatives as when-not alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee una norma consolidada por su id (BOE-A-AAAA-NNNN): metadatos, materias, referencias e índice.
Si la norma es corta devuelve el texto vigente completo; si es larga devuelve solo el índice
y hay que pedir bloques concretos con bloque (ids separados por comas, p. ej. 'a1,a2';
máx. 15 por llamada). Del texto se da la versión vigente de cada bloque.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| bloque | No | ||
| max_caracteres | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose meaningful behavior: short norms return full text, long norms return only the index, blocks are capped at 15 per call, and returned text is the vigente version. It omits permission/auth needs, error behavior, and what `max_caracteres` does, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and id format, then the branch logic, then the block syntax. Every sentence carries information and nothing is repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with an output schema, the description is largely complete: it covers the id format, the short/long return branching, and the block request pattern. The one undocumented parameter (`max_caracteres`) and the absence of sibling routing leave a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does for two of three params: `id` gets an explicit format and `bloque` gets comma-separated syntax plus a 15-item cap. `max_caracteres` (default 30000) is left completely unexplained, which is the remaining gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource (lee una norma consolidada por su id) with the id format (BOE-A-AAAA-NNNN) and the returned payload enumerated (metadatos, materias, referencias, índice). It does not explicitly distinguish itself from the close sibling leer_documento, so it stops just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implicitly tells the agent when to add `bloque` (short vs long norms), which is real usage guidance for the second call. However, it never states when to use this tool versus buscar_legislacion or leer_documento, nor any preconditions, so guidance is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lo publicado en el BOE en los últimos N días que toca unos temas, filtrando los sumarios por palabras clave.
materias: perfiles 'fiscal' (IVA, IRPF, tributos), 'laboral' (Seguridad Social, convenios), 'mercantil' (sociedades, concursal), 'vivienda' (alquiler, arrendamientos) y 'datos' (protección de datos), o palabras libres. dias: 1-31. Excluye por defecto la sección II (nombramientos, oposiciones) y la V (anuncios).
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | ||
| limite | No | ||
| materias | Yes | ||
| incluir_anuncios | No | ||
| incluir_personal | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses useful behavior: default exclusion of sections II and V, and a 1–31 day range. However, it does not explicitly state that this is a read-only query, nor does it mention authentication, rate limits, or result format (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose in the first sentence, then provides parameter details and defaults. The second paragraph is dense but well-structured, with every sentence adding relevant information. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the description adequately explains the required parameter and date range. However, with 5 parameters and 0% schema coverage, the omission of 'limite' makes the definition incomplete for full parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It explains 'materias' (profiles or free words) and 'dias' (1–31), and indirectly covers the default values for 'incluir_anuncios' and 'incluir_personal' via the exclusion statement. But it never mentions 'limite', leaving one of five parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action: retrieving recent BOE publications within a day range, filtered by topics/keywords. The resource (BOE) and verb (lo publicado / filtrando) are clear. However, it does not explicitly differentiate from sibling tools like sumario_boe, which likely also retrieves BOE summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by defining 'materias' profiles and a 'dias' range, and notes default exclusions. It does not state when to use this tool versus alternatives such as sumario_boe or buscar_legislacion, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sumario del BOE de un día, agrupado por sección y departamento (id, título, URLs html/pdf).
fecha: AAAA-MM-DD, 'hoy' o 'ayer'. Los domingos no hay BOE. incluir_anuncios: la sección V (contratación, anuncios) se omite por defecto por volumen. filtro: texto opcional (sin distinguir tildes) para quedarse solo con lo que lo contenga.
| Name | Required | Description | Default |
|---|---|---|---|
| fecha | No | hoy | |
| filtro | No | ||
| incluir_anuncios | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses grouping, default omission of section V due to volume, the Sunday no-BOE rule, and accent-insensitive filtering. It does not explicitly state read-only behavior or auth/rate-limit characteristics, but the summary nature strongly implies a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then gives one compact line per parameter and edge case. Every sentence is useful and nothing is repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with an output schema and no annotations, the description covers purpose, parameter formats, defaults, and important edge cases. It is nearly complete, missing only explicit routing against sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully documents all three parameters: fecha accepts AAAA-MM-DD, 'hoy', or 'ayer' with a Sunday caveat; incluir_anuncios defaults to false and controls section V; filtro is optional and accent-insensitive. This adds substantial meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and operation: daily BOE summary grouped by section and department, with output fields. It is clear what the tool returns, but it does not explicitly differentiate itself from siblings like buscar_legislacion or novedades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Sumario del BOE de un día' and notes that Sundays have no BOE, but it does not state when to choose this tool over sibling tools such as buscar_legislacion or novedades. Usage is inferable but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0buscar_legislacionleer_documentoleer_normanovedadessumario_boeScored across 5 tools
Los roles generales están bien separados: buscar_legislacion busca, leer_norma lee legislación consolidada y leer_documento lee disposiciones del diario. Sin embargo, sumario_boe y novedades pueden solaparse al recuperar publicaciones recientes, aunque la distinción diaria vs. agregada por temas ayuda.
Todos los nombres usan snake_case en minúsculas y son legibles, pero mezclan dos patrones: verbos + objeto (buscar_legislacion, leer_norma, leer_documento) y sustantivos solos (sumario_boe, novedades). La falta de un patrón verbal uniforme es una desviación menor.
Cinco herramientas están bien ajustadas para una API de solo lectura del BOE. Cada una cubre una capa distinta (resumen diario, búsqueda, lectura consolidada, lectura de diario, novedades) sin herramientas redundantes ni superficiales.
El conjunto cubre descubrimiento y lectura de legislación consolidada y publicaciones diarias, además de novedades temáticas. Falta una búsqueda directa sobre documentos del diario más allá del filtro de sumario o novedades, pero es un hueco menor para el caso de uso principal.
BOE, Spanish public tenders and INE statistics behind one MCP server.
TED MCP Server: Real-time EU public tenders access. https://www.lexsocket.ai/
Eurlex MCP client: Access EU law & Official Journal. https://www.lexsocket.ai/
The first fiscal MCP server for Spain: IAE/CNAE 2025, AEAT modelos, IRPF/IVA, RETA quota.
