MCP Legal Chile is a comprehensive legal research tool for Chilean law, providing access to official legislation, jurisprudence, doctrine, and administrative opinions. Key capabilities include:
Legislation: Search Chilean laws (BCN/LeyChile), retrieve norm metadata, check norm status and history, find related norms, get official XML text (full body or index), and extract specific articles or clauses/literals.
Jurisprudence: Search general Chilean court rulings (PJUD/TC) or specifically the Tribunal Constitucional, retrieve TC ruling extracts, and resolve cases by ROL/RIT — note that most jurisprudence searches return links only, not full text.
Doctrine: Search Chilean legal doctrine (OpenAlex, Crossref, SciELO Chile) or Latin American doctrine (Peru, Brazil, Argentina, Mexico, Colombia), with formal Chilean/APA citations, abstracts, and PDFs where available; retrieve specific works by DOI or OpenAlex ID.
Administrative Opinions (Dictámenes): Search Contraloría General de la República (CGR) dictámenes (link-only) or resolve a specific dictamen by number.
Citation & Text: Generate formal Chilean legal citations, produce official blockquote text from legal articles, and format citations for norms, ROLs, dictámenes, or doctrine from already-retrieved identifiers (no fabrication).
Integrated Research: Run a unified fan-out search across all sources (buscar_derecho_chileno), or orchestrate a full topic investigation into a structured anti-hallucination markdown memo (investigar_tema).
System Info: Access the tool catalog, honesty matrix, and Service Level Objectives via acerca_de.
Key limitation: Jurisprudence and dictamen searches provide links to official sources only — the system explicitly advises against affirming content based on link-only evidence.
Provides web search capabilities for legal content using Brave Search API as an optional search provider.
Used for durable caching and persistent API key quotas to improve performance and rate limiting.
Supports deployment on Render with a blueprint configuration and cron keep-alive for cold start mitigation.
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., "@MCP Legal Chile citar artículo 1 de la Constitución Política"
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.
Conector MCP libre y gratuito de derecho chileno para Claude, Cursor y apps compatibles.
Licencia: MIT — código abierto
Producción: https://mcp-legal-chile.onrender.com/mcp
Versión: 1.23.3
Roadmap: docs/ROADMAP.md · Changelog: CHANGELOG.md
Este MCP usa solo fuentes públicas sin costo de API:
Fuente | Uso |
LeyChile / BCN SPARQL | Texto y metadata de normas |
Tribunal Constitucional | Fallos TC con texto y considerandos |
OpenAlex + DOAJ + Crossref | Doctrina académica OA |
SciELO ArticleMeta | Enrich de artículos SciELO (PDF/HTML) por DOI/PID |
Portales oficiales (PJUD, CGR, superintendencias, etc.) | Deep links |
Yahoo HTML (+ DDG HTML/lite fallback) | Búsqueda web best-effort (sin claves) |
No se usan APIs comerciales (Serper, Brave, vLex, etc.).
PJUD no publica API de texto: para citar Corte Suprema / Apelaciones, pega el fallo en citar_jurisprudencia.
Acceso abierto por defecto (sin MCP_API_KEYS). Redis es opcional para self-host.CONTACT_EMAIL activa el polite pool de OpenAlex/Crossref (mailto=).
Excepción —
pjudCauses(§ Case-tracking PJUD): a diferencia de todo lo anterior, esta función sí elude una protección anti-bot (paga un solver de CAPTCHA para pasar el WAF F5/TSPD de PJUD). Está deshabilitada por defecto y es responsabilidad de quien la active.
Related MCP server: LeyChile MCP
Tool | Evidencia | Fuente |
| Texto íntegro + cita | XML LeyChile en blockquote |
| Texto + considerando | API TC gratis, o texto pegado (PJUD) |
| Metadata + abstract + citas | OpenAlex + DOAJ + Crossref + ArticleMeta |
| Metadata + citas + enlaces | Catálogo ISSN + OpenAlex + DOAJ |
| Enlace / candidatos | TC + web libre (Yahoo) → portales PJUD |
| Metadata + PDF | API gratuita TC |
| Enlaces + candidatos | TC + portales |
| Extracto + índice de considerandos | API gratuita TC |
| Solo enlace | Contraloría (deep link por número) |
| Solo enlace / portal_stub | CMF, Superintendencia de Salud, SUSESO, SEC, SUPERIR (sin API pública) |
| Pack mixto (parcial OK) | Orquesta lo anterior (~18s); cierra con Verificado / Por verificar / Portales / Próximos pasos |
| Texto + considerando | Fallo PJUD/CS/CA pegado (sin API abierta) |
| Índice del texto pegado | Lista/ranking de considerandos antes de citar |
| Texto + cita | Dictamen CGR pegado desde el portal |
| Plan de tools (local) | Router memo / escrito / seguimiento_causa / cita_rapida / consulta |
| Plan + pack | Orquesta |
| Esqueleto local | Demanda/recurso por materia (sin inventar citas) |
| Esqueleto local | Aviso/resumen/solicitud de antecedentes al cliente |
| Esqueleto local | Minuta de actualización desde campos/movimientos de causa |
| Esqueleto local | Anexo verified vs por verificar para el escrito |
| Diff local | Nuevas / desaparecidas entre dos snapshots de movimientos |
| Catálogo local | Mapa de flujos + tools + resources |
| Checklist local | Documentos a pedir al cliente por materia |
| Checklist local | Artículos/idNorma a obtener antes de redactar |
| Plan + plantilla + pack | Inicio orquestado de memo/escrito ( |
| Borrador local | Correo/WhatsApp solo con contexto aportado |
| Guía local | Qué tool llamar según el estado del trabajo |
| Catálogo local | Alias → idNorma/URL (CT, CPR, 19.880, …) |
| Catálogo local | Lista completa del hot catalog |
| Siempre | Oficina Judicial Virtual PJUD — experimental/no oficial, ver abajo |
Integridad (anti-alucinación): cada resultado lleva integrity:
Nivel | Significado |
| Texto/fuente oficial recuperada por el MCP |
| Metadato o enlace a verificar; no afirmar contenido |
| Solo portal de búsqueda; no es un documento encontrado |
Calidad de citas: jurisprudencia unifica el formato chileno (tribunal, tipo, ROL, año, considerando); la web ya no usa el título de página como cita. Doctrina normaliza autores (Apellido, N.), completa vol./páginas DOAJ y prioriza relevancia temática + catálogo Chile. Niveles de integrity: verified | candidate | portal_stub (evidence puede ser full_text / metadata / link_only).
Reglas: si evidence=link_only o integrity es portal_stub/candidate, no afirmes el contenido. citar_jurisprudencia rechaza un considerando que no exista en el texto (no sustituye por otro). Sin resultados → decirlo; no completar con memoria.
Empieza con catalogo_flujos o preparar_entregable / asesorar (modo=auto infiere el flujo).
Extrae texto con citar_texto_legal, obtener_articulo, obtener_fallo_tc o citar_jurisprudencia.
Fallos PJUD: abre el portal unificado, copia el texto → indice_considerandos y/o pegar_fallo_pjud.
Dictámenes CGR: resolver_dictamen (enlace) → pega el cuerpo en citar_dictamen_pegado.
Entregables: plantilla_escrito, anexo_citas, minuta_cliente / aviso_desde_causa.
Carpeta: lista_antecedentes → minuta_cliente (solicitud_antecedentes).
Seguimiento: obtener_causa_pjud → comparar_actuaciones → aviso al cliente.
Resources MCP: legalchile://guia/memo, .../escrito, .../seguimiento, .../honestidad, .../dia-tipico.
Si te trabas: siguiente_paso con el estado actual (pack_listo, causa_obtenida, etc.).
Guía completa: docs/flujo-estudio.md.
Operación | Objetivo | Notas |
Artículo con cache hit | < 500 ms | |
Artículo cold (sin 429) | < 5 s | LeyChile puede rate-limitar |
| < 4 s | SPARQL BCN |
| < 8 s | |
| < 18 s | Tope duro |
Éxito XML LeyChile (24h, con caché) | > 95% |
Métricas en vivo: GET /metrics
Texto oficial LeyChile (artículos, índice/cuerpo, inciso/literal heurístico)
Doctrina OA: ranking por relevancia, abstracts (backfill Crossref), enrich SciELO
citar_jurisprudencia con considerando (TC o texto pegado)
Caché en memoria (Redis opcional)
Rate limit / circuit breaker por proveedor (LeyChile XML aislado de BCN SPARQL/HTML; DOAJ aislado de Crossref; abort/deadline no abre circuitos; un solo conteo terminal tras reintentos)
Warmup boot + GET /warmup (cron) omiten XML si LeyChile está en cooldown 429 / circuito abierto
Endurecimiento de producción: CORS explícito para clientes MCP en navegador, rate limit por IP en /mcp (60 req/min por defecto, independiente de las cuotas por API key), errores JSON-RPC limpios (sin stack traces ni rutas de archivo aunque NODE_ENV no esté seteado), apagado ordenado ante SIGTERM/SIGINT, timeouts de socket HTTP contra clientes lentos, y uncaughtException/unhandledRejection no derriban el proceso
Nota clientes MCP (Hermes, etc.): un mensaje global tipo «MCP unreachable» tras ~3 errores suele ser protección del cliente, no del servidor. En el servidor los circuitos son por host; ante 429 o circuito abierto de LeyChile las tools de texto devuelven markdown útil (URL oficial + reintento) sin marcar
isErrorcuando es posible.
npm install
npm run dev
npm test
SMOKE_BASE=http://127.0.0.1:3000 npm run smokeMCP: http://localhost:3000/mcp
Variable | Descripción |
| Polite pool OpenAlex/Crossref ( |
| Opcional: Redis self-host |
| Opcional — si falta, acceso abierto |
|
|
| Tope búsquedas standalone (default 22s) |
| Búsqueda web libre (DDG) |
| Enfriamiento tras bloqueo DDG (default 180s) |
| Tope |
| Timeout por fuente en el pack (default ~11s) |
| Tope de requests/IP a |
| Timeouts de socket HTTP (defaults 60s/65s/61s) |
buscar_causa_pjud / obtener_causa_pjud automatizan la Consulta Unificada de Causas de PJUD (Oficina Judicial Virtual) para devolver estado, litigantes y movimientos por RUT/nombre o ROL/RIT/RUC. A diferencia de todo el resto de este proyecto:
Elude activamente el WAF anti-bot (F5/TSPD) de PJUD usando un navegador headless (Playwright) y un servicio de pago de resolución de CAPTCHA (2Captcha o CapSolver).
No es una API oficial ni endorsada por PJUD: los datos son siempre integrity=candidate, obtenidos por scraping, y pueden romperse sin aviso si PJUD cambia su HTML/anti-bot.
Implica un riesgo de Términos de Servicio que asume explícitamente quien habilite la función (ver docs/pjud-casetracking-solution.md para el diseño completo).
Deshabilitada por defecto (kill switch): si PJUD_CAUSAS_ENABLED != 1 o no hay un solver de CAPTCHA configurado, ambas tools degradan a una respuesta tipo portal_stub con el link a la Consulta Unificada, nunca fallan en silencio ni inventan datos.
Variable | Descripción |
|
|
|
|
| API key del solver (cuenta de pago) |
| Timeout de resolución (default 120s) |
| TTL de la cookie de sesión reutilizada (default 25 min), para amortizar el costo del CAPTCHA entre búsquedas |
| Tope diario de CAPTCHAs resueltos (control de costo/abuso, default 50) |
| Cache de resultados (default 6h / 24h) — el estado de una causa cambia a lo sumo a diario |
npm run build/postinstall no descarga Chromium salvo que PJUD_CAUSAS_ENABLED=1 esté seteado en tiempo de instalación (ver scripts/installPlaywright.mjs), así el build por defecto (p. ej. render.yaml) permanece liviano.
Blueprint: render.yaml — plan free, sin Key Value de pago ni API keys comerciales. pjudCauses está comentado en el blueprint por defecto: requiere una API key de pago (agrégala manualmente en el dashboard de Render si decides habilitarla).
No sustituye asesoría jurídica. PJUD/CGR no ofrecen API abierta de texto completo. El MCP es un puente gratuito a fuentes oficiales y OA.
Catálogo, matriz de honestidad y SLOs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits (e.g., read-only, return format, side effects). The agent has no information about what happens when the tool is invoked.
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 short (one line) but under-specified. Consiseness is undermined by lack of useful information; the sentence does not earn its place because it fails to communicate 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 no output schema and no annotations, the description is grossly inadequate. It does not explain what the tool returns or how to interpret the result, leaving a significant gap for a metadata/informational 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?
Input schema has no parameters, so schema_description_coverage is 100%. Baseline is 3. The description adds minimal context (catalog, honest matrix, SLOs) beyond the empty schema but does not explain parameters (none exist).
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 lists three nouns ('Catalog, honesty matrix, and SLOs') but lacks a verb to indicate action. It does not clearly state that the tool provides information about the MCP server, leaving purpose ambiguous. No differentiation from sibling tools (search and retrieval tools) is provided.
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 gives no context about use cases or exclusions, making it impossible for an agent to decide between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fan-out con presupuesto de tiempo; puede devolver pendingSources.
| Name | Required | Description | Default |
|---|---|---|---|
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes | ||
| limite_por_fuente | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses two key behaviors: fan-out (parallel queries) and a time budget, and warns that results may include 'pendingSources'. This adds value beyond the input schema, though details about result handling or error states are missing.
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 short (two phrases), but not in a concise, information-dense way. It omits critical details like purpose, source list, and usage context. The brevity undermines completeness, making it under-specified rather than efficiently written.
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 (fan-out across sources, time budget, pending results), the description is severely lacking. No output schema exists, so return values are unexplained beyond 'pendingSources'. There is no mention of which sources are searched, how to handle pending results, or error conditions. The description is wholly inadequate for effective use.
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 33% coverage (only 'formato' has a description). The description does not mention any parameters or clarify the roles of 'consulta' or 'limite_por_fuente'. It adds no semantic value beyond what the schema already provides, and the low coverage is not compensated.
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 'Fan-out con presupuesto de tiempo; puede devolver pendingSources' is vague. It does not explicitly state that this tool performs a unified search across multiple legal sources, though the title 'Búsqueda unificada' hints at it. The verb and resource are unclear, making it hard for an agent to know exactly what the tool does relative to siblings.
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 the specific source tools (e.g., buscar_legislacion, buscar_doctrina). The description does not indicate that this is a broad aggregator or that specific sources are preferable for targeted queries. Agents are left guessing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contraloría / administración (link_only).
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Cantidad máxima de resultados (1-20) | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'link_only', which is ambiguous and insufficient to disclose behavioral traits like safety, mutation, or return 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 short but lacks substance. While concise, it fails to convey necessary information, making it ineffective.
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 (3 parameters, no output schema, no annotations), the description is grossly inadequate. It omits what results look like, pagination, and any usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (two of three parameters have descriptions). The description adds no additional meaning beyond what the schema provides, so baseline of 3 applies.
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 'Contraloría / administración (link_only)' is vague and does not clearly state that the tool searches for dictámenes (opinions/rulings). The title helps, but the description itself lacks specificity.
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 'resolver_dictamen' or other search tools. No context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OpenAlex + Crossref con citas formales Chile/APA, DOI, abstract y PDF si existe.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Cantidad máxima de resultados (1-20) | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It mentions data sources and output fields but omits key behavioral traits: rate limits, whether PDFs are always available, authentication needs, or result sorting. Minimal insight into tool 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 a single short sentence, which is efficient. However, it could benefit from restructuring to separate core purpose from output details.
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?
No output schema is provided, so the description should clarify return structure. It mentions fields but does not specify ordering, pagination, or format details. With multiple sibling search tools, the description fails to disambiguate usage scenarios.
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 67% (limite and formato have descriptions, consulta lacks one). The tool description adds no additional meaning beyond the schema. It does not explain the consulta parameter or how to formulate queries effectively.
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 data sources (OpenAlex, Crossref) and output fields (citas formales, DOI, abstract, PDF) but does not explicitly state the action (e.g., 'Search for legal doctrine'). The purpose is implied but not clearly defined, and it does not distinguish from sibling tools like obtener_doctrina or investigar_tema.
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. It does not specify prerequisites, when not to use it, or provide any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Links a fallos PJUD/TC (evidencia link_only). Filtros opcionales anio/tribunal.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | ||
| limite | No | Cantidad máxima de resultados (1-20) | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes | ||
| tribunal | No | ||
| solo_urls_oficiales | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'evidencia link_only', which indicates that the tool returns links rather than full text. However, without annotations, there is no disclosure of other behavioral traits like authentication requirements, rate limits, or error handling.
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 very concise, using just two short sentences. It is front-loaded with the key purpose and main filters, but some additional details could be included without harming 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?
Given the tool has 6 parameters and no output schema or annotations, the description is insufficiently complete. It does not explain the return format, error scenarios, or the meaning of 'link_only' in detail.
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 mentions optional filters for year and court, corresponding to the 'anio' and 'tribunal' parameters, but does not cover other parameters like 'limite', 'formato', or 'solo_urls_oficiales'. With 33% schema description coverage, the description should add more meaning 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 title and description clearly indicate the tool searches for Chilean jurisprudence, and the description specifies it provides links to rulings from PJUD/TC. However, it lacks differentiation from sibling tools like buscar_tc, which may also search TC rulings.
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 alternatives. The description only mentions optional filters but does not provide context for when it is appropriate to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca normativa chilena en BCN / LeyChile. Para texto íntegro usa obtener_texto_norma / obtener_articulo.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Cantidad máxima de resultados (1-20) | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool searches norms and mentions the source (BCN/LeyChile), but discloses no behavioral traits such as authentication needs, rate limits, result structure, or side effects. The description is too minimal for a tool with no 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 only two sentences, with the first stating purpose and source, and the second redirecting to full-text tools. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 3 parameters, the description provides the basic purpose and one key usage hint. However, it lacks details on result formats (beyond 'formato' enum), pagination, error behavior, or how to differentiate from sibling search tools. It is minimally 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 coverage is 67%: 'limite' and 'formato' have descriptions, but 'consulta' lacks a schema description. The tool description does not add meaning for 'consulta' beyond implying it's a search query. Since the schema handles most parameters, a baseline of 3 is appropriate, but the missing coverage is not compensated.
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 searches Chilean legislation ('normativa chilena') using BCN/LeyChile. It distinguishes itself from full-text retrieval tools by redirecting to 'obtener_texto_norma'/'obtener_articulo', but does not differentiate from sibling search tools like 'buscar_derecho_chileno' or 'buscar_dictamenes', missing the top score.
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 when-not scenario (for full text, use other tools), but offers no guidance on when to prefer this search tool over other similar search tools in the sibling list. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Búsqueda acotada a tribunalconstitucional.cl (link_only).
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Cantidad máxima de resultados (1-20) | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'link_only' but does not explain authentication, rate limits, or what happens with no results.
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 entire description is a single concise sentence that front-loads the purpose. 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 resource but omits details like return format beyond 'link_only' and whether it is full-text search. The 'formato' parameter partially compensates.
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 meaning beyond the input schema. The 'consulta' parameter lacks a schema description and the tool description does not clarify it.
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 searches on tribunalconstitucional.cl and is link-only. It distinguishes from siblings that search other sources.
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 when searching the Constitutional Court site but does not explicitly state when to use it over alternatives or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve cita formal chilena + texto oficial de LeyChile listo para pegar en un escrito (blockquote).
| Name | Required | Description | Default |
|---|---|---|---|
| letra | No | ||
| inciso | No | ||
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| articulo | Yes | ||
| id_norma | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the output (citation + text blockquote) but omits any side effects, authentication requirements, rate limits, or external dependencies. The tool likely fetches data from LeyChile, but this is not 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 very concise (one sentence) and front-loaded with the main purpose. However, it is too brief to convey necessary details, making it merely adequate rather than efficiently 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?
Given the 5 parameters, 2 required, no output schema, and no annotations, the description is incomplete. It does not explain return format details (beyond 'blockquote'), provide usage examples, or clarify what constitutes a 'cita formal chilena'.
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 only 20% (only 'formato' has a description). The description does not explain the meaning of 'id_norma', 'articulo', 'letra', or 'inciso' beyond what the schema provides. For a low-coverage schema, the description should compensate but does not.
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 formal Chilean citation plus official text in blockquote format, using specific verbs and resources. However, it does not differentiate from sibling tools like 'obtener_articulo' or 'formatear_cita', which may have overlapping functionality.
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. No context about prerequisites, limitations, or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadatos de publicación y enlaces a historia LeyChile. Confirma siempre en la fuente oficial.
| Name | Required | Description | Default |
|---|---|---|---|
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| id_norma | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions returning metadata and links and advises confirmation in official source, implying data may not be authoritative. However, it does not disclose other behaviors like data freshness, rate limits, or authentication needs.
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 very concise (one sentence) but lacks necessary details. It is not wasteful, but it is too brief to be informative, failing to earn its place with substantive content.
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 2 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the response format, how to interpret results, or what 'estado' entails, leaving critical gaps for correct usage.
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 50% (formato has a description, id_norma does not). The tool description adds no explanation for parameters: it does not clarify what 'id_norma' represents or how to obtain it, nor does it elaborate on the 'formato' options beyond what the schema already states.
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 states it returns 'Metadatos de publicación y enlaces a historia LeyChile', clearly indicating it provides publication metadata and links. The name 'estado_norma' implies status, and the description adds a warning to confirm in official sources. However, it does not explicitly distinguish from sibling tools like 'obtener_norma' or 'normas_relacionadas'.
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. It only includes a caution to verify in the official source, which hints at reliability but does not explain context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera cadena de cita formal SOLO con identificadores ya recuperados (norma, ROL, dictamen o doctrina). No inventa datos.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| rol | No | ||
| url | No | ||
| anio | No | ||
| tipo | No | ||
| letra | No | ||
| inciso | No | ||
| numero | No | ||
| pagina | No | ||
| titulo | No | ||
| autores | No | Autores de doctrina | |
| revista | No | ||
| volumen | No | ||
| articulo | No | ||
| dictamen | No | ||
| tribunal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a non-destructive formatting operation and data integrity constraint ('No inventa datos'), but lacks details on input validation, error behavior, or authentication 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?
Two sentences, no filler, front-loaded with key purpose and constraint. Every word earns its place.
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 16 parameters, no output schema, low schema coverage, and no annotations, the description is too brief. It does not explain output format, parameter dependencies, or which identifiers are required for different citation types, 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 schema has 16 parameters with only 6% description coverage. The description only mentions high-level identifier types (norma, ROL, dictamen, doctrina), failing to explain the meaning of each parameter or how they combine to produce the citation. This is insufficient given the parameter count.
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 generates a formal citation string using already retrieved identifiers. The verb 'Genera' and resource 'cadena de cita formal' are specific, though it does not explicitly differentiate from sibling tool 'citar_texto_legal' which may also handle citation formatting.
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 restricts usage to already retrieved identifiers ('SOLO con identificadores ya recuperados') and warns against inventing data. This provides clear context but does not mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orquesta legislación (+ artículo si aplica), jurisprudencia, dictámenes y doctrina en un memo markdown anti-alucinación.
| Name | Required | Description | Default |
|---|---|---|---|
| consulta | Yes | ||
| limite_por_fuente | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the output format (markdown memo) and the anti-hallucination property, but lacks details on how sources are selected, whether it calls other tools internally, or any side effects or permissions needed. Some behavioral context is present but incomplete.
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 action ('orquesta') and includes key details (sources, output format). While it uses some jargon, it is efficient and contains no superfluous text.
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 orchestrating multiple legal sources and the absence of an output schema, the description is somewhat complete: it names all source types and the output format. However, it lacks specifics on how the query should be formulated, the structure of the memo, and any constraints on the tool's usage.
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 should add meaning to parameters. It does not explain 'consulta' or 'limite_por_fuente', leaving agents to rely solely on the schema. The parameter names are somewhat self-explanatory in Spanish, but the description adds minimal value.
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 orchestrates legislation, jurisprudence, dictámenes, and doctrina into a markdown memo, with an anti-hallucination focus. This is a specific verb+resource combination that distinguishes it from sibling tools that perform individual searches.
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 explicit guidance on when to use this tool versus the alternative sibling tools (e.g., buscar_legislacion, buscar_jurisprudencia). There is no mention of complementary or exclusive usage, making it difficult 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.
Candidatas relacionadas por similitud BCN + enlace a historia LeyChile.
| Name | Required | Description | Default |
|---|---|---|---|
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| id_norma | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the tool is read-only or modifies data. It lacks details on the nature of the similarity or the link 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 very short (one sentence) but somewhat cryptic due to jargon ('BCN', 'LeyChile'). It is concise but sacrifices clarity.
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 simplicity of the tool (2 parameters, no output schema), the description is incomplete. It does not explain what 'BCN' stands for, how the link works, or what the output format entails beyond 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 schema has 50% coverage; only 'formato' has a description. The description adds no explanation for 'id_norma', which is required. It does not enhance understanding 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 mentions 'candidatas relacionadas por similitud BCN' and 'enlace a historia LeyChile', indicating it finds related norms by similarity. However, 'BCN' is not explained and the purpose is somewhat vague compared to siblings like 'buscar_legislacion' or 'obtener_norma'.
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 such as 'buscar_legislacion' or 'estado_norma'. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Artículo puntual del XML oficial de LeyChile.
| Name | Required | Description | Default |
|---|---|---|---|
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| articulo | Yes | ||
| id_norma | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. The description only states what the tool does, without mentioning side effects (e.g., read-only), authentication needs, rate limits, or response characteristics.
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 (one short sentence), but it omits crucial details about parameters and usage. Conciseness is achieved at the expense of completeness, making the description under-specified.
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 lack of annotations, output schema, and the low schema description coverage, the description fails to provide sufficient context for correct tool invocation. Important details like the meaning of 'id_norma' and 'articulo' are absent, and no guidance is given on expected return values.
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 only 33% schema description coverage, the description adds no meaning to the parameters 'id_norma' and 'articulo', which are required but lack descriptions in both the schema and the tool description. The only parameter with schema description is 'formato', but the tool description does not reference any 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?
The title and description clearly state that the tool retrieves a specific article from the official LeyChile XML. This provides a specific verb-resource combination, but it does not differentiate it from sibling tools like 'obtener_norma' or 'obtener_texto_norma'.
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 such as 'obtener_norma' or 'buscar_legislacion'. The description lacks usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recupera una obra doctrinal con cita chilena, APA, abstract y enlaces DOI/PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| openalex_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a Chilean citation, APA citation, abstract, and DOI/PDF links, which gives some behavioral insight. However, it does not mention side effects, required permissions, or whether the operation is read-only (likely but unstated). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and resource, then lists output elements efficiently.
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 3 parameters (none required) and no output schema. The description does not clarify whether doi or openalex_id are alternatives or both needed, nor does it detail the output format beyond the listed items. This leaves the agent uncertain about how to invoke the 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?
Schema description coverage is only 33% (only the 'formato' parameter has a description). The description does not explain the doi or openalex_id parameters, nor their relationship (e.g., whether one must be provided). The description fails to compensate for the low 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 verb 'Recupera' (retrieve) and the resource 'obra doctrinal', specifying the output includes Chilean citation, APA, abstract, and DOI/PDF links. This distinguishes it from sibling tools like buscar_doctrina (search) and obtener_articulo (article retrieval).
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. It does not mention prerequisites, when not to use it, or how it differs from sibling tools like buscar_doctrina (which likely searches for doctrinal works).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extrae inciso/literal aproximado del texto oficial del artículo.
| Name | Required | Description | Default |
|---|---|---|---|
| letra | No | ||
| inciso | No | ||
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| articulo | Yes | ||
| id_norma | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It mentions 'aproximado', hinting at approximate results, which is a behavioral trait. However, it does not disclose other important behaviors like permissions, rate limits, or error conditions.
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 unnecessary words. It is concise, but could benefit from a bit more structure or detail without becoming 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 5 parameters, no output schema, and low schema coverage, the description is incomplete. It does not clarify output format beyond the schema's 'formato' enum, nor does it explain what 'aproximado' entails or how parameters interact.
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 only 20% (only 'formato' has a description). The description does not compensate for the other 4 parameters (letra, inciso, articulo, id_norma). It fails to explain their roles or how they relate to the extraction.
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/literal del texto oficial del artículo'), making the purpose clear. However, it does not distinguish from sibling tools like 'obtener_articulo' or 'obtener_texto_norma', which also deal with article 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?
No guidance is provided on when to use this tool versus alternatives. The description implies usage for extracting a specific subsection, but there are no exclusions or context for 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.
Metadatos BCN de una norma chilena.
| Name | Required | Description | Default |
|---|---|---|---|
| numero | No | ||
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| consulta | No | ||
| id_norma | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only indicates a read operation (metadatos) but lacks details on output structure, side effects, or authentication requirements. Minimal disclosure.
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 it omits essential details making it minimally adequate.
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 4 parameters with no output schema and no annotations, the description is severely incomplete. It does not explain usage, output, or how it complements sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description provides no information about any of the 4 parameters. With schema coverage at 25%, the description fails to clarify how parameters like id_norma, numero, consulta 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 states it retrieves metadata of a Chilean norm, but does not mention the search criteria (idNorma or number) or differentiate from sibling tools like obtener_texto_norma or 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 such as buscar_legislacion or obtener_texto_norma. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
XML oficial. modo=indice lista artículos; modo=cuerpo devuelve texto (truncable).
| Name | Required | Description | Default |
|---|---|---|---|
| modo | No | cuerpo | |
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
| id_norma | Yes | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions 'XML oficial' but the 'formato' parameter allows markdown/json, contradicting the implication of fixed XML output. No side effects, auth needs, or error behavior 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 very concise (two sentences) and front-loads the key fact 'XML oficial'. However, it could benefit from a brief usage context.
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 4 parameters and many sibling tools, the description is incomplete. It lacks output format clarification, usage guidance, and behavior details. The output schema is absent, so descriptions must cover return values, but they don't.
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 meaning for 'modo' (lists articles vs. returns text, truncable) and implies 'max_chars' for truncation. However, it does not describe 'id_norma' or 'formato' beyond schema defaults. With 25% schema coverage, the description partially compensates.
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 states that the tool retrieves official XML of a norm and distinguishes two modes (index lists articles, body returns text). It is clear about the resource and verb, but does not explicitly differentiate from the sibling 'obtener_norma'.
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 alternatives like 'obtener_norma', 'obtener_articulo', or 'buscar_legislacion'. The description only explains modes, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep-link / búsqueda por número de dictamen CGR.
| Name | Required | Description | Default |
|---|---|---|---|
| numero | Yes | ||
| formato | No | Formato de salida: markdown (recomendado para citas) o json | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. The description only states 'Deep-link / búsqueda' without explaining whether the tool is read-only, what it returns, or any side effects. It fails to convey basic behavioral information beyond the name.
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 very concise (one line), but it is too short to be effective. While it front-loads the purpose, it omits essential information such as usage context, parameters, and behavior. Conciseness is achieved at the expense of completeness, making it minimally adequate.
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 lack of annotations, no output schema, and only 50% parameter coverage, the description is severely incomplete. It does not explain the return value, authentication needs, or how the 'deep-link' works. The tool's complexity is low, but the description still fails to provide a complete picture.
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 50% coverage (only 'formato' has a description). The tool description adds no parameter information, so it does not compensate for the missing 'numero' description. It provides no meaning beyond what the schema already offers, leaving the required parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deep-link / búsqueda por número de dictamen CGR' clearly states the action (deep-link/search) and the resource (dictamen by number). It distinguishes from the general search tool 'buscar_dictamenes' by specifying direct access via number. However, the term 'resolver' in the title is ambiguous, and the description could more explicitly state that it retrieves a specific dictamen.
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. For example, it does not clarify that this tool is for direct lookup by number, while 'buscar_dictamenes' is for broader searches. The absence of any usage context or exclusions reduces its helpfulness.
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.
v1.3.0acerca_debuscar_derecho_chilenobuscar_dictamenesbuscar_doctrinabuscar_jurisprudenciabuscar_legislacionbuscar_tccitar_texto_legalestado_normaformatear_citainvestigar_temanormas_relacionadasobtener_articuloobtener_doctrinaobtener_incisoobtener_normaobtener_texto_normaresolver_dictamenScored across 18 tools
Each tool targets a distinct legal resource or action: search tools (buscar_*) are separated by domain (legislación, jurisprudencia, doctrina, dictámenes, TC); retrieval tools (obtener_*) handle specific entities; citation and formatting tools are unique; investigar_tema orchestrates searches. No ambiguity.
Most tools follow a verb_noun pattern (buscar_, obtener_, citar_, formatear_). A few deviate (acerca_de, estado_norma, normas_relacionadas) but the pattern is clear overall.
18 tools is well-scoped for legal research: enough to cover search, retrieval, citation, and investigation without bloat. Each tool serves a clear purpose.
Covers the full legal research workflow: search across all major sources, retrieve full texts and metadata, format citations, and compose topic memos. No obvious gaps for a read-only legal information system.
Resolve, search and verify legal citations against the official sources, with provenance.
Grounded MENA legal search, reasoning, citation resolution, and citation-graph traversal.
Search U.S. case law, fetch opinions, and ask matter-aware legal questions over your documents.
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
