MCP Legal Chile

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
18 tools is well-scoped for legal research: enough to cover search, retrieval, citation, and investigation without bloat. Each tool serves a clear purpose.
Completeness5/5
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.
Average 2.6/5 across 18 of 18 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 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.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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

Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/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 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.
Behavior1/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/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 '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.
Behavior3/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters2/5
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.
Purpose2/5
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.
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 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose3/5
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.
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 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.
Behavior2/5
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.
Conciseness2/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose4/5
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.
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 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.
Behavior1/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters2/5
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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose3/5
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.
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. 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose3/5
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.
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 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
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 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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/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/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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
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 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
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 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.
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 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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
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. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 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.
Usage Guidelines4/5
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.

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:

[![mcp-legal-chile MCP server](https://glama.ai/mcp/servers/gabrielperezibacache/mcp-legal-chile/badges/card.svg)](https://glama.ai/mcp/servers/gabrielperezibacache/mcp-legal-chile)

Score Badge

Copy to your README.md:

[![mcp-legal-chile MCP server](https://glama.ai/mcp/servers/gabrielperezibacache/mcp-legal-chile/badges/score.svg)](https://glama.ai/mcp/servers/gabrielperezibacache/mcp-legal-chile)

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/gabrielperezibacache/mcp-legal-chile'

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