mcp-mercado-financeiro-brasil

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools target distinct indicators or calculations, but get_serie_sgs overlaps with get_selic, get_cdi, get_ipca, and get_cotacao by exposing the same underlying SGS series through raw codes. listar_titulos_tesouro and get_titulo_tesouro also share a similar boundary, though descriptions help clarify one is a full list and the other is a search.
Naming Consistency2/5
The tool names mix English and Portuguese conventions without a consistent pattern: get_selic and get_cotacao follow English get_*, but listar_titulos_tesouro and simular_tesouro use Portuguese verbs, while historico_cambio, juros_compostos, and imposto_renda_renda_fixa are bare noun phrases. The naming is readable but inconsistent enough to make the overall surface feel unpolished.
Tool Count4/5
With 18 tools, the server sits slightly above the typical well-scoped range, but the count is reasonable given the breadth of Brazilian financial data covered: macro indicators, FX, Tesouro Direto, financial calculations, and operational health. A few tools could be consolidated, but none feel superfluous.
Completeness4/5
The server covers the main Brazilian economic indicators, official FX rates, Tesouro Direto browsing and simulation, and common fixed-income calculations such as compounding, rate conversion, real return, CDI comparison, and IR. Minor gaps exist, like no dedicated historical wrapper for IGP-M or accumulated CDI, though get_serie_sgs can partially fill those needs.
Average 3.4/5 across 18 of 18 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the output metric and unit; it does not describe whether the result is the latest value, a historical series, what the 'ultimos' parameter changes, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded, and contains no filler words. It conveys the core metric in a compact form, though the compactness comes at the cost of missing important detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one undocumented parameter and no output schema or annotations, the description is not complete enough. An agent can invoke it with defaults, but cannot reliably understand how to request historical values or interpret the result beyond 'monthly percentage'.
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 'ultimos' parameter at all. The schema only shows it is an optional integer with a default of 1, so the agent cannot learn what the parameter means from either source.
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 (poupança) and the metric (monthly yield in %), so an agent can infer what the tool returns and distinguish it from siblings like get_selic or get_cdi. However, it is a noun phrase rather than an explicit verb+resource statement, and it does not explicitly differentiate it from the 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 gives no guidance about when to use this tool instead of alternatives such as get_selic, get_cdi, or get_ipca. There is no mention of context, prerequisites, or exclusions, so an agent must rely entirely on domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of disclosing behavior; it only says the result is a percentage of CDI. It does not state the formula direction, whether inputs should be decimals or percentages, or what the return payload looks like.
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 filler or repetition. It is appropriately concise for a simple calculator, though it could afford one more sentence of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter calculator with no output schema and zero parameter descriptions, the definition is incomplete: it should specify the formula (investment rate divided by CDI), the input unit convention, and the output format. The current text leaves these to guesswork.
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 define the two parameters beyond the self-explanatory names taxa_investimento_anual and cdi_anual. It fails to clarify units or value ranges, so the low schema coverage is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it computes how much an investment yields as a percentage of CDI, which is a specific calculation distinct from merely fetching CDI (get_cdi). It does not explicitly name sibling alternatives, so it stops 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over rentabilidade_real, get_cdi, or juros_compostos. The intended use can be inferred from the name, but the description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only that the result is a historical series; it does not mention response format, ordering, business-day handling, or potential errors. This is minimal for a data-retrieval tool.
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 with no redundant words. The core purpose is front-loaded, and every phrase adds either purpose or a format constraint.
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 no annotations, no output schema, and three undocumented parameters, this description is too sparse. It lacks currency format guidance, response expectations, and any differentiation from sibling exchange-rate tools, leaving an agent to infer critical call details.
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 adds the date format 'aaaa-mm-dd' for the date parameters but does not clarify how 'moeda' should be specified (e.g., currency code) or whether the date range is inclusive.
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 a historical PTAX series for a currency ('Série histórica PTAX de uma moeda'), which clearly identifies the resource and operation. It does not explicitly differentiate from sibling tools like get_cotacao or get_serie_sgs, but the term 'PTAX' adds 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 get_cotacao or get_serie_sgs. The date-format note is a parameter formatting hint, not usage-context 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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context ('juros compostos equivalentes') but does not state whether the operation is a pure calculation, what it returns, how invalid inputs are handled, or any side effects. This leaves important behavioral expectations implicit.
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 redundancy. It efficiently communicates the core conversion purpose and method, though it could have added parameter clarification 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?
For a tool with three parameters, no annotations, and no output schema, this description is too sparse. It does not specify the format of 'taxa_pct', the expected values of 'de' and 'para', or the return value, leaving the agent to infer critical details from the schema alone.
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 by explaining parameters. It hints at the values of 'de' and 'para' by mentioning 'anual' and 'mensal', but it never describes 'taxa_pct', the direction of conversion, or input units (e.g., percentage vs decimal). This is insufficient for a three-parameter tool.
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 ('Converte') and clearly specifies the resource ('taxa') and the conversion scope between 'anual' and 'mensal' with 'juros compostos equivalentes'. This makes the tool's purpose unambiguous and distinguishes it from sibling tools like juros_compostos, which focuses on interest computation rather than period conversion.
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 does not provide any guidance on when to use this tool versus alternatives. It implies usage for rate conversion but never mentions sibling tools or conditions that would favor converter_taxa over related tools like juros_compostos.
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?
There are no annotations, so the description carries the behavioral burden. It does disclose one important assumption: contributions occur at the end of each period. However, it says nothing about return format, rounding, or other calculation conventions, though as a pure math tool this is less critical.
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 filler. It front-loads the core calculation and adds the key timing assumption without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter documentation, the description is too sparse to fully support a correct call. An agent would have to infer important details like the units for the interest rate and what the returned amount represents.
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 only clarifies the concept of periodic contributions and their end-of-period timing. It does not define principal, explain that taxa_periodo_pct is a percentage, or specify the meaning of periodos as the number of periods.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool computes the future amount with compound interest and periodic contributions, which clearly distinguishes it from sibling tools like converter_taxa and simular_tesouro. It lacks an explicit verb like 'calculates', but the intent is still unambiguous in Portuguese.
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 such as rentabilidade_real or rentabilidade_vs_cdi. It implies a compound-interest calculator use case, but there is no explicit context, prerequisite, or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains that the value is a monthly percentage variation, but it does not disclose how the 'ultimos' parameter affects results, what the response contains, or any data-source/time-period behavior beyond 'mensal'.
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 front-loads the core meaning ('IGP-M — variação mensal (%)') and adds a practical use case. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter data retrieval tool, the description gives enough to understand the metric and its typical use, but it is incomplete around the 'ultimos' parameter semantics and the expected response. The absence of annotations and output schema makes this gap more noticeable.
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 ('ultimos') with 0% description coverage, and the tool description does not explain it. The Portuguese word 'ultimos' hints at 'last N periods', and the word 'mensal' suggests monthly data, but the description adds no explicit meaning 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 identifies the resource (IGP-M) and metric (mensal variation percent), which distinguishes it from sibling tools like get_selic and get_cdi. It lacks an explicit verb like 'returns' or 'gets', but the meaning 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a concrete use case: 'Usado em reajuste de aluguéis/contratos' (used in rent/contract adjustments), which gives the agent context on when to call it. However, it does not mention when not to use it or compare it to sibling tools, relying on the tool name alone for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does add meaningful detail by specifying the regressive tax table and the prazo (term) in days as the deciding factor. However, it does not state what the output represents, whether rounding is applied, or any edge-case behavior, leaving a clear transparency gap.
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 with no filler and no repetition of the tool name. It front-loads the core concept and then adds the calculation method and the time dimension. It is slightly telegraphic but well structured for a focused utility 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?
Given no annotations and no output schema, the description is the only contract for the agent. It covers the input concepts but omits the output format, units, and constraints on 'dias_aplicado'. For a two-parameter calculator this is inadequate: an agent cannot confidently validate inputs or interpret the result.
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 clarify parameter meaning. It maps 'rendimento' to the fixed-income earnings and 'dias_aplicado' to the term in days, which is helpful but still incomplete. It does not specify whether 'rendimento' is a currency amount or a percentage, nor whether 'dias_aplicado' means calendar days, business days, or a minimum holding period.
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 exact subject (IR on fixed-income earnings), the method (regressive table), and the time input (days), making the tool's function clear despite the lack of an explicit verb. It is easily distinguished from sibling tools, which cover economic indicators, treasury products, and rate conversions. A small deduction is warranted because 'IR sobre...' is a noun phrase rather than a direct statement that derives the tax.
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 state when to use this tool over alternatives such as juros_compostos, converter_taxa, or simular_tesouro. There are no prerequisites, exclusions, or typical scenarios mentioned. An agent must rely on the tool name and semantics to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It makes clear this is a read-only listing of available securities and states the data scope (latest rate and price), which is useful. It does not mention output shape, pagination, data source, or refresh behavior, but for a simple no-parameter listing tool the core behavior is reasonably transparent.
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 compact sentence, front-loaded with the action, and no filler. The qualifiers 'disponíveis' and 'mais recentes' carry useful meaning without adding unnecessary length.
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 no-parameter listing tool, the description covers purpose and core output contents. However, because there is no output schema or annotations, and the description does not distinguish this tool from get_titulo_tesouro or state any usage conditions, the overall context is adequate but not 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 tool has zero parameters and 100% schema coverage, so there is nothing for the description to add. Per the zero-parameter baseline, this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and resource ('títulos do Tesouro Direto disponíveis') and adds the key content of the returned data ('taxa e preço mais recentes'). It is clear, though it does not explicitly contrast with the sibling get_titulo_tesouro, so some differentiation is left to the name.
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 instead of alternatives such as get_titulo_tesouro or simular_tesouro. The intended use is only implied by the tool's name and purpose; there are no explicit conditions, exclusions, or preferred 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?
With no annotations, the description carries the behavioral burden. It usefully explains that this is the current COPOM-defined target rate in percent per year, not historical data. However, it does not disclose whether the response is a bare number, whether it includes an effective date, or how frequently the value updates.
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?
A single, compact sentence with no filler. It front-loads the core meaning and every phrase adds value: current, SELIC, basic interest rate, unit, and source.
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 zero-parameter lookup of a current rate, the description is nearly self-contained: it tells the agent what value is returned, the unit, and the institutional source. It lacks return-shape details, but no output schema exists and the operation is simple, so the main missing piece is sibling-selection guidance.
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 input schema has zero parameters, so parameter documentation is unnecessary and the baseline 4 applies. The description adds relevant interpretive context by specifying that the value is a percentage per year and the SELIC target set by COPOM.
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 names the exact resource (Meta SELIC atual), its unit (% ao ano), and source (COPOM), so the tool's purpose is unambiguous. It is a noun phrase rather than an explicit verb, but the resource is specific enough to distinguish it from siblings like get_cdi or get_ipca.
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 about when to use this tool versus alternatives such as get_cdi, rentabilidade_vs_cdi, or get_serie_sgs. The description implies it returns the current SELIC target, but it gives no exclusions, prerequisites, or sibling-routing 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 description discloses a key behavior: matching is by substring ('contém'), which goes beyond what the tool name alone implies. However, with no annotations available, the description still does not explain output format, case sensitivity, or what happens if no matches are found.
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. The action and filtering criterion are front-loaded, and the examples add practical value without unnecessary length.
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 read/search tool, the description covers the essential purpose and parameter semantics. It does not mention return values or how it relates to sibling tools, but the tool's minimal complexity makes the description mostly sufficient.
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 provides no description for 'nome', so schema coverage is 0%. The description compensates by clarifying that 'nome' is a substring of the bond type and gives concrete examples ('IPCA', 'Selic', 'Prefixado'), which makes the parameter's meaning clear.
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 a clear verb ('Busca') and resource ('títulos') and defines the filtering criterion ('tipo contém nome'). It is sufficiently clear, but it does not explicitly differentiate itself from sibling tools like listar_titulos_tesouro, so it stops 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as listar_titulos_tesouro or simular_tesouro. The description only explains what the tool does, not when it should be preferred over other available 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?
With no annotations present, the description carries the transparency burden and does it well: it discloses that the output is gross, the input rate is an annual percentage, and that IR, custody fee (0.20% p.a. B3), and early-redemption mark-to-market are not considered. It stops short of specifying return format or exact compounding convention.
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 compact sentences front-load the action and resource, then add the key input instruction and exclusions. There is no filler; every sentence earns its place.
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 3-parameter calculator, the description is adequate but not complete. Without annotations or an output schema, it should also clarify the remaining parameter semantics and the exact output value returned; it does disclose the most important assumptions and exclusions.
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 needed to explain all parameters. It explains taxa_anual (unit, % p.a., purchase rate) but gives no additional meaning for valor_investido or anos, leaving two of three parameters reliant only on self-evident titles.
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 a specific verb and resource: it simulates the gross amount of a fixed-rate/indexed Tesouro bond, clarifying the output is bruto. It does not explicitly differentiate from sibling tools such as juros_compostos or rentabilidade_vs_cdi, though the resource scope makes the main purpose clear.
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?
It gives useful operating context: taxa_anual must be the purchase rate in % p.a., and the tool ignores IR, custody fee, and mark-to-market. However, it does not explicitly state when to prefer this tool over alternatives or provide alternative routing to 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that the value is the most recent daily CDI in percent per day, which is useful, but it does not describe the return shape (e.g., single number vs. object with date) or any update/source behavior, leaving some ambiguity.
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 with no filler. The key information—what the CDI value is, its frequency, and its unit—is front-loaded, and every clause contributes meaning.
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, simple lookup tool, the description is nearly complete: it tells the agent what data is returned, the frequency, the unit, and the general use context. It lacks an explicit statement of return type, but with no output schema and such a simple resource, that omission 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 and the schema is empty, so there are no parameter semantics to clarify. With 0 params, the description is not required to add parameter detail; it still provides useful semantic context about the returned rate and its unit.
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 (CDI), the cadence (daily), the recency (most recent), the unit (% per day), and its role as a post-fixed income benchmark. It is far more specific than a tautology and distinguishes the tool from siblings like get_selic or get_ipca, though it does not explicitly name an alternative.
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 'Referência de renda fixa pós-fixada' implies when this tool is relevant, giving some usage context. However, there is no explicit guidance about when to use this tool versus alternatives such as get_selic or get_serie_sgs, so the agent must infer the appropriate 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?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool reports server status and configured optional sources, which is useful, but it does not define what 'status' includes, the response format, or whether any side effects or prerequisites exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the primary point ('Status do servidor') front-loaded, followed by the secondary detail about optional sources. There is no filler, repetition, or structural waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool, the description conveys the essential return contents and purpose. It lacks specifics about the exact shape or values returned, but with no output schema and minimal complexity, the description is sufficient for an agent to decide to invoke the tool correctly.
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 and the schema description coverage is 100%, so the schema already fully describes the input contract. The description correctly adds no parameter-specific details because none are needed.
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 'Status do servidor e quais fontes opcionais estão configuradas' ('Server status and which optional sources are configured'), clearly identifying a server health-check resource. It lacks an explicit verb like 'check' or 'verify', but the meaning is unambiguous and distinct from the data-retrieval 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call this tool to check server status and see which optional data sources are configured. There is no explicit statement of when to use it versus alternatives, but its role as a health check is apparent from the unique wording and zero-parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It confirms a fetch operation and explains the code-to-series mapping, but it omits the response format, error behavior, default time range, and whether the result includes dates or just values. This is minimal for an unannotated tool.
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 compact and front-loaded: first the definition, then illustrative examples, then a brief parameter gloss. Every sentence adds value and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter fetch tool, the core calling contract is present: a numeric code and an optional number of points. However, with no output schema and no annotations, the lack of any statement about the response shape or possible failure modes keeps it from being fully 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 description coverage is 0%, so the description compensates by explaining 'codigo' with concrete examples and 'ultimos' as the number of points. It does not specify valid ranges or the exact effect of 'ultimos' beyond the schema default, but it adds meaningful semantics the schema lacks.
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 operation and resource: fetching a generic SGS series from the Central Bank by numeric code. The examples anchor the meaning of 'codigo' and distinguish this generic tool from the sibling-specific tools like get_selic, get_ipca, and get_cdi.
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 word 'genérica' and the code examples make it clear this tool is intended for arbitrary SGS codes, while dedicated sibling tools cover common named series. It does not explicitly state when not to use it or name alternatives, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the formula and states that rates are in % per year, which is useful. However, it does not describe the output format (e.g., returns a percentage number), rounding, or error handling. It adds some behavioral context but leaves significant gaps.
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 core purpose, then the formula, then the unit convention. No fluff or repetition—every word earns its place.
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 calculation tool with no output schema, the description gives the formula and units but does not specify what the returned value represents (percentage, decimal) or any edge-case behavior. It is adequate for basic use but not fully complete for an agent needing precise expectations.
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 0%, so the description must compensate. It clarifies that both parameters are annual rates and in percent, and the Fisher formula reveals their relationship. This adds meaning beyond the parameter names, which are already fairly descriptive. It does not explicitly define each parameter, but the formula and unit mention cover the essentials for two simple 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's function: 'desconta a inflação (IPCA) da taxa nominal' (discounts IPCA inflation from the nominal rate), and provides the Fisher formula. This is a specific verb-resource pair that distinguishes it from siblings like 'rentabilidade_vs_cdi' or 'converter_taxa'.
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 a real (inflation-adjusted) return is needed from a nominal rate and IPCA—but does not explicitly state when NOT to use it or mention alternatives. It provides context but no exclusions or comparisons with 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read-only listing behavior and mentions the key-requirement aspect, but it does not describe the response format, whether external calls are made, or any other behavioral details. This is adequate but minimal.
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. Every word adds meaning: the action, the resource, and the distinguishing detail about keys.
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 zero-parameter metadata-listing tool, the description covers the essential purpose and the key-requirement detail. It lacks a more precise statement of output shape, but the tool's low complexity and empty schema make this 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?
The tool has zero parameters, so there is nothing to document beyond the schema. The description adds useful context about what the returned list contains (data sources and key requirements), earning a score above the no-parameter baseline of 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 uses a specific verb ('Lista') and a clear resource ('as fontes de dados usadas'), and it specifies the key detail that it reports whether each source requires a key. This clearly distinguishes it from the sibling data-retrieval tools, which fetch economic series rather than metadata about data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering which data sources are available and their credential requirements, but it does not explicitly state when to use this tool versus the sibling data-getting tools. There is no 'use this before calling get_*' guidance or exclusions.
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, the description carries the full burden. It clearly states the output unit (monthly variation percentage) and explains the meaning of the 'ultimos' parameter (number of months). However, it does not specify the response format (single value vs. series), which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two compact clauses to convey the purpose and parameter meaning with no filler. The key information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameter, but without an output schema it omits the exact return structure (e.g., array vs. scalar) and any date-related details. This is a modest gap for an otherwise simple data retrieval 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 schema provides only the type and default for 'ultimos' with no description. The tool description adds the essential meaning 'nº de meses' (number of months), fully compensating for the 0% schema coverage on this single parameter.
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 identifies the resource (IPCA, official inflation) and the metric (monthly variation in %), making it distinct from sibling tools like get_igpm or get_selic. Even though the verb is only implied by the tool name, the resource and output are unmistakable.
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 such as get_igpm or get_selic. Usage is implied by the specific index name, but the description does not mention exclusions or alternatives, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and largely meets it: it discloses that a missing date defaults to the last available business day and that the output contains buy/sell values. It doesn't state what happens with a user-supplied weekend/holiday date or mention rate limits, but for a read-oriented quote look-up the core behavior is reasonably disclosed.
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?
Compact and front-loaded: the purpose line comes first, followed by a tight param note in monospace grouping format. Every sentence earns its place, and the currency list and date format are presented economically.
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 two-parameter, no-output-schema quote look-up, the description covers purpose, accepted values, output composition, and date defaults. The only gaps are unspecified behavior for an explicitly supplied non-business date and the exact numeric output format, both minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the schema properties carry only titles and defaults — so the description must fully compensate, and it does. It enumerates the exact accepted currency codes (USD, EUR, GBP, JPY, CHF, CAD, AUD) and specifies the date format ('aaaa-mm-dd') plus its default fallback logic, adding substantial meaning the schema lacks.
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?
States a specific verb+resource: the official PTAX quotation of a currency against the Real, with buy/sell values. This clearly distinguishes it from sibling rate tools like get_selic, get_cdi, and get_ipca, which return interest-price indexes rather than exchange rates.
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?
Documents the data parameter's default behavior (falls back to a recent business day), which guides effective use. However, it never states when to prefer this over the sibling historico_cambio (historical exchange tool) or converter_taxa, nor when not to use it. It also doesn't specify whether the date must be a business day when explicitly provided.
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

mcp-mercado-financeiro-brasil MCP server

Copy to your README.md:

[![mcp-mercado-financeiro-brasil MCP server](https://glama.ai/mcp/servers/vinibeni2801/mcp-mercado-financeiro-brasil/badges/card.svg)](https://glama.ai/mcp/servers/vinibeni2801/mcp-mercado-financeiro-brasil)

Score Badge

Copy to your README.md:

[![mcp-mercado-financeiro-brasil MCP server](https://glama.ai/mcp/servers/vinibeni2801/mcp-mercado-financeiro-brasil/badges/score.svg)](https://glama.ai/mcp/servers/vinibeni2801/mcp-mercado-financeiro-brasil)

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/vinibeni2801/mcp-mercado-financeiro-brasil'

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