This server provides forensic-level tools to search, retrieve, cite, and analyze Chilean legislation in real time. Capabilities include:
Search and discovery: Search norms by keyword or matter (leychile_buscar_normas), list recent norms (leychile_normas_recientes), and browse thematic categories (leychile_listar_categorias, leychile_listar_normas_categoria).
Retrieve full texts and structure: Get consolidated text of any norm by ID or law number (leychile_obtener_norma), retrieve historical versions (leychile_obtener_version), view systematic indexes (leychile_indice_sistematico) or complete article list with version dates (leychile_listar_articulos).
Forensic article and fragment extraction: Fetch specific articles including suffixed numbers (e.g., 183-B) with citation (leychile_obtener_articulo), extract exact inciso/numeral/letra fragments within an article (leychile_obtener_fragmento).
Temporal control: Trace an article's modification timeline (leychile_linea_tiempo_articulo), get text as of a specific date with procedural ultra-activity alerts (leychile_texto_vigente_a_fecha), compare versions within a date range (leychile_comparar_versiones) or compare multiple articles across norms (leychile_comparar_articulos).
Special parts: Isolate transitory articles (leychile_listar_transitorios), list modifications (leychile_listar_modificaciones), extract statutory definitions (leychile_extraer_definiciones), and retrieve annexes (leychile_obtener_anexos).
Metadata and validity: Check metadata, validity status, legal vacancy, and version count (leychile_obtener_metadatos).
Citation and cross-referencing: Resolve free-text citations to exact text (leychile_citar), search within a norm (leychile_buscar_en_norma), extract concordances and remissions from an article (leychile_concordancias_articulo), and resolve laws by popular name (leychile_resolver_ley_por_nombre).
Legal knowledge layer: Resolve codes by name (leychile_resolver_codigo), list all codes (leychile_listar_codigos), suggest special laws for a topic with validity checks (leychile_sugerir_normas_especiales), and map substantive rights to procedural remedies (leychile_mapa_procesal).
History and additional data: Get links to legislative history (leychile_historia_ley).
Output flexibility: All tools accept response_format = markdown, json, or compact.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LeyChile MCP find the current text of Law 19.300"
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.
Servidor MCP (Model Context Protocol) que conecta a Claude — u otra IA compatible — en vivo y directamente con Ley Chile, el sistema de legislación de la Biblioteca del Congreso Nacional de Chile (BCN).
Convierte el ordenamiento jurídico chileno en herramientas de nivel forense, pensadas para el estudio y la práctica de estudiantes de Derecho, abogados litigantes y jueces: buscar normas, leer el texto vigente, citar con precisión incisos/numerales/letras, controlar la vigencia intertemporal, comparar versiones, aislar transitorios, mapear especialidad y vías procesales, y razonar con prompts jurídicos guiados.
⚠️ Herramienta no oficial, sin afiliación con la BCN. Los textos provienen de Ley Chile. No constituye asesoría jurídica: verifique siempre contra la fuente oficial. Es una ayuda metodológica; el criterio jurídico es del profesional.
A diferencia de un volcado estático y parcial, LeyChile MCP consulta a BCN en cada llamada, por lo que entrega la versión consolidada y vigente de cada norma, con cobertura completa del ordenamiento (leyes, decretos, DFL, códigos, resoluciones). Está en español, con citas verificables y enlace oficial.
Related MCP server: lawyer-mcp
La API de BCN entrega datos, no juicios jurídicos. Para no “alucinar derecho”, el servidor separa:
Capa | Qué es | Fuente de verdad |
A — Datos | Recuperación y parsing determinista del XML de BCN |
|
B — Conocimiento | Catálogos curados y verificados (códigos, especialidad, reenvíos procesales) | Tablas mantenidas + verificación de vigencia en vivo |
C — Razonamiento | Prompts que guían el análisis usando A+B | El modelo, citando A/B |
Así, los datos los aporta BCN; el método lo aportan los prompts; y toda conclusión queda anclada a normas citadas.
🔎 Búsqueda por palabra clave o materia que rankea el cuerpo legal (Ley/Código) sobre modificaciones y actos administrativos, con filtros por tipo, año y excluir_modificaciones.
📄 Texto consolidado y vigente de cualquier norma (por idNorma o N° de ley).
🧷 Segmentación forense: extrae el inciso, numeral o letra exactos (p. ej. “art. 254 inciso segundo del CPC”, “art. 434 N° 4”).
🔤 Artículos con sufijo: 183-A…183-E CT, 27A LSA, 145 bis E, 157 TER, 4 bis. La cita forense usa guion y LeyChile nombra con espacio: ambas formas resuelven al mismo artículo. Y un artículo con sufijo nunca resuelve al base — antes 183-B devolvía el 183 con la cita «Art. 183», que en una herramienta anti-alucinación es el peor modo de fallo posible.
🕰️ Vigencia intertemporal: cómo estaba redactado un artículo a una fecha dada, versión histórica exacta (idVersion), línea de tiempo y comparación de versiones.
⚖️ Alerta de ultraactividad procesal: avisa cuando, en normas adjetivas, los plazos o actuaciones ya iniciados podrían regirse por la ley antigua.
📘 Texto refundido e instrumento fijador; vacancia legal (publicada pero no vigente).
🧩 Transitorios, definiciones legales y anexos (p. ej. sentencias del Tribunal Constitucional) aislados.
🔗 Modificaciones desde notas marginales e Historia de la Ley con las leyes modificatorias.
🗂️ Índice sistemático anti-desborde para códigos extensos y categorías temáticas de BCN.
🧠 Capa de conocimiento: resolución de códigos por nombre, mapa de especialidad (arts. 4° y 13 CC) y reenvíos sustantivo↔adjetivo con verificación de vigencia de la vía procesal.
⚙️ Razonamiento jurídico ejecutable (PYTHEN, determinista): reglas derrotables exception-first (leychile_razonar, leychile_evaluar_regla) y cascada de antinomías lex superior › specialis › posterior (leychile_resolver_antinomia).
🪶 Modo compacto (response_format=compacto): salidas mínimas que ahorran ~50 % de tokens al explorar.
🌐 Entrar al BCN (opcional, DrissionPage/Chrome): renderiza páginas JavaScript que la API no expone —Historia de la Ley, jurisprudencia— con leychile_bcn_extraer.
💬 6 prompts jurídicos: antinomías, ratio legis, derogación orgánica, vigencia intertemporal, minuta de alegato y mapa normativo del caso.
📌 Citas en texto libre: pega «art. 1698 inc. 1° del Código Civil» y obtén el texto exacto (leychile_citar).
🔦 Buscar dentro de una norma (leychile_buscar_en_norma) y concordancias/remisiones de un artículo (leychile_concordancias_articulo).
🏷️ Leyes por nombre popular: «Ley Karin», «Ley Emilia», etc. (leychile_resolver_ley_por_nombre).
🛡️ Resiliencia: User-Agent de navegador (anti-403), failover de hosts BCN, caché diaria, reintentos, plegado de acentos.
🔌 Transporte stdio (local) y streamable-HTTP (servicio).
Requisitos: Python 3.10+.
git clone https://github.com/IanGuiloff/leychile-mcp.git
cd leychile-mcp
pip install -e .Esto deja disponible el comando leychile-mcp.
Edita el archivo de configuración (%APPDATA%\Claude\claude_desktop_config.json en Windows; ~/Library/Application Support/Claude/claude_desktop_config.json en macOS) y agrega:
{
"mcpServers": {
"leychile": { "command": "leychile-mcp" }
}
}Reinicia Claude Desktop: aparecerán las herramientas leychile_*. (Ver examples/claude_desktop_config.json para la variante sin instalar.)
claude mcp add leychile -- leychile-mcpleychile-mcp --transport http --host 0.0.0.0 --port 8000 # endpoint: http://host:8000/mcp
# o con Docker:
docker build -t leychile-mcp . && docker run -p 8000:8000 leychile-mcp“Tráeme el inciso segundo del artículo 254 del Código de Procedimiento Civil.”
“Resuelve la cita: art. 19 N° 12 de la Constitución.”
“Busca ‘fuero maternal’ dentro del Código del Trabajo.”
“¿A qué artículos y leyes remite el art. 23 de la Ley 19.628?”
“¿Qué ley es la ‘Ley Karin’?”
“¿Cómo estaba redactado el artículo 17 de la Ley 19.628 el 1 de enero de 2005?”
“Compara el artículo 17 de la Ley 19.628 entre 2010 y hoy.”
“Dame los artículos transitorios del Código del Trabajo.”
“¿Qué leyes especiales priman en materia de consumo? ¿Siguen vigentes?”
“¿Cuál es la vía procesal para una acción reivindicatoria?”
“Arma una minuta de alegato sobre término de contrato de arrendamiento urbano.”
34 herramientas (búsqueda con ranking, texto, fragmentos anidados, vigencia/vacancia, versiones, transitorios, modificaciones, definiciones, anexos, categorías, códigos, especialidad, vía procesal, Historia de la Ley, razonamiento jurídico ejecutable y navegador BCN) y 6 prompts jurídicos. Referencia completa en docs/HERRAMIENTAS.md.
Todas las herramientas aceptan response_format = markdown (por defecto), json o compacto (markdown mínimo, ~50 % menos tokens). Las de texto aceptan formato_texto = limpio (quita notas marginales) u original.
Usa el servicio abierto obtxml de Ley Chile:
Búsqueda: obtxml?opt=61&cadena=…&cantidad=…
Norma consolidada: obtxml?opt=7&idNorma=… (&idVersion=YYYY-MM-DD para texto histórico exacto)
Recientes: opt=3 · Categorías: opt=30 · Normas por categoría: opt=6
El XML se parsea preservando la jerarquía oficial (Libros/Títulos/Capítulos/Párrafos/Artículos) y la fecha de versión por artículo, base del control intertemporal.
Documentación de la fuente: Servicios web de Ley Chile · Esquema XML
pip install -e ".[dev]"
pytest -qEstructura del paquete: client.py (HTTP), parser.py (XML y numeración de artículos), citas.py (citas en texto libre), segmenter.py (incisos/numerales/letras), timeline.py (vigencia intertemporal), catalog.py (capa B), prompts.py (capa C), razonamiento/ (PYTHEN: reglas derrotables y antinomías), browser.py (navegador BCN, opcional), formatting.py (salida + citas), service.py (orquestación), server.py (FastMCP).
El vocabulario de sufijos de artículo (
SUFIJOS_LATINOS,SUFIJO_LETRA) vive enparser.pyy lo importacitas.py: los dos módulos deben coincidir, y tenerlo duplicado fue justamente el origen del defecto que hacía resolver183-Bal artículo 183.
Depende de la disponibilidad del servicio de BCN (con reintentos, failover y caché).
numero_ley resuelve leyes; para otros tipos use id_norma o búsqueda.
La línea de tiempo se deriva del historial observable del texto vigente; para precisión absoluta a una fecha, contraste con la versión oficial.
leychile_historia_ley entrega enlaces a la tramitación (no descarga los PDF).
Las capas B y C son apoyo metodológico curado, no dictan derecho.
Datos: servicio público Ley Chile de la Biblioteca del Congreso Nacional de Chile (BCN). Proyecto creado y mantenido por Ian Guiloff.
MIT © 2026 Ian Guiloff.
Busca una palabra o frase dentro del articulado de una norma y devuelve los artículos.
Ideal para localizar dónde un código regula un tema (p. ej. 'fuero maternal' en el Código del Trabajo) sin descargar todo el cuerpo legal.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it searches within articles and returns them, but does not disclose any additional behavioral traits beyond what annotations already imply. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. The first sentence defines the action and output, and the second provides an example use case. There is no unnecessary information; every word contributes to understanding.
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?
Given the tool has an output schema (though not shown), the description appropriately focuses on input and purpose. It explains the search scope, output type, and typical usage. The schema covers required parameters, so the description is complete for an agent to understand when and how to use it.
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?
The input schema includes detailed descriptions for each parameter (e.g., 'termino', 'id_norma', 'numero_ley', 'max_resultados', 'response_format'), providing full semantic coverage. The tool description does not add parameter-specific information beyond the schema, so it meets the baseline for high schema coverage.
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?
The description clearly states the action ('busca una palabra o frase dentro del articulado'), the resource ('norma'), and the output ('devuelve los artículos'). It includes a concrete example ('fuero maternal' en el Código del Trabajo) that differentiates it from sibling tools like leychile_buscar_normas (which searches among norms) by focusing on searching within a specific norm's text.
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 provides a clear use case ('ideal para localizar dónde un código regula un tema') and a benefit ('sin descargar todo el cuerpo legal'). It implies the tool is for targeted searches within a known norm. However, it does not explicitly state when not to use it or mention alternatives among siblings, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca leyes, decretos, DFL, códigos y demás normas por palabra clave o materia.
Punto de partida para localizar el idNorma. Cobertura completa y vigente.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context: that it is a starting point for finding idNorma and that coverage is complete and current. No contradictions exist.
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 sentences with zero waste. The first sentence states the action and scope, the second provides strategic usage context. Highly efficient.
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?
Given that an output schema exists (not shown but indicated), the description doesn't need to detail return values. It covers essential purpose and usage context. Could briefly mention output is a list of norms, but not required. Complete enough for a search tool.
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?
The input schema itself provides detailed descriptions for all parameters (tipo, cantidad, consulta, response_format). Since the schema already documents parameters adequately, the description adds no additional meaning. Baseline of 3 is appropriate.
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?
The description clearly states the verb 'Busca' and the resource 'normas' (laws, decrees, codes), and explicitly frames it as a starting point to locate 'idNorma'. This distinguishes it from sibling tools like 'leychile_buscar_en_norma' which likely searches within a specific norm.
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 frames this tool as the 'punto de partida' (starting point) to locate an 'idNorma', implying it is the first step before using other tools. It also mentions 'Cobertura completa y vigente' (complete and current coverage). However, it does not explicitly state when not to use it or list alternative search tools, though 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.
Interpreta una cita legal en texto libre y devuelve el texto EXACTO citado.
Acepta 'art. 1698 inciso 1° del Código Civil', 'art. 19 N° 12 de la Constitución', 'art. 161 del Código del Trabajo', 'art. 4 de la Ley 19.628', etc. Devuelve el inciso/numeral/letra pedido (o el artículo completo) con su cita forense.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true and destructiveHint=false, which the description does not contradict. The description adds that it returns the exact text with a forensic citation, but no unique behavioral disclosures beyond what annotations already provide.
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 sentences: first defines the core purpose, second provides examples and output details. No extraneous words, efficiently communicates key information.
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?
Given the presence of an output schema and only one required parameter, the description sufficiently covers the tool's functionality. It mentions the exact text and forensic citation, which complements the schema.
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?
The 'cita' parameter has a detailed description in the schema with examples. The tool description adds information about the return value (inciso/numeral/letra or full article with forensic citation), providing context beyond the schema.
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?
The description clearly states the tool interprets a free-text legal citation and returns the exact text cited, with concrete examples. It distinguishes itself from sibling tools like leychile_buscar_normas which are for searching, not resolving citations.
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?
While the description gives examples of valid inputs, it does not explicitly state when to use this tool versus alternatives like leychile_buscar_en_norma. There is no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recupera 2 a 6 artículos (de una o varias normas) para análisis comparado.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so description does not need to repeat that. However, description adds no behavioral context beyond the basic retrieval purpose. No contradictions.
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?
Single sentence, no fluff, front-loaded with purpose. Very concise.
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?
Tool has a complex input schema with nested objects and enums, and an output schema exists but is not described. Description fails to explain input structure or return format, leaving the agent with insufficient information to invoke it correctly.
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 has 0% description coverage, and the tool description does not explain the parameters (referencias, formato_texto, response_format). The description only mentions the count of articles but not how to specify them. Lacks necessary parameter guidance.
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?
Description clearly states it retrieves 2-6 articles from one or more norms for comparative analysis. Distinguishes from siblings like leychile_comparar_versiones and leychile_obtener_articulo.
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?
No guidance on when to use this tool versus alternatives like leychile_comparar_versiones or leychile_obtener_articulo. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compara la redacción de un artículo entre dos versiones (fechas exactas de versión).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds no additional behavioral context such as error handling, data limits, or what happens if version dates are invalid.
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 a single sentence front-loaded with the main action, no wasted words. It is concise but lacks detail.
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?
Given the tool's complexity with 7 nested parameters and many siblings, the description is too brief. It does not explain how to use optional parameters like id_norma, numero_ley, or transitorio, nor the output format (though output schema exists).
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% at the top level, and the tool description does not add any parameter meaning. Although nested parameters have descriptions, the tool description itself fails to compensate for the low coverage.
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?
The description clearly states the tool compares the wording of an article between two versions with exact dates, using specific verb and resource. It is distinct from sibling tools like leychile_comparar_articulos (which compares different articles) and leychile_obtener_version (which retrieves a single version).
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 provides no guidance on when to use this tool versus alternatives. Given the large number of sibling tools, some indication of context or exclusion criteria is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrae las remisiones de un artículo: a qué otros artículos, leyes, códigos y decretos cita.
Útil para mapear la red normativa de un precepto (interpretación sistemática).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it extracts references, which is useful context but does not reveal behavioral traits beyond the annotations. No contradiction.
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 extremely concise with two sentences. The first sentence states the action, and the second adds the purpose. No wasted words, front-loaded, and easy to parse.
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?
Given the tool has an output schema, the description does not need to explain return values. The description covers the essential action and use case. It is complete for a tool of moderate complexity, though it could briefly mention optional parameters like transitorio.
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?
The description does not add any parameter semantics beyond the input schema. The schema itself provides descriptions for most parameters (e.g., articulo, id_norma, numero_ley), so the description's lack of parameter detail is acceptable but does not enhance understanding.
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?
The description clearly states the tool extracts references (remisiones) from an article to other articles, laws, codes, and decrees. It distinguishes from sibling tools like leychile_obtener_articulo (which gets article content) and leychile_buscar_en_norma (search within a norm), making the purpose specific and clear.
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 for mapping the normative network of a precept (systematic interpretation). It provides a clear context but does not explicitly state when not to use or mention alternatives. However, the sibling list and purpose clarity compensate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrae las definiciones legales ('para los efectos de esta ley se entenderá por…').
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive traits. Description adds no further behavioral context beyond stating the extraction action.
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?
Single, front-loaded sentence that efficiently conveys the tool's purpose with zero waste.
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?
Despite an output schema and adequate annotations, the description lacks completeness on input requirements and output specifics, relying on the agent to infer from sibling names.
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%. Description provides no details on parameters like id_norma, numero_ley, or response_format, leaving the agent uninformed.
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?
The description clearly states the verb (extrae) and resource (definiciones legales), distinguishing it from siblings like leychile_obtener_articulo.
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?
No guidance on when to use this tool vs alternatives; lacks when-not or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enlaces oficiales a la Historia de la Ley, asociando las leyes modificatorias detectadas.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so safety is clear. The description adds context about 'official links' and 'associating modifying laws', which provides minor behavioral insight beyond annotations.
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 a single sentence, very concise. However, it could be more informative without being verbose. Still, it is well-structured and front-loaded.
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?
Given the tool has an output schema and simple parameters, the description covers the main idea but misses explaining the key parameter options. It is adequate but not complete.
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 does not mention parameters or how to specify the law (by id_norma or numero_ley), adding no value beyond the schema's property descriptions.
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?
The description mentions 'Historia de la Ley' and 'asociando las leyes modificatorias', giving a sense of purpose but lacks an explicit verb like 'retrieve' or 'get'. It is somewhat clear but could be more actionable.
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?
No guidance on when to use this tool versus siblings like leychile_obtener_norma or leychile_listar_modificaciones. The description only states what it does, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Índice de agrupadores (Libros/Títulos/Capítulos/Párrafos), sin artículos.
Ideal para navegar códigos extensos sin descargar todo el texto.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: it only returns hierarchical groupings without articles, which is a key behavioral trait not covered by annotations. This helps the agent understand the tool's output scope.
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 extremely concise with two sentences that front-load the core purpose. Every word adds value; there is no fluff or redundancy. It efficiently conveys the tool's essence.
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?
Despite having an output schema, the description lacks essential context about how to specify which code to query via parameters. Without mentioning that id_norma or numero_ley is needed, the description is insufficient for an agent to correctly invoke the tool. The purpose is clear, but invocation details are missing.
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?
The description does not mention any parameters. Although the input schema has descriptions for fields like id_norma and numero_ley, the tool description fails to add meaning beyond the schema. With schema description coverage at 0%, the description should compensate but does not, leaving parameter usage ambiguous.
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?
The description clearly states the tool returns an index of groupings (Libros/Títulos/Capítulos/Párrafos) without articles, specifying the resource (sistematic index) and verb (listar/obtener). It distinguishes from sibling tools that return articles or full norms, though it does not explicitly name alternatives.
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 suggests using the tool for navigating lengthy codes without downloading full text, implying a usage context. However, it provides no explicit guidance on when not to use it or comparisons to alternatives, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trayectoria temporal de un artículo: última modificación, versiones y leyes modificatorias.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 safety profile is clear. The description adds the specific output contents (last modification, versions, amending laws) which is helpful but not extensive. No additional behavioral traits like pagination, performance, or edge cases are disclosed.
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 a single, concise sentence that efficiently communicates the tool's purpose. It is front-loaded with key terms ('trayectoria temporal'). However, it could be slightly more structured by explicitly stating the verb (e.g., 'obtiene' or 'muestra').
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?
Given the tool has an output schema, the description need not explain return values. The description adequately explains the general function. However, it lacks completeness regarding parameter usage and how to specify the article (e.g., required articulo field is not mentioned). The sibling list is large, so more contextualization would help.
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?
The tool description does not mention any parameters, and the schema description coverage is 0% (the description itself adds no param info). Although the input schema includes descriptions for each parameter, the tool description should at least hint at what is required (e.g., 'article number') to guide selection. With 5 parameters (including optional ones), the description falls short.
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?
The description 'Trayectoria temporal de un artículo: última modificación, versiones y leyes modificatorias' clearly states the tool provides the timeline of an article, including latest modification, versions, and amending laws. It distinguishes from siblings like leychile_comparar_articulos (compare articles) and leychile_obtener_articulo (get article). However, the verb is implicit rather than explicit, so not a perfect 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?
The description provides no guidance on when to use this tool versus alternatives (e.g., leychile_historia_ley, leychile_comparar_versiones). There are no prerequisites, exclusions, or usage contexts mentioned. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Índice jerárquico completo (incluye artículos) con fecha de versión por parte.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating safe read-only behavior. The description adds that it returns a hierarchical index with version dates, which is useful context but does not contravene annotations.
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 a single sentence with no extraneous information. It is concise but could benefit from front-loading key details in a more structured way.
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?
Given the tool's complexity (nested parameters, available output schema) and rich sibling set, the description is too sparse. It does not explain return format, pagination, or how to interpret the hierarchical index, leaving the agent underinformed.
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?
The description does not mention any parameters or their semantics. Despite 0% schema description coverage, the description fails to compensate by explaining the 'params' object or its fields (id_norma, numero_ley, etc.), which are only documented in the schema.
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?
The description clearly states the tool returns a complete hierarchical index including articles with version dates. It is a specific verb+resource, distinguishing it from siblings that focus on searching, comparing, or retrieving single articles.
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?
No guidance is provided on when to use this tool versus alternatives like leychile_texto_vigente_a_fecha or leychile_obtener_articulo. The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las colecciones temáticas curadas por BCN (códigos, leyes frecuentes, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, so the description need not repeat safety. It adds context about the content (codes, frequent laws), but does not disclose output format or pagination behavior. This is adequate but not rich.
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?
One sentence with 12 words, very concise. However, it omits parameter information that could be included without bloating. Efficient but slightly under-informative.
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 are likely covered. However, the description does not address the input parameter (response_format), creating a gap for proper invocation. Complete for simple listing but missing parameter context.
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 does not mention the 'params' argument or the 'response_format' enum, leaving the agent unaware of the ability to choose markdown or JSON output.
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?
The description clearly states the tool lists thematic collections curated by BCN, with examples like codes and frequent laws. It uses a specific verb ('list') and resource ('collections'), and distinguishes from siblings like leychile_listar_codigos and leychile_listar_normas_categoria.
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?
No guidance on when to use this tool versus alternatives. With many listing siblings, explicit context or exclusions are missing, making it hard for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los códigos de la República con su idNorma (verificado) para acceso directo.
Los marcados sin idNorma se resuelven con leychile_resolver_codigo o búsqueda.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds context about the type of codes listed and the resolution path for missing idNorma, enhancing transparency beyond annotations.
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 sentences, no wasted words. First sentence states purpose, second provides usage guidance. Efficient and front-loaded.
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?
Given the tool's simplicity (no required inputs, output schema available), the description covers the essential information: what it lists, how to handle missing idNorma, and links to alternatives. Complete for its complexity level.
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?
The description does not mention the single parameter (response_format) or its options. However, the parameter is a simple nested object with an optional field, and the tool can be invoked without input. Given zero schema coverage, the description could have noted the output format choice, but the simplicity mitigates the 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?
The description clearly states it lists codes of the Republic with verified idNorma for direct access. The title reinforces this. It distinguishes from sibling tools like leychile_resolver_codigo.
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 states that codes without idNorma should be resolved using leychile_resolver_codigo or search, providing clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las leyes modificatorias (desde notas marginales) de la norma o de un artículo.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the source ('desde notas marginales') but does not disclose further behavioral traits such as output format or empty results handling. With annotations present, the description provides adequate but minimal added value.
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 a single, concise 10-word sentence that immediately conveys the tool's purpose. Every word contributes; no redundancy.
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 description is too brief for a tool with four optional parameters and no parameter explanation. While an output schema exists, the lack of parameter context forces the agent to infer usage from the schema alone, which may be insufficient 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% as per context, placing the burden on the description. The description fails to explain any of the tool's parameters (articulo, id_norma, numero_ley, response_format), leaving the agent without parameter guidance beyond the schema itself.
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?
The description clearly states the tool lists modifying laws from marginal notes of a norm or article. It uses specific verb 'Lista' and resource 'leyes modificatorias', distinguishing it from sibling list tools like leychile_listar_articulos and leychile_listar_categorias.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or comparisons to other tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las normas de una categoría temática (ver leychile_listar_categorias).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. Description adds no additional behavioral context beyond listing norms, which is consistent 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no redundant words.
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?
Given the simple tool (1 required param, safe annotations, output schema exists), the description succinctly covers the necessary context including the prerequisite tool reference.
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?
Description does not add meaning beyond the input schema; the schema already includes descriptions for id_categoria and response_format. The description merely echoes the cross-reference to leychile_listar_categorias.
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?
Description clearly states the tool lists norms of a thematic category, distinct from sibling leychile_listar_categorias which lists categories themselves. The verb 'lista' and resource 'normas de una categoria' are specific.
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?
Description references 'ver leychile_listar_categorias' indicating the prerequisite to first get category IDs, but does not explicitly state when to use or exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aísla y extrae los artículos transitorios (gradualidad y reglas de vigencia).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds only that it 'isolates and extracts', which is redundant. It does not explain behavior for edge cases (e.g., missing law, multiple arguments) or output format.
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 a single sentence, which is concise but lacks structure. It does not front-load key information like required parameters or typical usage, though it is not verbose.
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?
Given the tool has one required nested parameter composed of three fields, and an output schema exists, the description does not explain how to invoke it effectively. It omits that a law identifier is required, making it incomplete for an agent to use correctly without additional inference.
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?
With 0% schema description coverage per context signals, the description should compensate by explaining the parameters. It does not mention how to specify which law (e.g., id_norma or numero_ley) or the response_format. The description adds no semantic value beyond the schema's parameter names.
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?
The description clearly states that the tool isolates and extracts transitory articles (gradualidad y reglas de vigencia), which is a specific operation distinct from sibling tools like 'leychile_listar_articulos' or 'leychile_obtener_articulo'. The verb 'extrae' and resource 'artículos transitorios' provide clear purpose.
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?
No guidance is given about when to use this tool versus alternatives, such as when to use 'listar_articulos' instead. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Conecta un derecho sustantivo con su vía procesal idónea (reenvío sustantivo↔adjetivo).
Verifica en vivo la vigencia de las normas procesales citadas (para no plantear estrategias sobre un procedimiento modificado o derogado).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, idempotent, non-destructive tool. The description adds the behavioral trait of live validity checking, which is helpful but does not elaborate on side effects or output format.
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 sentences, front-loaded with purpose, no wasted words. Concise and structured effectively.
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?
Given the schema coverage is 0% and there are three effective parameters (through nested object), the description fails to provide necessary parameter guidance. The output schema exists, so return values are covered, but parameter semantics are missing, reducing completeness.
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?
The description does not explain the parameters; the input schema has 0% description coverage according to context, so the description should compensate. It mentions connecting a substantive right but gives no details on the 'institucion' parameter or optional fields.
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?
The description clearly states the tool connects a substantive right with its appropriate procedural route, using specific verbs and resources. It distinguishes itself from sibling tools by focusing on mapping rather than searching norms.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The usage is implied by the purpose, but the lack of exclusions or alternative references leaves the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Últimas normas publicadas en el Diario Oficial (novedades legislativas).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description 'últimas normas publicadas' aligns with annotations (readOnlyHint true, openWorldHint true). It discloses the return type (latest norms) but adds no additional behavioral context beyond what annotations already provide. No contradictions.
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 a single concise sentence, front-loading the key purpose. However, it omits parameter details, which slightly detracts from completeness while being efficient.
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?
Given the tool has an output schema and annotations, the description is very minimal. It does not explain how to use parameters or what the output format entails. The tool is simple, but the description leaves important gaps for an agent to effectively use it.
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%, and the description does not mention any parameter. Parameters like 'cantidad' and 'response_format' are left unexplained, forcing the agent to infer from names and defaults. The description fails to add meaning beyond the schema.
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?
The description clearly states it retrieves the latest norms published in the Official Gazette. The title 'Normas recientes' and the tool name confirm this. It distinguishes itself from sibling search tools by focusing on recent publications.
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 for getting recent legislative news but does not explicitly state when to use or not use this tool versus alternatives. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve los anexos de la norma (p. ej. sentencias del Tribunal Constitucional).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description does not contradict these but also adds no additional behavioral context (e.g., rate limits, auth needs, data volume). Given annotations, the bar is lower; a 3 is appropriate.
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 a single sentence, concise and to the point. It does not waste words, though it could be slightly expanded without losing conciseness.
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?
With an output schema present, return values are covered, but the description omits how to use the params object, the required fields, or the response format options. For a tool with a nested parameter and enums, this is insufficient.
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?
The description adds no information about parameters, despite the input schema covering three properties (id_norma, numero_ley, response_format) with 0% tool-level description coverage. The description must compensate for low schema coverage but fails to do so, leaving the agent without guidance on how to specify the norm.
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?
The description clearly states that the tool returns annexes of a norm (e.g., Constitutional Court rulings). It specifies the verb 'Devuelve' and the resource 'anexos de la norma', distinguishing it from sibling tools like leychile_obtener_norma which returns the norm itself.
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?
No guidance is provided on when to use this tool vs alternatives. The description lacks any context about prerequisites, exclusions, or use cases, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texto de un artículo concreto, con su ubicación, fecha de versión y cita forense.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal context about return values (location, date, citation) but does not disclose any additional behavioral traits such as rate limits or auth requirements.
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?
Single sentence is concise but overly minimal. Lacks essential context such as parameter requirements or example usage. Could be restructured to front-load critical information like input requirements.
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?
Given the complexity of sibling tools and nested parameters, the description is too sparse. It does not explain how to specify the article or distinguish from similar tools like obtener_fragmento. Output schema exists but description does not leverage it to clarify return structure.
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?
The description adds no information about parameters. Although the input schema has detailed descriptions for each field (100% coverage in schema), the tool description fails to clarify how to identify the article (e.g., needing articulo plus id_norma or numero_ley). Schema coverage is 0% from the description's perspective.
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?
The description clearly states it obtains the text of a specific article with location, version date, and forensic citation. It distinguishes from siblings like obtener_norma (whole norm) and obtener_version (version of norm) by focusing on a single article.
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?
No guidance on when to use this tool versus alternatives. There are many sibling tools for searching, comparing, listing articles, etc., but the description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrae con precisión forense un inciso, numeral o letra de un artículo.
Ej.: 'inciso segundo del art. 254 del CPC' o 'art. 434 N° 4'. Devuelve solo el fragmento pedido con su cita.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false. The description adds 'forensic precision' and return format context but no additional behavioral traits beyond what annotations convey. No contradiction.
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 two sentences long, front-loaded with the main action, and includes a helpful example. Every sentence is purposeful with no waste.
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 description explains what is returned ('solo el fragmento pedido con su cita') and with an output schema present, additional info on return values is not needed. It covers key aspects for a tool with few required parameters and clear purpose.
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?
The input schema has detailed descriptions for each parameter, so schema_description_coverage is effectively high. The tool description does not repeat parameter details but provides examples that illustrate usage. This adds value beyond schema but not significantly more than the baseline.
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?
The description uses a specific verb 'Extrae' and resource 'inciso, numeral o letra de un artículo', clearly stating what the tool extracts. The examples further clarify the purpose. It distinguishes from sibling tools like 'leychile_obtener_articulo' which returns the whole article.
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 provides clear context and examples of usage, indicating when to extract specific subparts. However, it does not explicitly list alternatives or exclusions, but the examples make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadatos y estado de vigencia (incluye vacancia legal, texto refundido y N° de versiones).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only, idempotent, non-destructive tool. The description adds specific details about the content returned, but does not disclose additional behavioral traits like required permissions or error states. With annotations covering safety, the description provides incremental value.
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 extremely concise, using a single short phrase. It is efficient and every word is relevant, but it could benefit from a full sentence structure.
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 tool has a clear purpose and returns specific metadata, but the description does not explain the input requirements or when to choose this over siblings. The presence of an output schema reduces the need to describe returns, but input guidance is missing.
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?
The description does not mention the input parameters at all. Although the input schema includes descriptions for id_norma and numero_ley, the description text fails to guide the agent on how to specify the norm. Given 0% coverage, this is a significant 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?
The description clearly states that the tool returns metadata and validity status including specific items like legal vacancy, consolidated text, and version count. It implicitly distinguishes from sibling tools that return full norms or articles. However, it does not explicitly state that it takes a norm identifier as input.
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?
No guidance is provided on when to use this tool over alternatives like leychile_obtener_norma or leychile_obtener_version. The description lacks any context or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texto consolidado y vigente de una norma (o de una versión histórica con id_version).
Si el texto excede max_caracteres, conmuta automáticamente a índice sistemático.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the key behavioral trait of automatically switching to systematic index when text exceeds max_caracteres, which is not fully covered by annotations. This extra context is valuable for understanding the tool's adaptive behavior.
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 extremely concise: only two sentences, no filler, and the critical details are front-loaded. Every sentence serves a purpose.
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?
Given the presence of an output schema (not shown) and comprehensive parameter descriptions, the description covers the main functionality and the notable auto-switch behavior. It does not explicitly list alternative identification methods (id_norma vs numero_ley), but these are documented in the schema, so the description is sufficiently complete for a read-oriented tool.
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?
The input schema provides descriptions for all parameters, so the description does not need to repeat them. It mentions max_caracteres and the auto-switch, but that is already in the schema's description for max_caracteres. No additional semantic value is added beyond the schema, so baseline 3 is appropriate.
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?
The description clearly states it returns the consolidated current text of a norm or a historical version, and mentions the automatic switch to systematic index. This distinguishes it from siblings like leychile_obtener_articulo (single article) and leychile_obtener_version (version metadata), making its purpose unambiguous.
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?
No guidance is given on when to use this tool versus the many siblings (e.g., leychile_obtener_articulo, leychile_texto_vigente_a_fecha). The description does not mention when not to use it, prerequisites, or alternatives, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texto consolidado de una versión histórica EXACTA (idVersion = fecha de versión).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that it returns 'texto consolidado', which is useful context. No contradictions. However, it does not disclose potential errors or permission needs, but with annotations the bar is lower.
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 a single, concise sentence that front-loads the purpose and key constraint. No unnecessary words or repetitions. Efficient and clear.
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?
Given the tool's simplicity, annotations cover safety, and an output schema exists, the description is largely adequate. It clearly states what it does and the exact version constraint. Minor lack of error handling or edge-case guidance, but acceptable for a straightforward retrieval tool.
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?
The description does not mention any parameters, providing no additional meaning beyond the input schema. The schema itself has clear descriptions for parameters like id_version, but since schema description coverage is 0% (the description adds no param info), and there are parameters with schema descriptions that are not leveraged, the description fails to compensate.
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?
The description explicitly states 'Texto consolidado de una versión histórica EXACTA' which clearly identifies the tool's purpose: retrieving the exact consolidated text for a specific historical version. The emphasis on 'EXACTA' and the mapping idVersion = fecha de versión distinguishes it from sibling tools like leychile_texto_vigente_a_fecha that retrieve the text in force at a date.
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 for exact historical versions but does not explicitly state when to use this tool over alternatives, such as leychile_texto_vigente_a_fecha or leychile_obtener_norma. No 'when not to use' or alternative names are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resuelve un código chileno por su nombre y devuelve sus metadatos e idNorma.
Útil para obtener el idNorma exacto del Código Civil, Penal, Procesal Penal, de Procedimiento Civil, del Trabajo, Tributario, etc., antes de pedir artículos.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating that the tool returns metadata and idNorma, which are not captured in annotations. No contradictions.
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 two concise sentences. The first sentence clearly defines the action and output, and the second provides examples and use-case context. No unnecessary words.
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 description covers the main purpose, inputs, and output (metadata and idNorma). With annotations covering safety and idempotency, and a simple parameter set, the description is sufficiently complete for an agent to use this tool correctly.
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?
The input schema already provides a description for 'nombre' and an enum for 'response_format'. The tool description does not add any additional semantic information beyond what the schema offers, so baseline 3 is appropriate.
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?
The description clearly states it resolves a Chilean code by name and returns metadata and idNorma. It provides specific examples (Código Civil, Penal, etc.) and distinguishes from sibling tools like 'leychile_resolver_ley_por_nombre' by focusing on codes.
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 gives explicit usage context: 'Útil para obtener el idNorma exacto ... antes de pedir artículos.' This tells the agent when to use the tool. It does not explicitly mention when not to use it or alternatives, but the tool name and sibling list imply it's for codes rather than laws.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resuelve una ley por su apodo o nombre de uso común (p. ej. 'Ley Karin', 'Ley Emilia').
Usa un catálogo verificado de apodos; si no está, busca en vivo y ofrece coincidencias.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral info: it uses a verified catalog first, and if not found, performs a live search and offers matches. This goes beyond what annotations provide without contradiction.
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 extremely concise: two sentences, front-loaded with the core purpose. Every word is necessary.
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?
Given the tool's simplicity, the description covers the main behavior and fallback mechanism. The presence of an output schema compensates for not describing return values. Minor missing details (e.g., what happens with multiple matches) but overall adequate.
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%, but the description does not detail the parameters. However, the 'nombre' parameter is self-explanatory from the tool's purpose, and the response_format parameter is minor. The description adds no extra meaning beyond the schema's own description.
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?
The description clearly states it resolves a law by its nickname (apodo o nombre de uso común) and gives examples like 'Ley Karin' and 'Ley Emilia'. This verb+resource combination is specific and distinguishes it from sibling tools that search by text, obtain by ID, or list norms.
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 use when you have a popular name, but does not explicitly state when to avoid or mention alternatives among the many siblings. The fallback behavior is described, but no direct comparison to other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sugiere las leyes especiales que priman sobre la norma general en un tema (Arts. 4° y 13 CC).
Catálogo curado verificado en vivo; señala el estado de vigencia de cada norma.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds value by explaining it's a 'catálogo curado verificado en vivo' and that it provides validity status for each norm. No contradictions.
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 concise sentences, front-loaded with core purpose, followed by additional behavioral detail. No wasted words.
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?
Adequate for a read-only, idempotent tool with output schema and annotations, but lacks parameter guidance and usage context, which limits completeness.
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%, but description does not mention parameters (tema, response_format, verificar_vigencia) beyond the tool's purpose. No detail on allowed values or usage of optional parameters.
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?
Description clearly states verb 'sugiere' and resource 'normas especiales' with topic context. Includes legal reference (Arts. 4° y 13 CC) and distinguishes from sibling tools like search or listing tools.
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 for suggesting special laws on a topic, but no explicit guidance on when to use vs. alternatives (e.g., leychile_buscar_normas) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Determina cómo estaba redactado un artículo a una fecha dada (control intertemporal).
Para normas procesales agrega la alerta de ultraactividad (actuaciones/plazos ya iniciados).
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations: it retrieves historical text and adds an ultraactivity alert for procedural norms. Annotations already declare read-only, idempotent, and non-destructive, which are consistent. No contradictions.
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?
Extremely concise: two sentences. The first sentence states the core purpose, and the second adds a critical special case (procedural norms). No waste.
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?
Given the tool requires specifying a norm (via id_norma or numero_ley), the description omits this crucial context. While the output schema exists (so return format is covered), the description should mention that the tool operates on a specific norm and how to identify it. It covers the main purpose but misses identification guidance.
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%, meaning the description provides no parameter-specific information. While the schema itself has detailed parameter descriptions (e.g., 'Fecha del presupuesto fáctico'), the description should compensate for low coverage but does not. It doesn't explain how to identify the norm (id_norma or numero_ley) or how articulo and fecha are used.
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?
The description clearly states the tool retrieves the historical wording of an article on a given date ('control intertemporal'), with a special alert for procedural norms. This distinguishes it from sibling tools like leychile_obtener_articulo (current text) or leychile_comparar_versiones.
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 explicitly indicates when to use the tool: for determining how an article was worded at a specific date, including ultraactivity for procedural norms. It doesn't explicitly mention when not to use, but the context of siblings implies this is for historical queries, not current text.
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.
v2.0.0leychile_buscar_en_normaleychile_buscar_normasleychile_citarleychile_comparar_articulosleychile_comparar_versionesleychile_concordancias_articuloleychile_extraer_definicionesleychile_historia_leyleychile_indice_sistematicoleychile_linea_tiempo_articuloleychile_listar_articulosleychile_listar_categoriasleychile_listar_codigosleychile_listar_modificacionesleychile_listar_normas_categorialeychile_listar_transitoriosleychile_mapa_procesalleychile_normas_recientesleychile_obtener_anexosleychile_obtener_articuloleychile_obtener_fragmentoleychile_obtener_metadatosleychile_obtener_normaleychile_obtener_versionleychile_resolver_codigoleychile_resolver_ley_por_nombreleychile_sugerir_normas_especialesleychile_texto_vigente_a_fechaScored across 28 tools
Every tool has a clearly distinct purpose, from searching norms to retrieving specific fragments to mapping procedural routes. No two tools overlap in functionality, and the descriptions make their unique roles explicit.
All tools follow the consistent pattern 'leychile_verb_noun' using snake_case, e.g., leychile_buscar_normas, leychile_obtener_articulo. This makes the tool set predictable and easy for an agent to navigate.
With 28 tools, the set is larger than the typical well-scoped range, but each tool addresses a specific legal research need (citation, comparisons, timelines, etc.), justifying the count for the complexity of Chilean law. Slightly oversized but still reasonable.
The tool set covers the full lifecycle of legal research: search, retrieval, citation, comparison, history, categorization, and special features like process mapping and definition extraction. No obvious gaps are present for a comprehensive legal MCP server.
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
