Mexico's official economic data from Banxico: USD/MXN, inflation, UDIS, TIIE and reserves.
Scored across 6 tools
The five indicator-specific tools (inflación, reservas, tasas, tipo de cambio, UDIS) each target a distinct economic series, so they are easy to distinguish. However, 'consultar_serie_sie' is a generic series lookup that overlaps conceptually with all of them, so an agent may be unsure when to use the generic tool versus a specific one.
Only 'consultar_serie_sie' uses a verb_noun pattern while the rest (inflacion_mexico, reservas_internacionales, tasa_interes_banxico, tipo_cambio_usd, valor_udis) are bare noun phrases. All are snake_case and readable, but the verb-first outlier breaks a predictable convention.
Six tools is well-scoped for a central-bank data server, with one generic series accessor plus focused shortcuts for the most common indicators. Each tool earns its place without redundancy.
The surface covers the flagship indicators (inflation, reserves, policy/interbank rates, USD/MXN, UDIs) and the generic SIE tool provides broad catalog coverage as a fallback. Some named indicators lack dedicated shortcuts, but the generic tool prevents dead ends.
Consulta avanzada para obtener observaciones de cualquier serie económica del catálogo SIE de Banxico.
Args: id_serie: Identificador de la serie oficial (por ejemplo: 'SF43718', 'SP68257', 'SF61745'). fecha_inicio: Fecha inicial en formato YYYY-MM-DD o DD/MM/YYYY (opcional). fecha_fin: Fecha final en formato YYYY-MM-DD o DD/MM/YYYY (opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| id_serie | Yes | ||
| fecha_fin | No | ||
| fecha_inicio | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates a read-only query ('Consulta') that returns observations, but it does not mention rate limits, authorization needs, error behavior, or what happens when date filters are omitted. This is adequate for a simple query tool but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Opens with a one-sentence purpose statement followed by a compact Args list that maps directly to the schema. There is no filler, and every line contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return structure, and the description fully documents the parameters and the generic scope, making invocation clear. It lacks explicit sibling routing and behavioral caveats, but these are minor given the simple read-only nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains id_serie with concrete examples and specifies accepted date formats for both optional parameters, adding essential meaning beyond the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'obtener observaciones de cualquier serie económica del catálogo SIE de Banxico'. The phrase 'cualquier serie' clearly distinguishes it from sibling tools like tipo_cambio_usd or inflacion_mexico, which are specific-series helpers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'cualquier serie económica': an agent can infer this is the generic tool for arbitrary SIE series while siblings cover specific ones. However, it never explicitly states when to prefer this tool over the alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta la inflación oficial en México según el INPC de Banxico.
Args: tipo: Tipo de medición de inflación. Opciones: 'anual' (por defecto) o 'mensual'.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | anual |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions the type of measurement options and the default, but doesn't disclose aspects like data source specifics, frequency of updates, or whether it's a read-only operation. It's a simple query tool, so basic transparency is adequate, but additional context like 'read-only' would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence followed by a clear Args section. It front-loads the core purpose and efficiently explains the parameter in the same space. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single optional parameter and an output schema, the description is largely sufficient. It explains the parameter options and default, and the output schema covers return format. Minor gaps like not specifying how inflation data is calculated or frequency of updates, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter with a default but no description or enum values. Schema coverage is 0%, but the description does define the parameter 'tipo' and its options ('anual' or 'mensual'), which exceeds the schema's information. However, it relies on the description for meaning, which it provides clearly, so it's a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool queries official inflation in Mexico based on INPC from Banxico, which is specific and distinguishes it from sibling tools like tipo_cambio_usd that deal with exchange rates and valor_udis for UDIs. The verb 'Consulta' plus the resource 'inflación oficial' makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool can be used for annual (default) or monthly inflation measurements, which clarifies usage in context. It does not explicitly differentiate from alternatives, but the domain (inflation) is distinct enough from siblings, so the context implies when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta el saldo de reservas internacionales netas del Banco de México (en millones de dólares).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Consulta' clearly signals a read-only operation, and the description adds useful context by naming Banco de México as the source and stating the units. It does not describe edge cases or return structure, but for a zero-parameter read-only query this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action ('Consulta') and the resource, then immediately adds the source and units. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter query tool with an output schema present, the description is complete enough: it identifies the metric, source, and units. It does not explicitly say whether the result is the latest snapshot or a historical series, but this is a minor gap given the simple nature of the tool and the availability of a sibling for series queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with 100% description coverage. The baseline for a zero-parameter tool is 4, and the description adds no conflicting parameter information. There is nothing more to explain about arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta'), names the exact resource ('saldo de reservas internacionales netas del Banco de México'), and specifies units ('millones de dólares'). It clearly distinguishes this tool from siblings like tipo_cambio_usd, inflacion_mexico, and valor_udis, which cover different Mexican economic indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent needs Mexico's net international reserves, but it does not explicitly state when to prefer it over alternatives or mention sibling tools. The usage context is clear from the metric name, but no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta las tasas de interés interbancarias y de política monetaria en México.
Args: tipo: Tipo de tasa. Opciones: 'tiie_28' (TIIE a 28 días) o 'objetivo' (Tasa de referencia/fondeo).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | tiie_28 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the two rate types and their meanings, which is useful behavioral context. However, it doesn't mention whether this is a read-only operation, any data source caveats, or what the response structure looks like, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a compact parameter explanation. The Args section is slightly redundant with the schema but earns its place by adding semantic meaning to the parameter values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is mostly complete. It covers the key decision (which rate type to request) but lacks guidance on when to prefer this over consultar_serie_sie or whether there are any rate limits or data freshness considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining the 'tipo' parameter's two options ('tiie_28' and 'objetivo') with their meanings. This adds real value beyond the bare schema, though it could be more explicit about the default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries Mexican interbank and monetary policy interest rates, with a specific verb ('Consulta') and resource. It distinguishes itself from sibling tools like tipo_cambio_usd and inflacion_mexico by focusing on interest rates, though it doesn't explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the two valid options for 'tipo' and their meanings, which helps an agent choose the right parameter value. However, it doesn't explicitly state when to use this tool versus alternatives like consultar_serie_sie, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta el tipo de cambio oficial peso mexicano vs dólar estadounidense (USD/MXN).
Args: tipo: Modalidad del tipo de cambio. Opciones: 'FIX' (por defecto) o 'LIQUIDACION'. fecha_inicio: Fecha inicial en formato YYYY-MM-DD o DD/MM/YYYY (opcional). fecha_fin: Fecha final en formato YYYY-MM-DD o DD/MM/YYYY (opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | No | FIX | |
| fecha_fin | No | ||
| fecha_inicio | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses input semantics and date formats but does not describe return behavior, error cases, rate source details, or any operational constraints. The read-only nature is implied by 'Consulta' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary followed by a concise parameter list. There is no redundant or filler content, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with three optional parameters, the description covers the essential invocation details: resource, parameter meanings, defaults, and formats. An output schema exists, so return-value documentation is unnecessary; the main omission is explicit sibling differentiation, which is already partially addressed by purpose clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'tipo' options ('FIX' and 'LIQUIDACION'), defaults, and accepted date formats for both date parameters. Every parameter is given meaningful context beyond its name and schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Consulta') and resource ('tipo de cambio oficial peso mexicano vs dólar estadounidense (USD/MXN)'), making the tool's purpose unambiguous. It is also naturally differentiated from sibling tools, which address inflation, UDIs, interest rates, and reserves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for USD/MXN exchange rate queries, but it does not explicitly state when to prefer it over the sibling tools or when not to use it. The domain is clear enough for an agent to infer the use case, but no explicit routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta el valor oficial de las Unidades de Inversión (UDIS) en pesos mexicanos.
Args: fecha: Fecha específica a consultar en formato YYYY-MM-DD o DD/MM/YYYY (opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| fecha | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosing behavior. 'Consulta' indicates a read-only lookup, and the optional-date syntax is disclosed, but behavior for omitted or invalid dates, as well as any data-source limits, is not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in one sentence and then a compact parameter section. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is nearly complete: it states the purpose, the parameter, the accepted formats, and optionality. It does not clarify what happens when fecha is omitted (e.g., whether the current/latest UDIS is returned), which is a small but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines fecha as an optional string/null with no description, so 0% schema coverage means the description must compensate. It does so effectively by specifying the accepted formats (YYYY-MM-DD or DD/MM/YYYY) and explicitly marking the parameter as optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and resource ('valor oficial de las Unidades de Inversión (UDIS) en pesos mexicanos'), making the tool's purpose immediately clear. It is also distinct from the sibling tools because UDIS valuation is a different financial indicator than exchange rates, inflation, interest rates, or reserves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when an official UDIS value is needed, optionally for a specific date. However, it does not mention any sibling tools or state when an alternative such as consultar_serie_sie would be more appropriate, so 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
consultar_serie_sieinflacion_mexicoreservas_internacionalestasa_interes_banxicotipo_cambio_usdvalor_udisBanxico MCP — Banco de México (Mexico's central bank) via the SIE API.
Official Mexican data for AI agents: CURP, RFC, CFDI, postal codes, phone, SPEI/CEP, DOF, geocoding.
Datos econ�micos y financieros oficiales de Argentina (BCRA, INDEC, CNV, MECON), AI-ready.
Add one secure layer between your agents and this server.
