LeyChile MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.5/5 across 28 of 28 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives 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.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool 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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![LeyChile-mcp MCP server](https://glama.ai/mcp/servers/IanGuiloff/LeyChile-mcp/badges/card.svg)](https://glama.ai/mcp/servers/IanGuiloff/LeyChile-mcp)

Score Badge

Copy to your README.md:

[![LeyChile-mcp MCP server](https://glama.ai/mcp/servers/IanGuiloff/LeyChile-mcp/badges/score.svg)](https://glama.ai/mcp/servers/IanGuiloff/LeyChile-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/IanGuiloff/LeyChile-mcp'

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