mcp-cmf-chile

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
The 86 tools are organized by domain (empresa, fondos_mutuos, seguros, etc.), and the descriptive names help, but there is notable overlap among similar tools (e.g., multiple EEFF and indicator tools) that could confuse an agent selecting the right one. The consistent prefix pattern aides disambiguation, but the sheer volume makes misselection likely.
Naming Consistency4/5
All tool names follow a consistent snake_case convention starting with 'cmf_' followed by a domain and a resource noun. There is a slight mix of verb-leading (cmf_buscar_entidad, cmf_normativa_descargar) and noun-leading (cmf_empresa_eeff, cmf_fondos_mutuos_cartera) names, but the overall pattern is highly predictable and readable.
Tool Count2/5
With 86 tools, the server far exceeds the recommended range for a coherent toolset. Even considering the broad scope of financial regulatory data, this is an excessive number that will overwhelm agents and increase navigation complexity. The tools could be consolidated or grouped into multiple specialized servers.
Completeness5/5
The toolset is impressively comprehensive, covering nearly all CMF public datasets: financial indicators, banks, companies, mutual funds, insurance, XBRL, norms, and document handling. It includes search, listing, download, and even markdown conversion capabilities, with entity-level and market-level queries, leaving little critical functionality missing.
Average 3.3/5 across 86 of 86 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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=true and destructiveHint=false, so the agent knows this is a safe read operation. However, the description adds no behavioral context such as date-range filtering, pagination, or response scope. It only lists operation categories, which does not meaningfully extend the annotations.
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 this is under-specification rather than conciseness. It lacks a clear action and simply lists examples. Every word restates the title, so no sentence earns its place. It does not front-load a purpose or provide structured guidance for the agent.
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 moderate complexity (3 parameters, enums, output schema) and the large number of sibling tools, the description is far too thin. It does not explain what data is returned, how to filter, or how this relates to other CMF tools. An agent cannot confidently select or correctly invoke this tool based on the description alone.
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 coverage is 0%, so the description must compensate by explaining parameters. It fails to mention 'anio', 'tipo', or 'sociedades' at all. The enum for 'tipo' provides some implicit meaning, but the description gives no guidance on how to choose values or what the array 'sociedades' represents. The description adds zero value over the raw schema.
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 is a noun phrase listing capital operation types ('Repartos de capital, canje de acciones y acciones liberadas') with no explicit verb indicating the tool's action (e.g., retrieve, list, query). It restates the title's main idea and does not clarify whether the tool returns data, performs a calculation, or something else. While it distinguishes the topic from siblings, the lack of a verb makes the purpose vague.
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?
The description provides no guidance on when to use this tool versus alternatives. There are closely related siblings like cmf_dividendos and cmf_empresa_accionistas, but no mention of exclusions, prerequisites, or preferred contexts. An agent has no information about which scenarios this tool is best suited for.
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 declare readOnlyHint=true, so the safety profile is covered. However, the description adds no behavioral context beyond the name, such as data scope, pagination, limitations, or expected output. It does not contradict the annotations.
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 it reads as a fragment rather than a structured explanation. It is not verbose, but it is under-specified, resembling a title more than a functional description that guides invocation.
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?
With 5 parameters, a rich sibling context, and a generic description, the description is inadequate for an agent to understand what the tool does, when to use it, or how to invoke it correctly. The presence of an output schema does not compensate for the lack of input guidance and tool-selection context.
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 gives no explanation of the parameters (mes1, mes2, anio1, anio2, sociedades). The agent receives no help in understanding how to set these values, and the description fails to compensate for the schema's lack of semantic detail.
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 states the subject matter ('financial indicators under Chilean corporate standards') but lacks a specific verb or resource. It essentially restates the tool name and does not distinguish it from sibling tools like cmf_indicadores_financieros_sa or cmf_empresa_eeeff_nch.
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, no prerequisites, and no exclusions. The description is purely declarative without any contextual direction for selecting among the many related CMF tools.
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 adds no behavioral information beyond the annotations (readOnlyHint=true, destructiveHint=false). It does not disclose whether both parameters are required, how results are ordered, or any limitations. While annotations cover the safety profile, the description contributes nothing about the tool's behavioral traits.
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 concise (five words), but it is under-specified to the point of being a label rather than a useful description. It does not earn its place because it adds no information beyond the title, and important context about parameters and usage is missing.
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 two parameters and an output schema, the description provides almost no context. It does not explain what 'dictámenes' are, how the date range behaves, or how this tool fits with siblings. The output schema covers return values, but the tool's purpose and usage constraints are largely unexplained.
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 input schema has two parameters (desde, hasta) with zero description coverage, and the tool description does not mention them at all. The agent is left to infer that they are date filters from the 'YYYY-MM-DD' pattern, with no explanation of their semantics or relationship to the dictámenes being queried.
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 'Consulta de dictámenes de la CMF' states a clear action (consulta) and resource (dictámenes de la CMF), so it is not a pure tautology. However, it essentially repeats the tool title and does not distinguish this tool from other CMF query tools like cmf_sanciones_globales or cmf_resoluciones_globales, leaving the specific nature of 'dictámenes' undefined.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, any prerequisites, or context about the date-range parameters. It simply states the action without any direction for the agent.
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 adds no behavioral information beyond what annotations already state (readOnlyHint=true, destructiveHint=false). It does not mention the optional 'orden' parameter, output format, or any other behavioral trait, so it contributes nothing beyond structured metadata.
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 brief but under-specified. While it is short, it does not earn its place because it provides no actionable information; it is more of a label than a useful description.
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?
Even though the tool is simple with one optional parameter and has an output schema, the description fails to deliver complete context. It does not explain the parameter's effect, what data is returned, or how it fits with sibling tools, leaving gaps that an agent cannot resolve.
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 input schema contains one parameter 'orden' with no description, and schema coverage is 0%. The description also fails to explain what 'orden' does or how it affects results, leaving the parameter's semantics completely opaque.
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 'Información sobre tomas de control de emisores de valores' is a noun phrase that essentially restates the title with 'Información sobre' and adds 'de valores'. It lacks a specific verb or action (e.g., 'get', 'search'), making it a tautology rather than a clear purpose statement.
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 many sibling CMF tools. The description gives no context about intended use cases, scenarios, or exclusions, leaving the agent without any direction for tool 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds only the ISPRO system reference and does not disclose any behavioral traits such as pagination behavior, default filtering, data interpretation, or return characteristics. The added value beyond annotations is minimal.
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, so it is concise and front-loaded. However, it is under-specified rather than appropriately informative; it mainly repeats the title. It earns a score of 3 because it is brief but not effectively structured to convey key information.
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 has 3 optional parameters and an output schema, the description is severely incomplete. It does not explain what 'producción' means, what data is returned, how to use the parameters, or how this tool relates to the ISPRO system. It is inadequate for an agent to correctly invoke and interpret results.
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 parameter information. The schema covers limit and offset with descriptions, but tipoentidad lacks a description; the enum values (CSJUR, CSGEN, CSVID) are not explained. With 67% schema coverage and no compensating description, the agent gets limited semantic clarity.
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 is essentially a restatement of the title: 'Producción de corredores de seguros' repeats the title verbatim. The only addition is '(sistema ISPRO)', which identifies the source system but does not clarify what the tool does (e.g., list, query, report). It fails to distinguish from sibling tools like cmf_seguros_siniestros or cmf_seguros_eeff.
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?
There is no guidance on when to use this tool versus alternatives, no mention of typical use cases, and no exclusions. The description provides no context to help an agent select this tool over other insurance-related tools.
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 readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds no additional behavioral context such as how RUT is used, whether results are filtered, or what the response contains beyond the generic subject matter.
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 very short, but it qualifies as under-specification rather than conciseness. It is a sentence fragment without a verb, and the parenthetical '(pestanía 4)' is low-value noise that does not help an AI agent understand the tool's operation.
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 simplicity (one optional param, read-only, output schema present), the description is still insufficient. With over 80 sibling tools, it must clarify the exact scope and relationship to other company data tools, which it does not. The description only names the data category and fails to explain how 'directorio' relates to other metadata like accionistas or hechos.
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 for the undocumented 'rut' parameter. The description does not mention 'rut' at all, nor does it explain that the issuer is identified by RUT or whether the parameter is required. The only hint comes from the context 'de un emisor', which is too indirect to count as meaningful parameter semantics.
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 'Directores y gerentes de un emisor' clearly identifies the content area (directors and managers of an issuer), but it is a noun phrase without a verb such as 'list' or 'get'. It does not distinguish itself from sibling tools beyond naming a different data category, and the suffix '(pestanía 4)' adds navigational context that is not functional.
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 information about when to use this tool versus the many sibling tools (e.g., cmf_empresa_accionistas, cmf_empresa_info). There is no mention of prerequisites, typical scenarios, or alternative tools that should be preferred.
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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context—'Informe' implies a read-only report, but it does not reveal whether this returns a list, a file, or how it behaves with different year inputs. No additional traits beyond annotations 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no fluff. It is concise and front-loaded, but it is under-specified, lacking essential details about parameters and usage, which makes it less helpful than a more complete but still concise description.
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 one optional parameter and an output schema, but the description is too sparse to be complete. It does not explain the year filtering capability or how to interpret the report. Given the richness of the sibling context, more contextual guidance is needed to select and invoke this tool correctly.
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 the 'anio' parameter at all. Without any explanation of the year field's purpose or accepted values beyond the regex pattern, the agent has no semantic guidance for using the parameter.
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 provides a report of maximum commissions applicable to investment funds ('Informe de comisiones máximas aplicables a fondos de inversión'). It uses a specific verb ('Informe') and resource, and the tool name distinguishes it from sibling tools like cmf_fondos_mutuos_comisiones. However, it does not explicitly contrast with similar commission tools.
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?
There is no guidance on when to use this tool versus alternatives. The description is a single declarative sentence with no mention of use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the historical scope and serverlet name, but does not disclose behavioral traits such as how the 'indice' parameter affects results, pagination, or output format beyond what the schema already shows.
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 a single short sentence with no fluff, but it is under-specified. It omits crucial usage and parameter information, so its brevity is not an asset but a gap. It does not earn its place as a complete specification.
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 optional parameter with no schema description and no parameter explanation, the description is insufficient for an agent to confidently invoke it with meaningful arguments. The output schema exists, so return values are covered, but the input semantics and usage context are missing, leaving a significant completeness gap even for a simple tool.
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 the 'indice' parameter at all. Its default value '8.0' is cryptic, and the agent receives no guidance on what values are valid or what they represent. The description fails to compensate for the complete lack of parameter documentation.
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 'Cronología histórica del sistema bancario chileno' clearly identifies the resource (Chilean banking system) and scope (historical chronology), which distinguishes it from sibling tools like cmf_bancos_tasas and cmf_bancos_reportes. However, it lacks an explicit verb like 'get' or 'list', making it slightly less direct than ideal.
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 prerequisites, and no exclusions. It only states what the tool is about, not how or when it should be selected.
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 readOnlyHint=true and destructiveHint=false, but the description adds no behavioral context beyond the domain label. It does not mention date-range semantics, filtering behavior, or what kind of output to expect, so the agent gains little beyond the structured annotations.
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 and free of fluff, but it is arguably an under-specified noun phrase that barely expands on the title. It is concise without being informative, so it earns a middle score rather than high marks for quality 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 five optional parameters and no parameter documentation or usage guidance, the description is insufficient for correct tool selection and invocation. The presence of an output schema reduces the need to document return values, but the missing parameter semantics and selection criteria leave a significant gap.
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 provides no parameter explanations. The names mes1/mes2, anio1/anio2, and sociedades imply a date range and entity filter, but the tool description does not confirm or elaborate on these, leaving the agent to infer all invocation details.
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 identifies the resource as IFRS financial indicators and targets securities agents and stockbrokers, which differentiates it from sibling tools like cmf_intermediarios_eeff_ifrs or cmf_liquidez_intermediarios. Although it lacks a directive verb, the noun phrase conveys the tool's data domain with enough specificity.
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 such as cmf_intermediarios_eeff_ifrs, cmf_resultados_av_cb, or cmf_liquidez_intermediarios. There is no mention of use cases, prerequisites, or exclusions.
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 readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context such as date filtering, pagination, or output format. It neither contradicts the annotations nor enriches them, offering no extra transparency beyond what the annotations provide.
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 with no filler or redundant content. It front-loads the core topic and is easy to parse. While short, it is concise rather than 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?
The tool has 3 optional parameters, an output schema, and many sibling tools. The description is extremely minimal and does not specify valid date ranges, how to identify intermediaries, or what the resulting indices contain. Despite having structured annotations and output schema, the description leaves critical gaps 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 descriptions are completely absent (0% coverage). The description also fails to explain any of the three parameters (desde, hasta, intermediario), leaving their meaning and usage entirely to inference from parameter names. The description does not compensate for the schema gap.
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 'Índices de liquidez y solvencia de intermediarios de valores' clearly identifies the resource (securities intermediaries) and the metric type (liquidity/solvency), but it is a noun phrase without an explicit action verb. It also does not differentiate from similar sibling tools like cmf_intermediarios_indicadores_ifrs, which likely covers similar indicators.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it state any prerequisites or contextual scenarios. This leaves the agent without direction on tool 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 readOnlyHint=true, and the description's 'consulta' aligns but adds no new behavioral context. It does not mention date range handling, response format, pagination, or any limitations beyond what the schema shows.
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 concise sentence with no redundant text, but it adds little beyond the tool name and title. It is appropriately short but under-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?
For a simple date-filtered query tool, the description is incomplete. It omits the purpose of the date range, does not mention that parameters are optional, and lacks context about the nature of the loan data. Although an output schema exists, the description still fails to give sufficient 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?
The description does not explain the 'desde' and 'hasta' parameters at all, despite schema description coverage being 0%. The parameter names are somewhat self-explanatory as date filters, but the description does not compensate for the lack of schema documentation.
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 queries 'préstamos otorgados' (granted loans) and specifies the domain as 'mercado de valores' (securities market). The verb 'consulta' and resource are specific, and it is distinct from sibling tools, though it does not explicitly differentiate from them.
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, any prerequisites, or typical use cases. The description only states what it does, not when or why 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?
Annotations already declare readOnlyHint true and destructiveHint false, so the safety profile is known. The description adds only 'API oficial v3', which is version information and not behavioral disclosure. It doesn't describe output shape, filtering behavior, or any operational characteristics.
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, front-loaded sentence that is appropriately concise. It avoids wordiness, though it is also sparse in 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?
With an output schema present, return values are covered, but the description lacks essential context about how to use the tool: what value to pass for 'institucion', whether 'mes' and 'anio' are optional filters, and how this tool relates to siblings. It is too thin to be complete.
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%, and the description does not mention any parameters. While 'mes', 'anio', and 'institucion' are self-explanatory Spanish names, the description fails to compensate for the lack of schema descriptions, especially the required 'institucion' parameter and its expected format.
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 resource: members of the directory (board) of a financial institution. It distinguishes itself from siblings like 'accionistas' (shareholders) by naming a different entity type, though it doesn't explicitly contrast it with them.
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 prerequisites, and no context about how it fits among the many sibling tools. It is a bare statement of what it returns.
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 operation as read-only and non-destructive, so the safety profile is covered. However, the description adds no additional behavioral context such as pagination, date-range constraints, or required filters, offering nothing beyond what the annotations and schema already imply.
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, efficient sentence that front-loads the resource and key dimensions. It is concise and free of waste, though it is arguably too terse to fully support an agent's decision-making.
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?
For a tool with six optional parameters and no inline documentation, the description is inadequate. The output schema exists, so return formatting doesn't need explanation, but the purpose, parameter semantics, and intended usage context remain too vague for reliable 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?
With 0% schema description coverage, the description must compensate, but it only mentions 'tipo' and 'cuadro' without explaining possible values or how the optional month/year parameters work. It adds minimal meaning beyond the parameter names, leaving the agent uncertain about valid inputs.
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 identifies the resource as 'valores de ahorro previsional voluntario (APV)' and mentions the key dimensions 'tipo' and 'cuadro'. However, it lacks an explicit verb (e.g., 'consulta' or 'recupera') and does not differentiate itself beyond the unique resource name, which is otherwise clear among the many sibling tools.
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 context about when to use this tool versus the many other CMF financial data tools, nor does it mention any prerequisites, filters, or alternative tools. An agent would have no guidance on selecting this tool for a specific task.
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 and destructiveHint=false, which cover safety expectations. The description adds the 'detalle y resumen' distinction, indicating that the output can be either detailed or summarized. However, it does not add other behavioral context like rate limits, response size, or authentication requirements. With annotations present, a score of 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, concise sentence that is front-loaded with the core subject 'Dividendos declarados'. There is no redundancy or filler. However, its brevity comes at the cost of omitting important parameter and usage information, which prevents a perfect score.
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 six parameters, zero schema coverage, and no output schema details provided, the one-sentence description is insufficient for an agent to construct a valid request. The meaning of the date fields, type of dividend, and society list remain opaque. The 'detalle y resumen' hint is the only additional context, leaving the tool under-described.
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 provides no explanation for the six parameters (mes, anio, mes2, anio2, tipodiv, sociedades). An agent cannot infer what these parameters mean, their formats, or how they should be combined. The description does not compensate for the missing schema descriptions at all.
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 identifies the resource as dividends declared by public limited companies, with both detail and summary levels. It distinguishes this tool from the many other CMF tools since 'dividendos' is a unique domain. However, it lacks an explicit verb like 'obtener' or 'listar', though the intent is apparent from the title and description.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention filter options, date ranges, or how it relates to sibling tools such as cmf_empresa_info or other dividend-related APIs. The usage context is only implied by the title and description.
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 and destructiveHint=false, so the safety profile is covered. The description adds the period scoping ('para un período') but does not explain the cryptic 'pestanías 5/21' or any additional behavioral details like output characteristics or data source.
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 conveys the core purpose without redundancy. However, the phrase '(pestanías 5/21)' is cryptic and likely a typo for 'pestañas', which detracts slightly from 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?
With an output schema present, return-value documentation is unnecessary, but the description leaves significant gaps: it does not explain the parameters, the meaning of 'pestanías 5/21', or how to identify the emisor. For a tool with three parameters and zero schema coverage, this description is incomplete.
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 provides no explanation of the three parameters (mes, rut, anio). The mention of 'período' hints at time-related parameters but does not distinguish mes from anio or explain that rut refers to the issuer. The description completely fails to compensate for the missing schema documentation.
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 identifies the resource: 'Los 12 mayores accionistas de un emisor para un período' (the 12 largest shareholders of an issuer for a period). It differentiates from sibling tools by specifying 'emisor' and the fixed number 12, though lacks an explicit verb like 'obtener' or 'listar'.
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 merely states what data it returns, with no mention of use cases, exclusions, or related tools such as cmf_api_accionistas_institucion.
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 and destructiveHint=false, so the safety profile is established. The description adds useful context about the data fields returned and the source, but does not disclose other behavioral traits such as whether the RUT is required, error behavior, or pagination. Given the annotations cover the main concern, 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, efficient sentence that front-loads the core purpose and data fields. It is appropriately sized, with no unnecessary information, though it contains a minor typo ('pestanía' instead of 'pestaña').
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 incomplete for a tool with one parameter and an output schema that is not referenced. It lacks information about how to query (e.g., whether RUT is required), what happens if omitted, and why this tool would be chosen over similar alternatives. The existence of an output schema reduces the need to explain return values, but usage and parameter behavior are still missing.
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 schema has one optional parameter 'rut' with a pattern but no description, and the description does not explain how to use it. The description lists RUT as an output field, not as an input query parameter, creating ambiguity. With 0% schema description coverage, the description should clarify the parameter meaning but fails to do so.
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 provides identification data of an issuer (razón social, RUT, inscripción, actividad) from the CMF ficha, tab 1. It specifies the resource and the type of data, distinguishing it somewhat from similar sibling tools by referencing the specific source and tab, though it does not explicitly contrast with them.
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 cmf_empresa_por_ticker or cmf_buscar_entidad. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without clear selection criteria.
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 adds no behavioral context beyond what annotations already state (readOnlyHint=true, destructiveHint=false). It does not disclose any limitations, required input formats, or other operational traits. For a read-only tool, the annotations cover safety, but the description fails to add additional useful behavioral information.
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 communicates the tool's purpose without redundancy. It effectively expands the title abbreviations and names the target entities, earning its place with no wasted words.
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 five parameters and a complex domain (financial regulatory data), but the description is minimal. While an output schema exists, the description does not clarify the meaning of parameters or the intended use case, making it incomplete for an agent to confidently select and invoke the tool correctly.
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 provides no explanation of the five parameters (mes1, mes2, anio1, anio2, sociedades). The agent must rely solely on parameter names, which are ambiguous (e.g., 'sociedades' could mean companies or entities). This is a critical gap for effective invocation.
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 identifies the tool as providing IFRS financial statements for specific types of intermediaries (stock brokers, exchange brokers, and commodity exchange brokers). This distinguishes it from related tools like cmf_eeff_ifrs_sa (for S.A. companies) and cmf_intermediarios_indicadores_ifrs (indicators), though it lacks an explicit verb like 'retrieve' or 'list'.
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 does not mention any specific use cases, prerequisites, or exclusions, leaving the agent without context for selection among many related financial tools.
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 read-only, and the description adds a small behavioral clue: it is an 'AJAX grid of the sv_cumplimientos system', suggesting it scrapes an internal web interface. However, it doesn't disclose paging, parameter dependencies, or response format. The added value is minimal, so a mid-range score.
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 one short phrase, which is extremely concise. However, it is more cryptic than helpful, and the parenthetical about the AJAX grid adds some context but is not structured. It could be longer and more explanatory while still staying 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?
With an output schema present, return values are covered, but the description lacks use-case guidance and parameter semantics. The tool appears to be a simple data retrieval, but the description is incomplete for an agent to know how to correctly invoke it, especially with optional parameters.
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 coverage is 0% and the description does not explain mes, anio, or tipoentidad. The parameter names are somewhat self-explanatory, but valid values for tipoentidad are unknown and no additional context is provided. The description fails to compensate for the missing schema documentation.
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 identifies the resource (insurance companies' regulatory compliance) and distinguishes it from siblings like seguros_siniestros or seguros_eeff by using 'cumplimiento'. However, it lacks an explicit verb like 'get' or 'list', relying on the noun phrase 'Cumplimiento de la normativa'.
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. There is no mention of the intended use case, prerequisites, or exclusions. The description merely states the subject matter.
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 and destructiveHint=false. The description adds that it is a direct GET, reinforcing the read-only nature. However, no further behavioral context is provided, and there is 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is generally good, but it contains a typo ('pestanía') and the 'GET directo' note adds little value. It is concise but could be more informative 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?
Although an output schema exists, the description lacks usage context and parameter semantics. Given the large number of sibling tools, this omission is significant; the agent may not know when to invoke this tool or what input to provide beyond the optional rut.
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 single 'rut' parameter is not explained in the description. With 0% schema description coverage, the description should compensate by clarifying that rut identifies the entity, but it does not, leaving the agent to infer from the pattern.
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 identifies the tool as providing the registry of registered products for an entity, listing examples (securities, installments, series) and referencing tab 31. This distinguishes it from sibling tools that cover other entity aspects, though the action is implied rather than explicitly stated.
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?
There is no guidance on when to use this tool compared to alternatives. The reference to 'pestanía 31' is an UI detail and does not help an agent decide, nor are exclusions or alternative tools mentioned.
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 and destructiveHint=false, so safety is clear. The description adds minimal behavioral scope ('meses anteriores') but does not disclose pagination, response size, or rate limits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant wording. However, it is under-specified for tool selection, which slightly detracts from its overall structure effectiveness.
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 is simple (one optional boolean parameter), but the description does not explain the entity scope, what 'resoluciones cursadas' specifically means, or how it differs from similar tools in the sibling list. The output schema exists, but selection context is insufficient.
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 covers 100% of parameters with a detailed description for 'historico'. The tool description adds no additional parameter context, so baseline 3 is appropriate per the schema coverage rules.
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 the resource ('resoluciones cursadas') and scope ('recientes e históricas'), but lacks an explicit action verb like 'list' or 'get'. It does not differentiate from siblings such as cmf_resoluciones_globales or cmf_sanciones_cursadas, making it ambiguous what unique tool this is.
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 cmf_resoluciones_globales. The historico parameter hints at different use cases (recent vs full history), but the description itself offers no explicit when/when-not guidance.
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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context (e.g., pagination, entity-type filtering, what each row represents), providing no extra value beyond the title.
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 Spanish sentence with no filler; it efficiently names the resource and regulatory reference. Perfectly sized.
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 and safe-read annotations, the core return format is covered, but the description is too sparse to guide correct selection among similar insurance-related tools. The ambiguous tipoentidad parameter and lack of usage guidance are significant gaps.
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, particularly tipoentidad, whose CSGEN value is not mentioned in the 'vida/reaseguradoras' description. Schema covers limit/offset (67% coverage), but the enum parameter remains ambiguous, and the description fails to clarify its role.
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 identifies the resource as the investment portfolio of life insurance companies/reinsurers under Circular 1835. It distinguishes from sibling insurance tools (siniestros, eeff, rentas vitalicias) by its specific subject matter, though it lacks an explicit action verb like 'returns' or 'lists'.
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 the many sibling cmf_seguros_* tools. It neither states prerequisites nor excludes alternatives, leaving the agent to infer applicability solely from the resource name.
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 discloses a valuable behavioral trait: the tool may require solving a CMF anti-bot challenge and should be retried if it fails. This adds context beyond the annotations' read/destructive hints, which is important for execution, though other behaviors like response format or rate limits are not covered.
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, compact sentence with essential anti-bot information. It is front-loaded with the core purpose and contains no fluff, making it 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?
Given the tool has 5 optional parameters and many sibling report tools, the description is too terse to provide enough context for correct selection and invocation. It does not explain what report categories exist, how the parameters relate, or what differentiates this tool from similar ones, despite having an output 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 description provides no parameter-level detail, leaving `indice`, `reporte`, `institucion`, and period fields unexplained. With schema coverage at 60%, the missing parameters (indice, periodo_final) are unaddressed, and the description does not compensate for these gaps.
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 provides reports from the BaseDato system for financial institutions, but it uses a noun phrase rather than a clear verb and does not specify what kinds of reports are included. It is somewhat distinguishable from sibling tools via 'BaseDato' but remains vague compared to more specific bank report tools.
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. It mentions retrying on failure due to anti-bot challenges, but gives no context for selecting this over other CMF report tools or any 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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the data is 'asignadas a emisores e instrumentos por clasificadoras', providing context about the source and target of the ratings. No additional behavioral traits (e.g., pagination, result size limits) are disclosed, but the annotation coverage lowers the burden.
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 with no redundancy or filler. It front-loads the core subject. However, it could have included more operational detail without becoming wordy, so it is concise but slightly under-specified for a 5-parameter tool.
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 and safety annotations, the description lacks essential context for usage: it does not mention that all parameters are optional, how filtering works, or what kind of data is returned beyond the general 'clasificaciones de riesgo'. For an AI agent to select and invoke this tool correctly, more guidance on when to use it and how the filters behave is needed. The description is too thin for a tool with 5 parameters and a low schema description coverage.
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 40% (only limit and offset have descriptions). The description does not compensate for the undocumented parameters (emisor, clasificadora, tipo_instrumento). While the parameter names are self-explanatory in Spanish, the description does not clarify expected formats, interplay, or whether they function as filters. Thus it adds little beyond 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 identifies the resource as 'Clasificaciones de riesgo asignadas a emisores e instrumentos por clasificadoras', which clearly conveys the domain and scope, distinguishing it from insurance-specific classification tools like cmf_seguros_clasificacion_riesgo. However, it lacks an explicit action verb such as 'list' or 'get', so the purpose is clear but not stated as an imperative.
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 mention of optional filters, and no exclusions. It is a bare statement of the tool's subject matter, leaving the agent to infer usage from the schema and sibling 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 and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral nuance: '0=todas' indicates the wildcard behavior for the sociedades parameter, and 'y otras entidades' expands the scope beyond strictly S.A. entities. However, it does not disclose period constraints, output structure, or other execution behaviors.
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 two short sentences with no filler, front-loaded with the primary resource. It earns its place by stating the core purpose and the key selection instruction. It is concise but at the expense of missing crucial parameter details, so it is not a 5.
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 five parameters and low schema coverage, the description should explain the date range semantics (mes1/anio1 to mes2/anio2) and any prerequisites. It does not, and the mention of 'sistema sa_eeff_ifrs' is cryptic. It also fails to reference related tools like cmf_listados_eeff_ifrs for enumerating RUTs or cmf_fechas_divulgacion_eeff for filing dates, making it incomplete for a real workflow.
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% (the sociedades parameter), leaving mes1, mes2, anio1, and anio2 undocumented. The description explains 'Seleccione sociedades por RUT (0=todas)' for the sociedades parameter but says nothing about the four date parameters, their meaning (likely a period range), format, or whether they are required. This is a major gap for an agent trying to construct a valid request.
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 identifies the resource as 'Estados financieros IFRS de sociedades anónimas y otras entidades', clearly indicating it provides IFRS financial statements for corporations and others. This distinguishes it from NCH-based siblings (e.g., cmf_empresa_eeff_nch) and other entity-specific EEFF tools. However, it lacks an explicit verb like 'retrieve' or 'consult', making the action less direct.
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 only usage guidance is 'Seleccione sociedades por RUT (0=todas)', which is a parameter selection instruction, not a when-to-use guideline. There is no mention of alternatives or exclusions, such as 'for non-S.A. entities use' or 'for NCH statements use cmf_empresa_eeff_nch'. The description does not help the agent choose 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the specific reporting standard (NCH/FECU) and entity type, but does not disclose any additional behavioral traits such as required parameter combinations, response format, or limitations, beyond what annotations provide.
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 phrase with no redundant words. It is appropriately sized for a simple tool, though it lacks a verb and is not structured as a complete sentence. It earns a high score for zero fluff, but a slightly lower score due to underspecification.
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 with no descriptions and no required fields, the description should clarify basic usage context (e.g., that period values must be provided and sociedades defaults to '0'). It does not. Although an output schema exists, the lack of input semantics makes the tool incomplete for correct invocation.
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 provides no explanation for any of the 5 parameters. The parameter names (mes1, mes2, anio1, anio2, sociedades) are cryptic, and the description does not compensate by explaining that they represent a period range and list of companies. This is a severe gap for agent usability.
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 identifies the resource: financial statements under Chilean standard (NCH/FECU) for corporations. It distinguishes itself from siblings like cmf_eeff_ifrs_sa by explicitly mentioning NCH/FECU. However, it lacks an explicit verb like 'obtiene' or 'consulta', making it a noun phrase rather than a full action statement.
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 accessing NCH financial statements of Chilean corporations, which provides context but does not explicitly state when to use this tool versus alternatives like cmf_empresa_eeff or cmf_eeff_ifrs_sa. No exclusions or alternative recommendations are 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?
The annotations already declare the operation as read-only and non-destructive, but the description adds no additional behavioral context such as optionality of the year, output format, or scope (e.g., all companies vs. a specific one). The phrase 'por año' merely echoes the schema parameter anio and provides no new insight.
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 with no redundant words, making it easy to read. It is appropriately sized for a simple one-parameter tool.
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?
Although the tool is simple and has annotations and an output schema, the description lacks important context about the scope of the calendar (whether it is global or per-entity) and the effect of the optional year parameter. Given the availability of structured metadata, it remains minimally complete but has clear gaps.
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?
With 0% schema description coverage, the description is expected to compensate, but it only vaguely references 'por año' without explaining the parameter's format, optionality, or behavior when omitted. The schema already defines 'anio' as a 4-digit pattern, so the description adds minimal semantic value beyond what the parameter name implies.
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 defines the tool as a calendar of financial statement disclosure dates organized by year, clearly identifying the resource it provides. However, it lacks an explicit action verb (e.g., 'list' or 'get') and does not directly differentiate itself from other CMF EEFF-related tools, though the specific subject matter is distinct.
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 compared to the many sibling tools, such as cmf_empresa_eeff or cmf_eeff_ifrs_sa. There is no mention of alternatives or exclusions, leaving the agent to infer the use case from the title.
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 and destructiveHint=false, so the safety profile is known. The description adds context about the report content (Boletín de Patrimonio y Rentabilidad) and that data is per mutual fund series, but does not disclose behaviors such as pagination, default date ranges, or handling of missing data.
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, information-dense sentence that avoids fluff and clearly lists the data points included. It is well-structured and easy to parse.
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 names the data fields and the report type, and the output schema likely details the return structure. However, it does not explain the role of parameters or provide selection criteria among mutual fund sibling tools, so it is only moderately complete for an agent.
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 coverage is 0% and the description provides no information about the three parameters (mes, anio, admin). The agent cannot determine the expected format or meaning of these parameters from either source, which is a critical 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 identifies the tool as providing mutual fund data (patrimony, variation, monthly nominal returns, participants, and quota value) by series, distinguishing it from sibling mutual fund tools that focus on cartera, comisiones, etc. However, it lacks an explicit verb like 'retrieve' or 'get', which slightly reduces clarity.
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 explicit guidance is provided on when to use this tool versus alternatives. The description does not name sibling tools or exclude use cases, leaving the agent to infer the tool's purpose from the field list 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the period parameter context but doesn't disclose behavior beyond that (e.g., filtering, default tipo). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no superfluous words, but it is a noun phrase without a verb. It is concise, not efficient in conveying information.
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 4 parameters, 0% schema coverage, and no usage guidance, the description is insufficient for correct invocation. Output schema exists, but the description doesn't clarify parameter semantics, especially the 'consulta' switch, making the tool hard to use 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 descriptions cover 0% of parameters. The description mentions 'nacionales o extranjeros,' which aligns with the 'tipo' enum, but fails to explain 'mes,' 'anio,' or 'consulta' options (fondos/emisores/pais_transaccion). An agent would not know how to construct a correct query.
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 identifies the resource ('inversiones de fondos mutuos') and scope ('instrumentos nacionales o extranjeros por período'), but lacks an explicit action verb like 'consultar' or 'obtener.' It partially differentiates from sibling mutual fund tools by focusing on investments, but doesn't explicitly distinguish from cartera/cartola.
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; no exclusions or prerequisites. The only usage hint is 'por período,' implying time-period filtering, but no context about suitable scenarios.
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 and destructiveHint=false. The description adds the market-wide, date-range scope, which is useful context beyond the annotations. However, it does not disclose other behavioral traits like pagination, response format, or what constitutes a 'resolución' in this context.
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, front-loaded sentence with no unnecessary words. However, its brevity comes at the cost of essential details, making it concise but under-specified.
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 4 optional parameters, an output schema, and no parameter descriptions, the description is far too sparse. It does not explain what the output contains, how to use tipoentidad, nor any limitations (e.g., date range constraints), so the agent lacks enough context 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?
With 0% schema coverage, the description must compensate for parameter meaning, but it only hints at the date range and market. It does not explain 'tipoentidad' at all, and the enum values ('V', 'O', 'S') are undefined, leaving most parameters semantically opaque.
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 the tool returns resolutions for an entire market within a date range, which clearly identifies the resource (resoluciones) and scope (mercado, fechas). It distinguishes itself from entity-specific tools like cmf_empresa_resoluciones, but lacks an explicit verb and is somewhat generic.
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 related tools such as cmf_resoluciones_cursadas or cmf_sanciones_globales, nor does it state any exclusions or prerequisites, leaving the selection decision entirely to the agent.
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 safety with readOnlyHint=true and destructiveHint=false. The description adds that it covers period-based data for general or life insurance companies, but it does not disclose output format, pagination, or any filtering behavior, so the additional context is minimal.
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 with no filler and front-loads the main subject. However, it is perhaps too sparse for a tool with six parameters, but conciseness itself is well-handled.
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 annotations and an output schema, the description does not explain how to construct a period range or what the 'sociedades' parameter does. For a 6-parameter tool with 0% schema coverage, the description is not complete enough.
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 for parameter meaning. It only hints at period ('por período') and type ('generales o de vida'), leaving mes1/mes2/anio1/anio2 semantics and the 'sociedades' filter 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 clearly identifies the resource as financial statements (FECU) of insurance companies and scopes it to general or life insurers by period. This distinguishes it from sibling tools like cmf_empresa_eeff, but it lacks an explicit action verb such as 'obtener' or 'listar'.
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 like cmf_empresa_eeff or other cmf_seguros_* tools. No exclusions, prerequisites, or alternative tool references are given; usage is only implied by the resource type.
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 state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no extra behavioral context—it merely restates the title and does not mention pagination (despite limit/offset params) or any other operational traits, offering no additional value beyond structured data.
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, succinct sentence that directly states the tool's subject. It wastes no words and is easy to scan, though it could arguably be more informative without sacrificing conciseness.
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?
With an output schema present and only two pagination parameters, the tool is relatively simple. The description covers the core purpose but omits any indication of the result format, pagination behavior, or specific use cases, making it minimally sufficient but not complete.
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?
Both parameters (limit and offset) are fully described in the input schema with clear meanings and constraints, so high schema coverage gives a baseline of 3. The tool description adds no parameter-specific details, but this is acceptable given the schema already handles them.
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 identifies the tool as providing transactions of insurance companies under Article 12 of Ley 18.045, which is a specific resource and distinct from sibling tools covering other securities market data. However, it lacks an explicit action verb like 'list' or 'get', reducing clarity slightly.
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 neither mentions the specific use case (e.g., retrieving insider transaction data) nor names any sibling tools to consider instead, leaving the agent without direction.
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 and destructiveHint=false, so the safety profile is covered. The description adds the 'API oficial v3' context and confirms the read-only nature, but does not disclose additional behavioral traits like pagination or filtering 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 a single, front-loaded sentence that directly states the tool's purpose. It contains no fluff or redundant information, making it highly 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?
Given the tool has 3 parameters and 0% schema description coverage, the description is too sparse for an agent to correctly use the tool. It does not mention optional filters, expected input formats, or provide any usage context beyond the basic listing action.
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, but it does not explain the parameters. It does not clarify what 'institucion' should contain (e.g., ID, name, code) or that 'mes' and 'anio' are optional filters. The parameter names are self-explanatory but the description adds no value beyond 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 lists shareholders of a bank/financial institution, using a specific verb and resource. It distinguishes from sibling tools focused on other institution data (e.g., balance, members) by specifying 'accionistas de un banco/institución financiera'.
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. There are many sibling tools (e.g., cmf_empresa_accionistas, cmf_api_integrantes_institucion) that could be confused, but the description does not differentiate them or indicate typical 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?
The description adds no behavioral details beyond the annotations. It doesn't mention pagination behavior, output format (though output schema exists), or any limitations. 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?
One concise sentence that names the resource and lists key fields. 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?
The tool is simple (2 optional params, output schema present), and the description gives the core subject. However, it does not explicitly state that this is a paginated list of all issuer communications, which could lead to ambiguity.
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?
Both parameters are fully described in the schema (limit and offset with descriptions and defaults), so the description need not add param semantics. Coverage is 100%, yielding the baseline 3.
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 is a noun phrase ('Comunicaciones de los emisores de valores') with a field list, but lacks an explicit verb like 'list' or 'get'. It identifies the resource but does not clearly state the operation, making it somewhat vague.
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; there is no mention of filtering, scope, 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=true and destructiveHint=false, so the safety profile is covered. The description adds the scope of meeting types and the reference to 'pestanías 78-80' (tabs 78-80), but this is more contextual than behavioral. It does not disclose pagination, date-range behavior, or response format, but the output schema likely covers return structure. 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 of about 15 words, front-loaded with the core purpose. It contains no redundant phrases or filler, making it highly concise and easy to parse.
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 4 parameters and no schema descriptions, the description is too sparse to be fully self-sufficient. It does not explain the meaning or expected input of date parameters, nor does it clarify the 'pestanías 78-80' reference. While the output schema exists and annotations are provided, the overall lack of usage and parameter guidance leaves the description incomplete.
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 for parameter meanings. It indirectly maps to the 'tipo' parameter by listing the meeting types, but it does not explain 'rut', 'desde', or 'hasta'. Without explicit parameter details, an agent would have to infer that 'desde'/'hasta' are date filters or that 'rut' is the issuer identifier, which 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 the tool is for 'Actas de juntas de accionistas' (shareholder meeting minutes) and specifies the types: ordinary, extraordinary, and statute reform. It identifies the resource as belonging to an issuer, which distinguishes it from generic meeting record tools. However, it lacks an explicit action verb like 'retrieve' or 'get', and does not directly contrast with sibling tools.
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 exclusions or alternative tools (e.g., cmf_empresa_hechos for material events). The only implicit hint is the inclusion of meeting types, which may suggest usage for those specific cases, but there is no explicit instruction 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 declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds no behavioral context such as return format, pagination, rate limits, or access constraints, but given the annotations cover the safety profile, this is adequate though not enriching.
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 short sentence with no filler, immediately stating the core subject. It is front-loaded and every word contributes to the meaning.
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?
For a 5-parameter, 0-required query tool, the one-line description leaves the agent without enough information to construct a query or understand parameter conventions. Although an output schema exists and may cover return values, period selection, moneda codes, and differentiation from sibling tools are missing, making the tool under-specified.
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 40% (admin and tipo_fondo have brief descriptions), and the description does not explain the meaning of mes, anio, moneda, or the special enum values like '$$', 'PROM', and 'EUR'. The phrase 'por fondo/serie' provides domain context but does not map to parameter usage, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the fee structure for mutual funds, listing placement commissions, administration fees, and operating expenses, which distinguishes it from broader sibling tools like cmf_fondos_mutuos_costos or cmf_fondos_comisiones_maximas. However, it lacks an explicit verb such as 'get' or 'list', making it a noun phrase rather than a clear action statement.
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?
There is no guidance on when to use this tool versus closely related siblings like cmf_fondos_mutuos_costos or cmf_fondos_comisiones_maximas. The description does not mention required filters, date ranges, or typical use cases, leaving the agent without selection 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?
The annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the data is 'calculated IFRS' and 'para un corte', implying date-bound derived metrics, but it does not explain potential quirks like the meaning of the default sociedades value or whether it returns all companies when unspecified. This is minimal additional context beyond the 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, compact sentence that front-loads the core resource and includes relevant specific categories (liquidez, endeudamiento, rentabilidad). It avoids unnecessary filler and is easy to scan. Slightly more detail could be added without harming conciseness, but as written it is efficient.
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?
With an output schema present and annotations covering read-only behavior, the description does not need to explain return formats or safety. However, it is incomplete in that it does not mention the 'sociedades' parameter at all, and it does not explicitly state that this tool is for IFRS (as opposed to NCh) beyond the name. This could lead to mis-selection among sibling tools.
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?
Only one of the two parameters (fecha_max) has a schema description, giving 50% coverage. The description does not compensate for the undocumented 'sociedades' parameter; it merely repeats the 'corte' concept from the schema description of fecha_max. The agent receives no guidance on how to use the sociedades array or what the default ['0'] signifies.
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 identifies the tool as providing financial indicators (liquidity, leverage, profitability) calculated under IFRS for corporations (SA) at a specific cutoff date. It distinguishes itself from the sibling tool cmf_indicadores_financieros_nch by explicitly mentioning 'IFRS' and 'SA'. Although it lacks an explicit verb like 'get' or 'return', the intent is 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 provided on when to use this tool versus alternatives such as cmf_indicadores_financieros_nch or cmf_eeff_ifrs_sa. There is no mention of any exclusions, prerequisites, or comparative context. The description is purely a statement of what the tool returns, leaving the agent to infer usage from the name and sibling list.
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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the data comes from the official CMF v3 API and lists the indicators, but it discloses no behavioral details such as response behavior for missing parameters, rate limits, or authorization requirements. The term 'período' is ambiguous.
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 is front-loaded with the core purpose. Every word contributes value, and there is no superfluous content.
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?
While an output schema exists (so return format is presumably handled) and annotations cover safety, the description is incomplete for a 4-parameter tool with 0% schema description coverage. It leaves unclear how 'período' maps to the date parameters and whether all or some combinations are valid. No cross-reference to the series tool is made.
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%. The description does not explain the parameters (dia, mes, anio, serie). It lists indicator names that are already in the schema's enum, and 'fecha o período' only vaguely implies the date parameters. No guidance on parameter combinations or meaning is provided.
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 the value of official economic indicators (UF, dollar, UTM, IPC, etc.) for a specific date or period. It lists the supported indicators, making the resource scope clear. However, it does not explicitly contrast with the sibling `cmf_api_indicador_serie`, so it lacks explicit sibling differentiation.
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 usage guidance is provided. The description doesn't specify when to use this tool versus `cmf_api_indicador_serie` or any other alternative, nor does it explain the meaning of 'period' or how to structure date parameters. There is no indication of whether a full date is required or if partial dates (e.g., year only) are allowed.
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 and destructiveHint=false. The description adds minimal behavioral context by specifying that the result is the annual report for an issuer/year, but it does not disclose auth needs, rate limits, or response behavior beyond what the annotations and output schema already imply.
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, front-loaded sentence with no redundant wording. It conveys the essential purpose and scope immediately, though 'pestanía 49' is slightly cryptic but not wasteful.
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?
For a simple two-parameter read-only tool with an output schema, the description is minimally sufficient to identify the resource. However, it does not clarify parameter relationships or explain the cryptic 'pestanía 49' reference, leaving some contextual gaps.
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?
With 0% schema description coverage, the description must compensate, but it only loosely maps 'emisor' to rut and 'año' to anio. It does not explain optionality (no required params), value formats beyond the regex, or how to use the two parameters together.
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 resource ('memoria anual de un emisor') and the temporal scope ('para un año'), which distinguishes it from financial statements or events among sibling tools. However, it lacks an explicit verb like 'obtiene/retrieves', so it falls short of the strongest purpose statements.
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 instead of related cmf_empresa_* tools, nor are any exclusions or prerequisites mentioned. The phrase 'para un año' implies a filtering use case but does not constitute actionable usage guidance.
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 and destructiveHint=false, so the safety profile is covered. The description adds the date-range scoping and the issuer-specific focus, but does not discuss authentication, pagination, or response details. This modest extra context merits a 3.
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, tightly worded sentence with no filler. It immediately states the content and scope, making it efficient 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?
The tool has a simple read-only purpose with three optional parameters and an output schema. The description is enough for basic understanding, but lacks clarity on parameter optionality and how to exclude dates, which leaves some gaps.
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 mentions 'rango de fechas' which suggests the desde/hasta parameters are dates, and 'emisor' implies rut identifies the issuer, but it never explicitly ties the parameters together. The compensation is thin.
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 sanctions applied to an issuer ('emisor') within a date range. The phrase 'a un emisor' distinguishes it from global sanctions tools like cmf_sanciones_globales, though it does not explicitly name alternatives or use a verb.
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 siblings such as cmf_sanciones_globales or cmf_sanciones_cursadas. It only describes what it returns, leaving the agent to infer usage from 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 and destructiveHint=false, so safety is covered. The description adds the market categories and date-range scope, but does not disclose any additional behavioral traits such as pagination, limits, or required authorizations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose. It avoids unnecessary words, though it is somewhat telegraphic and 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?
Given 4 parameters with no schema descriptions and no guidance, the description is too thin. It omits any mention of the 'tipoentidad' parameter, provides no usage context, and relies entirely on the output schema to fill gaps. The tool is likely a simple read, but the missing parameter documentation makes it incomplete.
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%, so the description must compensate. It clarifies 'desde/hasta' as a date range and explains the mercado enum values (V=valores, O=otros, S=seguros), but it does not mention 'tipoentidad' at all, leaving that parameter unexplained.
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 provides sanctions for an entire market (V/O/S) within a date range, implying a listing/query operation. It distinguishes from sibling tools by emphasizing 'todo un mercado' versus company-specific sanctions, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, exclusions, or mention of alternative tools like cmf_empresa_sanciones or cmf_sanciones_cursadas. The market and date range are implied but not framed as selection 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the context of 'reseñas' (reviews) and period-based filtering, but does not explain behavioral details like pagination, data range limits, or what 'reseñas' entails. 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 a single concise sentence that immediately states the tool's purpose. It is well-structured and front-loaded, with 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?
The description gives the core purpose and implies the period filter, but fails to provide usage differentiation or parameter details. The presence of an output schema reduces the need to document return values, but the description still feels thin for an agent selecting between many related tools.
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%, and the description does not explain the meaning or format of 'mes' and 'anio'. It only implies period filtering via 'por período', leaving the parameter semantics to the schema's property names and regex patterns.
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 identifies the tool as providing risk classification and reviews for insurance companies by period, which distinguishes it from the sibling cmf_clasificaciones_riesgo. However, it lacks an explicit verb like 'lista' or 'obtiene', making the action implied rather than stated.
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 cmf_clasificaciones_riesgo or other seguro-specific tools. There are no exclusions or alternative recommendations.
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 and destructiveHint=false, covering the safety profile. The description adds the 'API oficial v3' context and the fields returned, but does not disclose additional behavioral traits such as data availability, error handling, or parameter dependencies. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the resource and scope. Every word contributes to understanding the tool's purpose.
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 presence of an output schema and annotations covers return values and safety, reducing the burden on the description. However, the description is sparse: it does not explain the optional month/year parameters or explicitly differentiate from the many sibling institution tools. This leaves a moderate gap in context.
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 compensate. It fails to explain whether 'mes' and 'anio' are required for a ficha (which seems static) or the expected format of 'institucion'. Agents receive no guidance on parameter meaning beyond the raw 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 identifies the tool as providing a 'ficha' (record) for a bank/financial institution and lists specific fields (address, subsidiaries, executives), which distinguishes it from sibling tools like balance or resultados. However, it lacks an explicit verb such as 'get' or 'returns', making it a noun phrase rather than a direct command.
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 is given on when to use this tool versus alternatives. The listed contents (domicilio, filiales, ejecutivos) imply it is for basic institution data, but no exclusions or alternative tool names are mentioned. This is implied rather than stated.
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 and destructiveHint=false, so the safety profile is clear. The description adds useful context about the period and tab reference, but does not describe return format, pagination, or other behavioral traits beyond what annotations already convey.
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, concise and front-loaded with the key resource type. No unnecessary words or repetition of title or schema 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?
Given the tool has three optional parameters, an output schema, and many sibling tools, the description is too terse. It does not explain what specifically constitutes 'filiales', how this differs from cmf_empresa_eeff_historial or cmf_empresa_eeff_nch, or how to frame a correct query. The output schema helps with return structure, but the description leaves the agent without adequate context for tool selection.
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 mentions 'período' and 'emisor', which hints that mes/anio and rut correspond to the period and issuer, respectively. However, with schema description coverage at 0%, the description should offer more explicit parameter meaning. The parameter names themselves are somewhat self-explanatory, but the description does not fully compensate for the lack of schema descriptions.
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 identifies the resource: financial statements of subsidiaries (filiales) for an issuer and a period. The phrase 'pestanía 33' adds a specific reference, and the use of 'filiales' differentiates it from parent-level EEFF tools like cmf_empresa_eeff, though not explicitly naming alternatives.
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 other EEFF-related tools, nor does it mention any exclusions, prerequisites, or context such as regulatory requirements. Users must infer usage solely from the name and the term 'filiales'.
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, so the safety profile is known. The description adds that it is monthly and supports market filtering, but it does not explain 'portada de sanciones' or any pagination or formatting behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but the phrase 'portada de sanciones' is ambiguous. It is concise and front-loaded, but could be clearer.
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 documented elsewhere. However, the description lacks context on what 'cursadas' means specifically and does not explain the market codes, making it minimally complete for a simple 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 single parameter 'mercado' is self-explanatory and the description reinforces 'por mercado'. However, with 0% schema description coverage, the enum values V, O, S are not explained, leaving some ambiguity about what each market code represents.
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 identifies the tool's purpose: retrieving monthly processed sanctions and a sanctions cover by market. The resource and scope are clear, but it does not explicitly distinguish it from sibling tools like cmf_sanciones_globales.
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 simply states what it does without any context on prerequisites, exclusions, or which sibling tool to choose for different scenarios.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral details such as pagination semantics, data coverage, or rate limits, providing no additional transparency beyond the 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 redundancy or filler, front-loading the key acronym and its expansion. It is appropriately sized for a simple read-only stats tool.
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 tool has low complexity: read-only annotations, full schema descriptions for its two pagination parameters, and an output schema defining the return structure. The one-line description is sufficient to convey the primary purpose, though it doesn't elaborate on the nature of the statistics beyond the system name.
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 includes descriptions for both limit and offset, achieving 100% coverage, so the baseline of 3 applies. The description does not add any extra parameter context, but none is needed given the schema's clarity.
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 identifies a specific resource (SCOMP system) and the type of data (statistics), which distinguishes it from sibling tools about other insurance/pension topics. However, it uses a noun phrase without an explicit verb like 'list' or 'retrieve', so it is clear but not as action-oriented as ideal.
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?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites mentioned. The description only states what the tool provides, so usage must be inferred from the tool name and 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 (readOnlyHint=true, destructiveHint=false) already establish this as a safe read operation. The description adds context about the source tab ('pestanía 25') and the included fields (document number and download link), but does not disclose pagination behavior, rate limits, or ordering. With the annotations bearing the safety burden, the description provides moderate additional 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, compact sentence that conveys the essential information without unnecessary words. It front-loads the core purpose and includes the key detail about the download link, making it easy to parse.
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?
With an output schema present, the description need not explain return values, but it does not clarify that all parameters are optional or how to structure typical queries (e.g., by RUT alone, by date range only). This leaves the agent uncertain about query flexibility. A more complete description would state that 'rut' may be omitted for global searches or provide an example.
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 schema covers only 40% of parameters (limit and offset have descriptions), while rut, desde, and hasta lack descriptions. The description partially compensates by revealing that data is filtered by emitter ('emisor') and date range ('rango de fechas'), which clarifies rut and the date fields. However, it does not explicitly map each parameter or explain edge cases, leaving some ambiguity for a low-coverage 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 identifies the tool's purpose: retrieving essential facts ('hechos esenciales') published by an issuer within a date range, including document number and download link. It distinguishes itself from sibling tools like sanciones, resoluciones, and juntas by naming the specific data type. However, it lacks an explicit verb like 'obtener' or 'listar', making it slightly less direct.
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 cmf_hechos_globales or other empresa-specific tools. The description alludes to date-range queries and issuer context, but there are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage from sibling tool names.
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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond annotations by detailing that the result is a Google Visualization grid converted to JSON and structured as a matrix of accounts × funds. This clarifies the return format, though it does not discuss limits or permissions beyond what annotations imply.
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, tightly written sentence with a colon introducing the key detail. Every element earns its place: the resource, the structure, and the format conversion. No filler or repetition exists, making it highly efficient.
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 provides the core purpose and output structure, which is adequate for a simple read-only tool with an output schema. However, it omits essential context about the date parameters, defaults, and when to use the tool, leaving gaps that might require the agent to infer from schema or sibling names. For a 6-parameter tool, more guidance would be expected.
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%, with mes1, mes2, anio1, anio2 lacking descriptions. The tool description does not compensate for this gap; it never explains that these are start/end months and years or how they relate to the date range. The parameter names are suggestive but provide no explicit semantics, and the description adds no parameter-related value.
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 identifies the resource as IFRS financial statements of investment funds and specifies the structure as an accounts × funds matrix. It distinguishes from sibling tools by naming 'fondos de inversión' and the grid format, but it lacks an explicit action verb like 'retrieve' or 'list', making the purpose slightly implicit.
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, such as when considering cmf_fondos_mutuos_* tools or cmf_eeff_ifrs_sa. No context is given about typical use cases, exclusions, or complementary tools. The only implied usage is from the name and resource type.
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 and non-destructive. The description adds context about the two available categories (AV/CB and NCH issuers) but does not disclose other behaviors such as pagination, date ranges, or output structure. It does not contradict the 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 concise sentence that directly states the resource. It contains no filler, repetition, or extraneous details.
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's simplicity (one optional parameter, read-only, output schema present), the description is minimally adequate. However, it lacks usage guidance and explicit parameter documentation, leaving some gaps for agents unfamiliar with the domain.
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 schema has one parameter 'tipo' with an enum, but no parameter descriptions. The tool description mentions both categories, which helps interpret the enum values, but it never explicitly ties the parameter to those categories. With zero schema description coverage, the description only 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 clearly identifies the resource: result tables for securities agents/stockbrokers and issuers under NCH. It distinguishes from sibling tools by specifying the exact scope. Although it lacks a verb, the noun phrase effectively communicates the tool's output.
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 alternatives. It does not mention exclusions, related tools, or prerequisites. The intended use is only implicit from the domain-specific phrasing.
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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context such as pagination behavior, return format specifics, or any operational details. It merely restates the query nature without enriching beyond the 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, clear sentence with no filler words. Every word contributes to understanding the tool's purpose, making it highly concise and appropriately structured.
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 simplicity of the tool (2 well-documented params, output schema present, and read-only annotations), the description minimally covers the core purpose. However, it lacks usage guidance and any additional context about how this fits with the broader CMF toolset, leaving a clear gap for agent selection.
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 100%, with both 'limit' and 'offset' fully described. The description adds no parameter-specific meaning, so the baseline of 3 applies since the schema does all the heavy lifting.
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 'Consulta' with a specific resource 'siniestros detectados no reportados por compañías de seguros', clearly distinguishing it from sibling tools. The title reinforces the exact scope, leaving no ambiguity about what the tool does.
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 simply states the purpose without any context about use cases, exclusions, or related tools. There is no mention of when not to use it or prerequisites.
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 include destructiveHint=true, indicating this operation has side effects. The description's 'Envía una consulta' aligns with this by implying an external submission, but it adds little beyond the annotation. It does not contradict the annotation, so a score of 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, concise sentence that immediately conveys the tool's action and subject. It is efficient without unnecessary detail, though it lacks any structured breakdown of usage or parameters.
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?
For a simple form submission, the description is adequate to understand the core function, and an output schema exists to document return values. However, it omits any mention of prerequisites, delivery methods, or expected response time, leaving some contextual gaps for a tool with side effects.
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 provides no information about any of the five parameters. The parameter names like 'nombre', 'email', and 'mercado' are partially self-explanatory, but the description fails to clarify their purpose or required format, leaving the agent without added value beyond raw schema 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 uses a specific verb ('Envía') and identifies the resource (a query to CMF about XBRL usage) and context (technical support). It clearly distinguishes this tool from sibling tools that fetch data, such as cmf_xbrl_taxonomias or cmf_xbrl_visor.
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 purpose implies it is used for technical support inquiries about XBRL, but it does not explicitly state when to use it versus alternatives or mention any exclusions. No alternative tools are referenced, leaving usage guidance implied rather than 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is established. The description adds the date-range scoping and the 'pestanía 37' context, but does not disclose behavior about optional parameters or pagination. 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, front-loaded sentence that is free of any filler or redundant information. Every word contributes to conveying the tool's purpose.
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 three parameters with no descriptions in the schema and an ambiguous 'pestanía 37' reference. The description does not address the optionality of parameters or the relationship to sibling resolution tools, making it under-specified for fully correct invocation.
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?
With 0% schema description coverage, the description adds high-level meaning by identifying 'emisor' (rut) and 'rango de fechas' (desde/hasta). However, it does not clarify that all parameters are optional or explain how the date range boundaries are applied, leaving gaps.
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 identifies the tool as providing CMF resolutions about a specific issuer within a date range, distinguishing it from global resolution tools. However, it lacks an explicit verb such as 'list' or 'get', relying instead on a noun phrase.
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 phrase 'sobre un emisor' implies the tool is intended for issuer-specific resolution queries, which offers some contrast to global resolution tools like cmf_resoluciones_globales. There is no explicit guidance on when to use this tool over alternatives or any 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=true and destructiveHint=false, so the safe read-only nature is clear. The description adds content details (types of costs) but does not disclose additional behavioral traits such as filtering behavior, series selection, or any output limitations beyond what the annotations 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?
The description is a single, focused sentence that packs meaningful detail about the tool's content without extraneous words. It is front-loaded with the primary noun and immediately specifies the output components.
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 is a simple read-only query with an output schema, and the description covers the domain. However, the missing parameter semantics and the lack of usage context mean the description is not fully complete for an agent to confidently invoke it without additional schema or examples.
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 three parameters (mes, anio, admin). Even though the schema includes patterns for month and year, the description fails to clarify their semantics or how 'por serie' relates to the admin parameter, leaving an agent without enough information to construct a valid query.
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 this tool provides a statistical table of mutual fund costs, specifying the exact components (remuneración fija/variable, gastos de operación, and TAC) and the grouping by series. This distinguishes it from sibling tools focused on portfolios, commissions, or investments.
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?
There is no guidance on when to use this tool versus alternatives. The description only defines the output, without mentioning exclusions or the specific conditions under which this cost table is the appropriate choice compared to sibling mutual fund tools.
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 read-only and non-destructive behavior. The description adds valuable behavioral context about the captcha: if no captcha is provided, the tool responds with an input request for the agent to ask the user, and notes that the captcha is a 6-character image. This goes beyond annotation data and helps the agent anticipate interactive 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 three sentences long and front-loads the main purpose. Each sentence adds information: the core function, the captcha requirement and interactive behavior, and the captcha's format. It is concise but could be slightly tighter with wording, yet remains effective.
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 5-parameter schema with all optional fields and an output schema present, so return structure is covered. However, the description omits details such as date range semantics, meaning of market codes (V, O, S), and acceptable entity types. The captcha flow is well explained, but the other parameters are left ambiguous, creating gaps for an agent trying to make optimal use of the 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?
Schema coverage is only 20%, with only 'captcha' having a description. The description explains the captcha parameter in detail but leaves 'desde', 'hasta', 'mercado', and 'tipoentidad' unexplained. The phrase 'o de un tipo de entidad' hints at 'tipoentidad' but does not specify valid values or usage, so the description does not compensate adequately for low schema coverage.
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 provides 'hechos esenciales' for the entire market or by entity type, which conveys its main function and scope. It distinguishes itself from entity-specific tools like cmf_empresa_hechos by emphasizing 'globales' and 'todo el mercado', though it does not name alternatives explicitly.
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?
Usage is implied by the description: it is for querying global market facts, possibly filtered by entity type. However, it does not explicitly say when to use this tool versus alternatives like cmf_sanciones_globales or cmf_empresa_hechos. The captcha requirement is a practical usage constraint but not a usage guideline.
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 declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds that it provides 'estructura de etiquetas' (label structure), which is some behavioral context, but does not describe output format, pagination, or any constraints beyond what the schema shows.
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 that directly states the tool's purpose with no redundant words, making it appropriately concise and front-loaded.
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 tool has just two required parameters, both well-defined in the schema, and an output schema exists, so the description does not need to explain return values. The description adequately covers the tool's function, though it would be improved by noting its relationship to the sibling taxonomy tools.
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 schema has coverage for 'fecha' with an example and the 'taxonomia' parameter is defined by an enum, so the schema does most of the work. The description mentions both parameters ('por taxonomía y fecha de versión') but does not add details about value meanings or interactions, so it offers marginal added value.
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 the verb 'Navega' (navigates) and specifies the resource as an XBRL taxonomy from CMF, with scope of label structure by taxonomy and version date. This is clear and specific, but it does not explicitly differentiate from sibling tools like cmf_xbrl_taxonomias or cmf_xbrl_consulta, so a 4 rather than 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 gives no guidance on when to use this tool versus alternatives like cmf_xbrl_taxonomias or cmf_xbrl_consulta. There is no mention of exclusions or preferred contexts, leaving the agent to infer usage 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 declare readOnlyHint=true and destructiveHint=false, which covers safety. The description adds context about the monthly scope and the Circular 1333 column codes, but it does not disclose behaviors such as pagination, rate limits, or what happens if the optional month/year filters are omitted. This is moderate 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 sentence that is front-loaded with the core resource and provides the key breakdown of portfolio types. Every phrase earns its place with no redundant or filler content.
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 output schema exists, so return values are covered. However, the description does not explain how this tool differs from other fondos mutuos tools, nor does it address the optional mes/anio parameters. For a simple read-only tool this is adequate but incomplete for an agent to confidently select it among siblings.
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?
With only 33% schema description coverage, the description should compensate for the undocumented mes and anio parameters. It mentions 'por mes' and repeats the cartera enum values, but it does not clarify the role or optionality of mes/anio. This is a partial, not full, compensation for the low coverage.
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 identifies the resource (Cartera de inversiones de fondos mutuos) and the time dimension (por mes), as well as the specific types of portfolios (nacional, extranjera, opciones, etc.). Although it lacks an explicit verb like 'obtener' or 'listar', the intent is unambiguous and it is distinct from sibling tools like catálogo or inversiones.
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 this tool is for retrieving monthly mutual fund portfolio data by type, but it does not explicitly state when to use this tool over alternatives such as cmf_fondos_mutuos_inversiones or cmf_fondos_mutuos_cartola. No exclusions or alternative tools are mentioned.
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 and destructiveHint=false, so the safety profile is covered. The description adds context about the data content (capital adequacy components) but does not disclose behavioral details such as handling of institution code 999 or potential empty results. This is acceptable given the read-only nature and existing 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, focused sentence with a parenthetical list, making it concise and front-loaded with the resource name. It could be improved by starting with an explicit verb, but it is efficiently sized with no wasted 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?
For a read-only data query tool with an output schema, annotations, and 5 parameters, the description sufficiently defines the scope and the meaning of key enums. It lacks explicit usage guidance but is otherwise complete enough for an agent to correctly select and invoke the tool.
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 description maps the enum values of 'componente' to human-readable financial terms (activos ponderados, límites, patrimonio efectivo, IRE/IRS) and clarifies that 'indicador' is relevant only when 'componente=indicadores'. This adds meaning beyond the terse schema descriptions, though mes/anio are left to pattern interpretation.
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 identifies the specific resource (capital adequacy components/indicators of financial institutions) and lists examples (activos ponderados, límites, patrimonio efectivo, IRE/IRS), which distinguishes it from sibling institutional data tools. However, it lacks an explicit verb like 'get' or 'query', making it slightly less action-oriented.
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 does not explicitly state when to use this tool versus alternatives, nor does it name exclusions. The domain-specific wording implies its use for capital adequacy data, but an agent would have to infer this from context rather than receive direct guidance.
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 annotations already declare the operation as read-only and non-destructive. The description adds useful context by specifying the monthly granularity and the special meaning of institucion=999, but it does not disclose any additional behavioral details such as response formats or rate limits, which are less critical given the output schema and read-only annotation.
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 short sentences, front-loaded with the core purpose and a key parameter tip. No redundancy or extra verbosity.
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?
For a simple read-only query tool with an output schema and three parameters, the description conveys the essential information: what data is returned, the granularity, and a special parameter value. It does not explain return structure, but the output schema covers that.
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 schema has no descriptions for the three parameters, and the description only explains the special value 999 for 'institucion'. It does not elaborate on the general meaning of the institution code or the format of mes/anio, though the regex patterns provide some guidance. This is partial compensation for the low schema coverage.
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 identifies the tool as returning the monthly income statement ('Estado de resultados mensual') for financial institutions from the official v3 API, distinguishing it from sibling tools like balance or ficha. However, it lacks an explicit action verb, relying on the noun phrase to convey 'gets'.
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 related tools such as cmf_api_balance_institucion. The only usage hint is the special value 999 for the total financial system, which is more about parameter input than tool 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context about the data sources (memoria integrada, SASB, XBRL SASB), but does not disclose more behavioral details such as return format, pagination, or required permissions.
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, well-structured sentence that front-loads the core purpose and lists the data types. 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?
Output schema exists and annotations are adequate, but the description does not explain how to specify the issuer (rut) or time period (mes/anio). Given the simplicity of the query and self-explanatory parameter names, it is minimally viable but not fully complete.
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 25%, with only tipo_informe documented. The description partially aligns with tipo_informe values (memoria integrada, SASB, XBRL SASB) but does not explain mes, anio, or rut. Although parameter names are somewhat self-explanatory, 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 tool provides ESG (environmental, social, governance) indicators for an issuer, naming specific report types (integrated report, SASB, XBRL SASB) and the 'pestaña 110' scope. This distinguishes it from sibling company-data tools like cmf_empresa_info or cmf_empresa_eeff.
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 gives context (per issuer, tab 110) but does not explicitly state when to use this tool versus related alternatives (e.g., other company indicators or XBRL tools). No exclusion or alternative guidance is provided.
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 and destructiveHint=false, so the safety profile is clear. The description adds that it includes IFRS modality (aviso de inicio), but it does not disclose behavior when 'rut' is omitted (the schema shows it as optional) or any other nuances. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of superfluous text. It effectively communicates the core purpose without wasting 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 tool is simple with one optional parameter and an output schema, so return values are covered. However, the description leaves ambiguity about what happens when 'rut' is not provided (does it list all issuers?) and lacks explicit linkage between the parameter and the described behavior. This is a moderate gap for a read-only 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 schema has one parameter 'rut' with no description, and schema description coverage is 0%. The description mentions 'un emisor' but does not explicitly state that the 'rut' parameter identifies that emisor or how to use it. With zero coverage, the description was expected to compensate, but it does not.
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 a specific action ('Lista') and a precise resource ('los períodos (años y cortes) para los que un emisor tiene estados financieros publicados'). It also adds the extra detail of IFRS modality, distinguishing it from sibling tools like cmf_empresa_eeff that likely return the actual financial statements.
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 it should be used when needing available periods for a specific issuer, but it does not explicitly state when to use this tool versus alternatives such as cmf_empresa_eeff or cmf_empresa_eeff_nch. No exclusions or prerequisite steps are mentioned, leaving the usage guidance somewhat implicit.
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 adds that queries are by period, which aligns with the readOnlyHint and destructiveHint annotations. However, it does not disclose pagination, authorization, or output specifics. Since annotations already indicate a safe read operation, the description adds only modest context and does not contradict the 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 concise sentence under 20 words, front-loaded with the tool's purpose and free of any filler or redundant detail.
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 gives a basic purpose and period scope, but lacks guidance on selection among the many seguros-focused siblings and does not explain what the SIC statistics represent. The existence of an output schema helps cover return values, but the description remains thin for a tool with 2 parameters and read-only behavior.
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%, and the description only mentions 'por período' (by period), which loosely connects to the 'desde' and 'hasta' params. It does not clarify which parameter is the start or end date, nor that they are optional, leaving the meaning incomplete.
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 states a specific verb ('consultas') and resource ('pólizas de seguros') within the 'Conoce tu seguro' (SIC) system, clearly distinguishing it from other seguros-related sibling tools. The scope of 'por período' adds further specificity.
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 retrieving SIC statistics by period but provides no explicit guidance on when to use this tool versus other seguros siblings (e.g., cmf_seguros_siniestros, cmf_seguros_eeff). No alternatives or exclusions are mentioned.
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 and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context (e.g., pagination, scope, or rate limits), which is acceptable given the annotations but does not go beyond them.
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 that front-loads the core purpose and list variants with no redundant text. It is optimally concise for the information conveyed.
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 low complexity (1 optional parameter, output schema present, read-only annotations), the description is appropriately complete. It explains the tool's purpose and list types, while the output schema handles return-value details. A note about the default parameter value would be nice but is not critical.
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 schema has one parameter (tipo_listado) with enum values but zero descriptions. The description compensates by naming the list types (general, Circular 556, oficios 457/485), which aligns with the enum values and gives them meaning. However, it does not explicitly map them to the parameter, leaving a small 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 the tool provides lists of companies presenting IFRS financial statements, enumerating specific list types (general, Circular 556, oficios 457/485). This differentiates it from siblings focused on individual company data, though it lacks an explicit verb like 'retrieve' or 'list'.
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 lists of IFRS-reporting companies are needed, but it offers no explicit guidance on when to choose this tool over alternatives such as cmf_listar_entidades or cmf_eeff_ifrs_sa. No exclusions or alternative recommendations are provided.
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 and destructiveHint=false, covering the safety profile. The description adds context about data being 'por compañía' and the types of statistics, but does not disclose behavior like pagination or output format. This matches the expected baseline with annotations present.
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 with a parenthetical list, front-loaded with the key term 'Estadísticas'. No wasted 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 tool has a rich schema (100% param descriptions), output schema, and annotations. The description adequately explains what the tool returns and at what granularity. It could mention that 'codigo' is required or that limit/offset control pagination, but those are already in the schema, so the description is sufficiently complete.
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?
Schema descriptions cover all parameters (100%), so the baseline is 3. The description adds value by explaining the domain of the 'codigo' parameter (commissions, premiums, interest rates, rankings) and indicating company-level breakdown, which helps map the example codes to real meanings.
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 specifies the resource ('mercado de rentas vitalicias previsionales por compañía') and enumerates content ('comisiones, primas, tasas de interés, rankings de asesores'), which distinguishes it from sibling seguros tools. However, it lacks a direct verb like 'obtener' or 'consultar', making it slightly less action-oriented than ideal.
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: use this tool when you need statistics about rentas vitalicias. However, it does not explicitly state when to use it over alternatives or provide exclusions, so guidance is only implicit.
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 and destructiveHint=false. The description adds the data source (SBIF servlet) but no behavioral details such as pagination, filtering, or response format. With annotations covering the safety profile, this is acceptable but not informative.
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, clear sentence that immediately communicates the tool's purpose without any unnecessary words or redundancy.
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?
For a simple read-only tool with one optional parameter and an output schema, the description is adequately complete. The only minor gap is the inconsistency between 'bancos' in the name and 'instituciones financieras' in the description, which could be clarified.
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 schema fully describes the single parameter 'indice' with a default value and description. The tool description adds no extra meaning about the parameter, but schema coverage is 100%, so the 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 states 'Buscador de tasas de interés de instituciones financieras' which clearly identifies the action (search) and resource (interest rates). It also mentions the SBIF InfoFinanciera servlet, adding specificity that distinguishes it from other bank-related tools like cmf_bancos_cronologia.
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 its use for finding interest rates of financial institutions but provides no explicit guidance on when to prefer it over alternative tools like cmf_bancos_reportes or cmf_indicadores_financieros_sa. It lacks exclusions or alternative names.
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 destructiveHint=false. The description adds valuable behavioral context: data is cached for 24 hours, responses are paginated, and the raw dump is never returned. This goes beyond what annotations provide and helps set expectations about response size and freshness.
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, front-loaded with the main purpose, and every phrase adds value: entity catalog, record count, filters, caching, and pagination. There is no redundancy or wasted 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?
Given the presence of an output schema and annotations, the description covers essential operational aspects: filters, caching, and pagination. It omits return format details, but those are presumably in the output schema. The 24h cache and anti-raw-dump notes are particularly useful for agents managing expectations.
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 only 40% (limit and offset), leaving nombre, tipo_entidad, and estado without schema descriptions. The description clarifies that these three parameters act as filters, which is useful, but it does not specify matching behavior (e.g., exact vs partial) or the meaning of estado values beyond the enum.
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 identifies the resource as a catalog of all CMF supervised entities, with filters by name, type, and status. It lacks an explicit verb like 'list' or 'search' and does not distinguish itself from sibling tools such as cmf_buscar_entidad, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching filtered, paginated views of the full catalog, but it does not explicitly state when to prefer it over alternatives like cmf_buscar_entidad or cmf_listar_entidades. No exclusions or alternative comparisons are provided.
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 and destructiveHint=false. The description adds that the data is a historical annual series as of December and lists the included metrics, but it does not disclose parameter optionality, default behavior when anio is omitted, or pagination/result 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?
The description is a single, front-loaded sentence that efficiently conveys the resource, the historical nature, and the key fields with no filler or redundancy.
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 tool is simple (one optional parameter, output schema present) and the description covers the core data content and time dimension. Minor gaps remain around the optional anio behavior, but the description is otherwise sufficient for an agent to select and invoke the 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?
Schema coverage is 0%, so the description must compensate. It clarifies that the data are year-end values ('por diciembre de cada año'), which aligns with the anio parameter, but it never explicitly states that anio filters by year or that omitting it returns the full series.
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 identifies a specific resource and scope: 'Serie histórica de antecedentes generales del sistema de fondos mutuos' and enumerates the exact data fields (número de administradoras, fondos, patrimonio total y partícipes). This clearly distinguishes it from sibling tools that focus on individual fund catalogs, portfolios, or fees.
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 retrieving aggregate historical mutual fund system indicators, but it does not explicitly state when to choose this over alternatives such as cmf_fondos_mutuos_catalogo or cmf_fondos_mutuos_cartera, nor does it mention exclusions or that the anio parameter is optional.
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 and destructiveHint=false, so the safety profile is known. The description adds that it returns a summary per section rather than full details, which is useful behavioral context, but it does not disclose other traits like default section selection or row limits.
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 the core value proposition, and includes a practical pointer to alternative tools. No wasted words, appropriately sized for an aggregation tool.
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 moderate parameter set (4 params, none required) and an output schema, so the description need not detail return values. However, it omits important invocation details such as that secciones is an array with specific allowed values, that max_filas caps rows per section, and how month/year defaults behave. It is minimally viable but has clear gaps.
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 identifies some content types (BPR, costos, comisiones, inversiones) but does not explain the mes/anio format, the full set of secciones enum values, or the meaning/effect of max_filas. This is insufficient given the complete lack of schema descriptions.
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 provides a single call for monthly mutual fund bulletins (patrimonio/rentabilidad, costos, comisiones, inversiones), and distinguishes itself from the individual sibling tools by offering a summary per section. Though the verb is implicit, the scope and aggregation behavior are concrete.
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 says to use the individual tools for full detail, implying this tool is for aggregate summaries. This provides direct comparison with alternatives, though it could be more explicit about exactly when to prefer this over the separate tools (e.g., 'when you need multiple sections in one call').
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?
Sin anotaciones, la descripción asume la carga. Menciona el rango temporal (desde abril de 2009) y los campos devueltos (número, fecha, póliza afectada, materia y archivo), lo cual es útil; sin embargo, no aclara si requiere autenticación, si hay límites de actualización, o el significado exacto de 'archivo' ni el comportamiento con resultados vacíos.
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?
El texto es breve, de dos oraciones, con la información esencial al frente: propósito, temporalidad y campos de retorno. No hay relleno ni repetición del nombre.
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?
Para una herramienta de listado con solo parámetros de paginación y sin esquema de salida, la descripción cubre propósito, alcance temporal y campos devueltos. No obstante, no detalla el significado de 'archivo' ni el comportamiento de ordenamiento/vacíos, lo que impide un 5.
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?
El esquema ya documenta ambos parámetros (limit y offset) con descripciones y límites, por lo que la cobertura es 100%. La descripción no aporta semántica adicional sobre ellos, manteniendo la línea base.
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?
La descripción identifica con precisión el recurso y la acción: lista resoluciones de la CMF que prohíben depósito de pólizas. El verbo 'Lista' y el alcance 'que prohíben a una aseguradora depositar pólizas' lo distinguen de herramientas hermanas como cmf_seguros_deposito_polizas.
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?
La descripción indica claramente qué hace, pero no ofrece guía explícita sobre cuándo usar esta herramienta frente a alternativas como cmf_seguros_deposito_polizas ni menciona exclusiones o casos en que no corresponde. El uso queda implícito por el propósito mismo.
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 destructiveHint=false, so safety is covered. The description adds behavioral context about date range support and variants (previous/posterior to a date), which goes beyond the schema. However, it does not mention output format or pagination, but the existing output schema mitigates the need.
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, front-loaded sentence that clearly states the purpose and enumerates indicators without unnecessary words. Every phrase earns its place and is easy to parse.
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 is adequate for a simple read-only retrieval tool with output schema and annotations, but the 'variantes anteriores/posteriores a una fecha' phrase is ambiguous and could confuse an agent. It also lacks explicit guidance on which parameters are required or how this tool relates to cmf_api_indicador_valor.
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 0% and the description partially compensates by clarifying that 'serie' refers to the indicator and from/to parameters are years/months. It does not explain exact parameter formats (beyond the schema pattern) or the vague 'variantes anteriores/posteriores' concept. The enum list is already in the schema, so the description adds limited new meaning.
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 provides the historical series of an indicator and enumerates the supported indicators (UF, dólar, euro, etc.). It also specifies the scope (range of years/months) and mentions variants, which distinguishes it from the sibling tool cmf_api_indicador_valor that likely provides current values.
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 for historical indicator data versus a current-value tool, but it does not explicitly state when to use this tool instead of alternatives or mention any exclusions. The context signals and sibling names suggest a distinction, but no direct guidance is given.
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 destructiveHint=false; the description adds valuable operational context: 'Requiere captcha de la CMF: si no se entrega, la tool lo solicitará.' This discloses an authentication/verification requirement and the tool's fallback behavior. 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 two sentences: the first front-loads the core function and data fields, the second adds the essential captcha requirement. No filler or redundant material.
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 presence of an output schema and read-only annotations, the description covers the key operational caveat (captcha) and scopes the query to a date range and fund. It does not need to describe return values because the output schema exists.
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 only 25% (only 'fondo' is described as RUN del fondo). The description helps by indicating the tool operates over a 'rango de fechas' and that captcha may be requested, but it does not individually explain 'desde'/'hasta' or the captcha field beyond the schema's regex/length constraints.
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 identifies the tool as returning a daily cartola (valor cuota, patrimonio, partícipes) for a mutual fund over a date range, which distinguishes it functionally from sibling fund tools. However, it is a noun phrase rather than an explicit verb+resource statement, so it falls short of the strongest purpose clarity.
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 needing daily fund data over a date range and notes the captcha requirement, but it does not explicitly state when to choose this over alternatives like cmf_fondos_mutuos_cartera or cmf_fondos_mutuos_bpr. No exclusions or alternative comparisons are provided.
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 and destructiveHint false, so the safety profile is established. The description adds useful context about the special value institucion=999 and optionality of cuenta, but does not disclose pagination, response format, or other runtime behaviors, which is acceptable given the read-only annotation coverage.
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 three concise sentences: the first states the purpose, the second explains a special parameter value, and the third clarifies optionality. No filler words; every sentence contributes essential 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?
The description is sufficient for a simple read-only query with an output schema provided. It covers the main parameters and special values, but leaves unclear whether mes and anio are required together or if the API can be called with no parameters, which is a minor gap.
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?
With 50% schema description coverage, the description partially compensates by explaining the key parameter institucion (999 = total financial system) and clarifying that cuenta is optional. It does not elaborate on mes/anio, but their regex patterns are defined in the schema, so the description adds meaningful value for the less obvious 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?
The description clearly states the tool provides 'Balance mensual de instituciones financieras (bancos)', identifying it as a monthly balance data retrieval tool. It distinguishes from sibling tools like ficha_institucion or resultados_institucion by specifying the resource type 'balance' and notes the special institucion=999 value.
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 gives context about the institution code (999 = total system) and optionality of cuenta, but does not explicitly state when to use this tool over alternatives or any exclusions. Usage is implied (when balance data is needed), but no alternative tools are mentioned.
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 destructiveHint=false. The description adds valuable behavioral context: it returns the canonical RUT, razón social, entity type, and status, and specifies the search inputs. This goes beyond the annotations by explaining what the tool outputs and its role in the workflow, though it does not cover potential edge cases like no results or pagination.
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 three sentences long, with each sentence serving a distinct purpose: what it does, what it returns, and when to use it. There is no redundant filler or repetition of schema details. It is concise and well-structured.
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 is a search/discovery tool with an output schema, so the description need not detail return values. However, it omits clarification on the purpose of the 'term' and 'limite' parameters, and given the large sibling list, it could explicitly distinguish from cmf_listar_entidades or cmf_empresa_info. The 'first step' guidance helps but the parameter ambiguity leaves the description incomplete for seamless 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?
The description adds little beyond the schema. It repeats that search is by 'nombre, RUT o ticker', which is already in the schema's description for 'consulta'. However, it does not clarify the purpose of the 'term' parameter (described only as 'Alias de consulta') nor explain the 'limite' parameter. With 67% schema coverage, the description fails to resolve the ambiguity between 'term' and 'consulta', leaving the agent confused about which parameter to use.
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 a specific verb ('Busca') and resource ('entidad supervisada') with explicit search criteria (nombre, RUT, ticker). It also distinguishes itself from sibling tools by positioning as the recommended first step before consulting EEFF, hechos, etc., making the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool to find an entity by name/RUT/ticker before querying other financial data. It says 'Es el primer paso recomendado' but does not explicitly name alternatives or exclude cases where other search/list tools might be more appropriate, such as cmf_listar_entidades for full listings.
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 and destructiveHint=false, so the safety profile is covered. The description adds the search scope (by name or RUT) and the CMF supervision aspect, but does not disclose other behaviors like pagination or result format beyond the schema-provided limit/offset parameters.
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, front-loaded sentence with no filler. It conveys the core purpose and search capability in an efficient manner, making it highly scannable.
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 tool appears simple, with annotations and an output schema covering the return structure. The description provides necessary context about the fund type and search fields, though it doesn't mention pagination or result limits explicitly—but those are represented in the schema. Overall, it is sufficiently complete for a straightforward catalog search.
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?
Input schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by specifying that the 'consulta' parameter accepts a name or RUT of the administrator, which enriches the schema's generic 'Nombre o RUT a buscar' 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 the tool provides a catalog of investment funds supervised by the CMF, with search by name or administrator RUT. This distinguishes it from sibling tools like cmf_fondos_mutuos_catalogo by explicitly specifying 'fondos de inversión' and the search criteria.
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 the tool is for searching investment funds via name or RUT, but it does not provide explicit guidance on when to use this tool versus alternatives or mention exclusions. While the context is clear enough for a simple catalog lookup, there's no direct comparison to similar catalog tools.
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?
Beyond the readOnlyHint=true annotation, the description discloses that the conversion uses pdf-inspector, does not perform OCR, and indicates when a PDF is scanned. This adds useful behavioral context about limitations without contradicting the 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 three sentences, front-loaded with the main purpose, and each sentence adds value: what it does, input methods, and the scanned-PDF limitation. No superfluous 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 tool's complexity (multiple input modes, conversion behavior) and the presence of annotations and an output schema, the description covers the core functionality and key limitation (no OCR). It doesn't detail error handling, but the output schema likely provides return format, so this is sufficient.
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 100%, so the schema already explains all four parameters. The description only repeats the token/URL alternatives without adding new semantic detail beyond what the schema provides, so a baseline score 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 it downloads a signed CMF document and converts it to readable Markdown for the agent. It specifies the document types (EEFF, hechos, sanciones, resoluciones, normas) and how it differs from sibling tools like cmf_documento_descargar by focusing on conversion to Markdown.
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 explains the tool accepts either a s567 token or a CMF URL, and notes the no-OCR limitation for scanned PDFs. While it doesn't explicitly name alternative tools, it implies when to use this tool (when readable Markdown is needed) as opposed to simple download or info tools.
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 the tool as read-only and non-destructive. The description adds context by detailing the data source (catálogo de empresas-cmf-chile) and the specific return fields (RUT, razón social, ISIN, tipo de entidad, norma, inicio IFRS), which goes beyond what annotations 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?
The description is concise (three sentences), front-loaded with the verb and resource, includes concrete examples, and packs in return fields and use case without wasted 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?
With annotations and an output schema present, the description is mostly complete. It covers purpose, data source, return values, and a typical use case. The only minor omission is clarification of the 'term' parameter, but overall it provides sufficient context for an agent to select and invoke the 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?
Schema coverage is 67% (2 of 3 params have descriptions). The description reinforces that 'consulta' is the ticker/name parameter but does not clarify the ambiguous 'term' parameter or the 'limite' parameter's purpose. It adds some context but does not fully compensate for the schema gaps.
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's function: 'Busca una empresa chilena por su ticker de bolsa' with specific examples (COPEC, SQM-B). It distinguishes itself from sibling tools by specifying it returns RUT, razón social, ISIN, etc., and explicitly mentions its use for translating tickers to RUT before querying other data.
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 clear usage context: 'Ideal para traducir tickers a RUT antes de consultar EEFF, hechos, etc.' This implies when to use it relative to other cmf_empresa_* tools. While it doesn't name alternative tools explicitly, the intended workflow is evident.
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?
Beyond the readOnly annotation, the description reveals that the tool returns monthly XLS documents by administrator, informing the agent about output format and granularity. It also names the specific circulars, adding regulatory context. This is useful but does not cover pagination or download mechanics.
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, compact sentence that packs key information: purpose, scope, regulatory basis, output format, frequency, and granularity. It is well-structured and front-loaded, with no wasted 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?
Given the presence of an output schema and annotations, the description adequately covers the tool's purpose, data coverage, and output characteristics. It lacks explicit details about optional year filtering or how to handle returned XLS documents, but these are reasonable gaps for a query tool with a rich 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 description explicitly relates the 'circular' parameter to Circulars 1951 and 1965, and the 'tipo' parameter to mutual funds and investment funds. However, the 'anio' parameter is not described in words, only implied by the monthly documents context. With 0% schema description coverage, this partial compensation is helpful but not complete.
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 identifies the tool as providing maximum commissions that mutual funds and investment funds can charge to pension (Circular 1951) and severance (Circular 1965) funds. It specifies the exact resource and scope, distinguishing it from general commission tools by the regulatory circulars and pension/cesantía context.
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 the tool is for querying maximum commissions in the pension/cesantía context but does not explicitly state when to prefer it over sibling tools like cmf_fondos_mutuos_comisiones or cmf_fondos_inversion_comisiones_maximas. There are no clear exclusions or alternative references, so the usage guidance is only implicit.
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 destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations by specifying the returned fields, the name filter, and pagination support. This goes beyond merely restating the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose ('Catálogo completo...') and efficiently lists fields and capabilities. Every part earns its place with no redundancy.
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?
With an output schema present, the description does not need to explain return structure. It adequately covers the tool's purpose, fields, and filtering/pagination. However, given the large sibling list, a brief mention of this being the entry point for obtaining fund identifiers (RUN fondo) for use in other fondos mutuos tools would have made it more complete.
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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description only restates the nombre filter and pagination (limit/offset) already present in the schema, without adding deeper semantics or examples.
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 is the 'Catálogo completo de fondos mutuos de la CMF' and lists the specific fields included (RUT administradora, RUN fondo, nombre, tipo, moneda, fechas). This distinguishes it from sibling tools like cmf_fondos_mutuos_cartera or cmf_fondos_mutuos_comisiones, which focus on specific data rather than the full catalog.
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?
It provides clear context that the tool is filterable by name and paginated, indicating when it should be used (for retrieving catalog data with optional filtering/pagination). However, it does not explicitly name alternatives or state exclusion criteria, so it falls short of a 5.
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 and destructiveHint=false, so the safety profile is covered. The description adds only minor context: it mentions the CMF listing engine and implies a limitation (not the full catalog), but does not disclose pagination behavior, rate limits, or authentication requirements. Given the annotations, this is acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core function and parameters, and the second provides an alternative. It is front-loaded and contains no fluff or redundancy.
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 is largely complete for a simple filtered-list tool: it clarifies purpose, gives an alternative, and output schema exists. The only notable gap is that the 'mercado' enum values (V, O, S) are undocumented, which could leave the agent unsure of valid inputs.
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 80% (4 of 5 parameters). The description repeats the tipoentidad example already present in the schema ('RVEMI=emisores de valores') and mentions 'mercado' without explaining its enum values, so it adds little beyond the structured 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 lists supervised entities by type and market, using the specific verb 'Lista' and resource 'entidades supervisadas'. It also distinguishes itself from the sibling cmf_buscar_entidad by explicitly directing the user there for the complete catalog, making its own scope unambiguous.
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?
The description provides an explicit alternative: 'Para el catálogo completo use cmf_buscar_entidad con consulta='%'`. This tells the agent when not to use this tool and what to use instead, while implying that this tool is for filtered listing by type/market.
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 and destructiveHint=false, so the safety profile is established. The description adds a behavioral detail: it includes normativa from the last month. However, it doesn't disclose pagination behavior, default date ranges, or how filters combine. Since annotations cover the key safety traits, the description's additional context is modest, scoring 3.
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 short sentences, immediately front-loaded with the action and resource. It wastes no words and conveys all key search dimensions efficiently.
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 complexity (8 parameters, no required ones) and the presence of an output schema, the description covers the essential search capabilities and the notable 'last month' inclusion. It doesn't need to explain return values because the output schema exists. Minor gaps like pagination are already documented in schema descriptions, so the overall completeness is adequate but not exhaustive, scoring 4.
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?
Schema coverage is 50%, with descriptions missing for 'desde', 'hasta', 'entidad', and 'materia'. The description compensates by explaining these as filters for date range, entity, and matter. It also clarifies the tipo parameter as covering circulares, oficios, and NCG. This adds meaning beyond the schema, so a 4 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 uses the specific verb 'Busca' (searches) and identifies the resource: CMF norms (circulares, oficios, NCG). It clearly distinguishes from sibling tools by specifying search criteria (type, number, date range, entity, matter), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does and its main search dimensions, but it does not explicitly state when to use it over alternatives like cmf_normativa_descargar, nor does it mention exclusions. This earns a 4.
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?
With no annotations provided, the description carries the full transparency burden. It discloses key behavioral traits: unfiltered queries return the entire registry, and exportar=true triggers a large official XLSX download. This goes beyond the schema and gives the agent useful expectations about result size and export 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?
Three sentences, front-loaded with the action and resource, then a caution about scale, then the export alternative. Every sentence earns its place with no redundancy.
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?
For a 9-parameter query tool with no output schema, the description covers core purpose, the full-dataset caveat, and export mode. It could mention pagination parameters (limit/offset) explicitly, but the phrase 'use filtros o paginación' gives enough hint. Overall, it is sufficiently complete for an agent to invoke 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?
Schema description coverage is 78% (7 of 9 params). The description adds context about the registry's content (e.g., 'temas y norma') which maps to the 'tema' and 'norma' parameters, and clarifies the exportar option. However, it does not explain the undefined 'desde'/'hasta' date parameters beyond implying date filtering, leaving a small gap that the schema's pattern partially covers.
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 identifies the tool's action ('Busca en el Registro de Depósito de Pólizas de la CMF') and specifies the domain (mercado de seguros). It lists the key returned fields (código, fecha, aseguradora, texto, temas, norma) and distinguishes it from sibling insurance tools by naming the specific registry and NCG 124/349.
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 practical usage context: warns that no filters return the full ~7,000 records and advises using filters or pagination. It also explains the exportar=true mode for downloading the official XLSX. It does not explicitly compare with alternative sibling tools, but the domain-specific naming and clear workflow guidance are strong.
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 and destructiveHint=false, so the safety profile is known. The description adds the specific taxonomy codes and the source (CMF), which is useful context but does not disclose additional behavioral traits such as return format or ordering. Given the annotation coverage, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence in Spanish. It leads with the action ('Lista'), specifies the resource, and includes the relevant taxonomy codes. There is no wasted text or repetition of the title.
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?
For a parameterless listing tool with annotations and an output schema, the description is complete enough. It identifies exactly what is listed (the six taxonomy codes) and their source. The output schema presumably covers return structure, so no additional detail is needed. A small gap is that it does not mention whether the list is exhaustive or if there are any limitations, but this is minor.
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 tool has zero parameters, so the input schema is empty and requires no explanation. The description does not need to add parameter semantics. The baseline for 0 parameters is 4.
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 a specific action ('Lista') and a concrete resource (taxonomías XBRL del Mercado de Valores publicadas por la CMF), and it enumerates the exact taxonomy codes (CL-CI, CL-CC, etc.). This distinguishes it from sibling XBRL tools like cmf_xbrl_visor and cmf_xbrl_consulta, which are for viewing or consulting specific reports.
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 does not explicitly mention when to use this tool versus alternatives, but it provides clear context: it is for listing available XBRL taxonomies. There is no exclusion or alternative mentioned, which is acceptable for a simple listing tool, but slightly more guidance would be beneficial.
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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: it returns metadata and explicitly states it does not download the content, which clarifies the scope beyond the annotations. It does not cover auth or error behavior, but that is acceptable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and followed by a clear exclusion. Every sentence earns its place with no wasted 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?
The tool is simple with one parameter, an output schema exists, and annotations cover safety. The description sufficiently explains what it does, what it does not do, and the required token. No additional behavioral details are needed for a metadata lookup 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?
Schema coverage is 100% and the s567 parameter already has a description in the schema ('Token del documento extraído de hechos/sanciones/resoluciones'). The tool description mentions the token and document categories but does not add substantial new meaning beyond the schema. Baseline 3 applies given 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 tool returns metadata for a signed CMF document using a specific verb ('Devuelve') and identifies the resource types (hechos, sanciones, resoluciones, informes). It also explicitly notes it does not download content, distinguishing it from sibling download tools.
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 for use: you need a token s567 and you get metadata, not content. The negative statement 'No descarga el contenido' implies when not to use this tool, but it does not explicitly name alternative tools such as cmf_documento_descargar, so an explicit alternative reference is missing.
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 establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it produces a plan (not data), enforces a 2-year worker limit, and returns normalized filenames. This goes beyond the annotations without contradicting them.
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: the first front-loads the core purpose and output, the second adds constraints and redirection. No wasted words; every phrase contributes value.
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 essential behavioral contract (what is produced, the 2-year limit, no bytes) and points to the appropriate sibling for actual downloads. With an output schema present, the lack of detailed return-value documentation is acceptable. Minor gap: no mention of parameter defaults or how 'ventanas de años' maps to anio_inicio/anio_fin, but overall adequate.
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 7 parameters with 0% description coverage, and the description does not explain any parameter semantics. Terms like rut, tipo, norma, anio_inicio, anio_fin, secciones, and incluir_tablas are intuitive from their names and enums, but the description fails to add meaning or clarify edge cases (e.g., default values, interaction between anio_inicio and anio_fin).
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 the tool's function with a specific verb ('Arma') and a clear resource: a complete download plan (directory tree + document manifest) with normalized filenames. It distinguishes itself from the sibling cmf_empresa_paquete_documentos by clarifying it does not include bytes.
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?
Provides explicit usage boundaries: maximum 2 years per call with guidance to use successive year windows for longer history, and explicitly directs users to cmf_empresa_paquete_documentos when bytes are needed. This clearly states when to use this tool vs the alternative.
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 destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail beyond annotations: it returns base64 content for files <4MB or a resource URI for larger files, disclosing a size threshold and fallback behavior. This is valuable context that the annotations do not 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?
The description is two sentences, front-loaded with the main action, and provides essential output behavior without any filler. Every sentence adds value and is highly scannable.
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?
For a simple single-parameter tool with an output schema and complete annotations, the description covers all necessary aspects: the action, the output format, and size-dependent behavior. It is sufficient for an agent to select and invoke the 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 schema description for the only parameter 'archivo' is explicit and includes an example path, providing 100% coverage. The tool description does not add anything beyond the schema, but it also doesn't need to. Per the baseline rule for high schema coverage, this scores 3.
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 states exactly what the tool does: 'Descarga el PDF de una norma del compendio' (downloads the PDF of a regulation from the compendium). It uses a specific verb and resource, and clearly distinguishes it from sibling tools like cmf_normativa_buscar (which searches) and cmf_documento_descargar (which is a more generic document download).
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 its usage context: when the user needs a PDF of a normativa and provides the file path. It also specifies the output behavior for small vs large files, which helps the agent decide if this is the right tool. However, it does not explicitly mention alternatives or exclusion criteria, so it stops short of 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?
Beyond the annotations (readOnlyHint, destructiveHint), the description adds security context: 'El servidor gestiona el token; nunca se expone al modelo.' This discloses token handling behavior and implies a safe download path. The large-doc suggestion also hints at potential size limits. 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 two sentences, front-loaded with the primary action, and every sentence adds value: purpose, formats, security note, and an alternative for large documents. No redundancy or fluff.
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?
For a simple one-parameter download tool with an output schema and readOnly annotations, the description covers the essential context: what it downloads, the token, server-side security, and a size-based fallback. It could mention error scenarios or supported formats in more detail, but overall it is sufficiently complete.
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 schema already describes s567 as 'Token del documento' (100% coverage), but the tool description enriches it by stating 'su token s567' and clarifying that the server manages it securely, adding meaning about the token's role in downloading signed documents.
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 ('Descarga un documento firmado'), the resource (CMF), and the formats (PDF/XLS/XLSX). It distinguishes itself from sibling tools like cmf_documento_info and cmf_documento_markdown by specifying the signed document token usage.
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 an explicit alternative for large documents ('Para documentos grandes use el resource cmf://documento/{id}'), telling the agent when not to use this tool. It could additionally mention when to prefer cmf_documento_markdown for markdown conversion, but the large-doc guidance 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 declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it explains that 'El HTML de la CMF viene sin líneas' and that 'la fuente real de las cifras son los PDFs', giving the rationale for using PDFs. It also discloses that markdown mode uses 'pdf-inspector' to convert the audited PDF. No contradictions 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 three sentences, each earning its place: first states the overall purpose, second details the two modes, third provides a critical caveat about HTML vs. PDF. It is front-loaded with the key information and avoids redundancy. No filler words or repetition of schema parameter names.
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 tool has 9 parameters and an output schema, so return values are already defined. The description covers the main mode distinction, the financial statement variants (consolidated/individual, IFRS/NCH), and the underlying data quality nuance. It does not explicitly differentiate from sibling EEFF tools (e.g., historial, filiales, NCH-specific), but the 'pestanía 3' and period focus make it clear enough. Importantly, it reveals the real source of data (PDFs), which is critical for an agent to understand the tool's behavior.
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?
Schema description coverage is 78%, slightly below the 80% threshold, so the description should compensate. It does so by explaining the 'modo' enum in detail (documentos vs. markdown) and referencing 'consolidado o individual' (tipo) and 'IFRS o NCH' (norma). It does not describe all parameters, but the schema already covers most (mes, rut, anio, query, max_chars, validar_contable). The description adds meaning to the main mode parameter and confirms the business context for the others.
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's function: 'Estados financieros de un emisor (pestanía 3) para un período, consolidado o individual, IFRS o NCH.' It goes on to explain the two modes (documentos and markdown) and their outputs (PDFs vs. Markdown), which distinguishes it from sibling tools like cmf_empresa_eeff_historial or cmf_empresa_eeff_filiales. The verb is implicit but the resource and scope are precise.
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 for when to use each mode: 'modo=documentos: devuelve los PDFs oficiales... modo=markdown: además convierte el PDF original auditado a Markdown'. This gives usage guidance for choosing the right mode. It does not explicitly mention alternatives or when-not-to-use, but the sibling list and the specific 'pestanía 3' reference give enough context for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral detail: it returns a base64 ZIP with logical directory and normalized filenames including manifest.json, imposes specific limits (max 3 EEFF periods, 2 years for other sections, max_documentos, max_mb), and states that signed tokens are handled server-side. This goes well beyond the annotations to set expectations about response format and constraints.
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 dense but every sentence contributes value: it states the action and output, explains the limits and parameter semantics, and notes token handling. It is front-loaded with the primary purpose and avoids unnecessary filler.
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 complexity (10 parameters, multiple document types) and the presence of an output schema, the description covers the essential return format, limits, and parameter details. It does not mention error conditions or prerequisites (e.g., validity of the company), but the output schema and annotations cover some of these aspects, making it reasonably complete.
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 schema has only 10% description coverage, so the description must compensate. It explains the periodos format (AAAAMM, max 3), the default behavior of using the most recent periods, the 2-year limit for other sections, and references max_documentos and max_mb. However, it does not clarify other parameters like rut, tipo, norma, secciones, or incluir_zip in detail, leaving some gaps.
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 downloads a company's documents across multiple sections (EEFF, hechos, sanciones, resoluciones, memoria) in a date range and returns them as a base64 ZIP with a logical structure. This specific verb+resource distinguishes it from sibling tools that handle individual document types or single downloads.
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 for when to use this tool (batch downloading multiple document categories in one call) and details the per-call limits. It does not explicitly name alternative tools or say when not to use it, but the context is sufficient to infer it is for batch/package downloads.
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-cmf-chile MCP server](https://glama.ai/mcp/servers/JoaquinMulet/mcp-cmf-chile/badges/card.svg)](https://glama.ai/mcp/servers/JoaquinMulet/mcp-cmf-chile)

Score Badge

Copy to your README.md:

[![mcp-cmf-chile MCP server](https://glama.ai/mcp/servers/JoaquinMulet/mcp-cmf-chile/badges/score.svg)](https://glama.ai/mcp/servers/JoaquinMulet/mcp-cmf-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/JoaquinMulet/mcp-cmf-chile'

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