Meelion MCP
Server Details
Brazilian fixed income & financial data for AI. Selic, CDI, IPCA, CDB/LCI/LCA rankings, FX rates.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Meelion-com/meelion-mcp
- GitHub Stars
- 1
- Server Listing
- mcp-meelion
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: finding best investments, fetching current indicators, retrieving future projections, getting investment details, and obtaining quotes. No overlap or ambiguity.
All tools follow a consistent 'get_' prefix with descriptive noun phrases in snake_case (e.g., get_best_investments, get_financial_indicators). No mixing of styles.
With 5 tools, the server covers core functionality for Brazilian fixed income and financial data. The count is well-scoped for the domain, not too few or too many.
The tool set covers search, details, indicators, projections, and quotes. A minor gap is the lack of a direct comparison tool, but the essential operations are present.
Available Tools
5 toolsget_best_investmentsMelhores investimentos de renda fixaARead-onlyInspect
Busca as melhores oportunidades de renda fixa disponíveis na Meelion, com filtros por tipo de investimento, distribuidor, instituição, prazo e limite de resultados. Modo aberto (meelion_pro=0): no máximo 5 itens, seeMoreOnSite aponta para o comparador em www.meelion.com. Modo Pro (meelion_pro=1): padrão 10 com acesso completo e 5 com acesso limitado; o parâmetro limit respeita teto 200 (completo) ou 10 (limitado). detailUrl e links de site usam a base pública (MCP.public_base_url). Use quando o usuário quiser encontrar onde o dinheiro pode render mais, comparar CDB, LCI, LCA, CRI, CRA, debêntures ou outros produtos de renda fixa, ver rankings de melhores investimentos de hoje, melhores investimentos por prazo, por tipo ou por corretora/banco. Os dados são indicativos e podem mudar; o usuário deve confirmar as condições na instituição financeira antes de investir. English keywords: Brazilian fixed income, best investments today, CDB, LCI, LCA, CRI, CRA, debentures, highest yield, investment ranking, maturity, distributor, issuer, net return, gross yield.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Número máximo de resultados a retornar. Use valores menores para respostas rápidas e valores maiores para comparações mais amplas. | |
| prazo | No | Slug ou ID da faixa de prazo. Exemplos: prazo-ate-1-ano, prazo-1-a-2-anos, prazo-2-a-3-anos. | |
| distributors | No | IDs, nomes ou slugs dos distribuidores, corretoras ou instituições. Exemplos: XP Investimentos, Itaú, BTG Pactual, Banco Inter. | |
| investment_types | No | IDs, nomes ou slugs dos tipos de investimento. Exemplos: CDB, LCI, LCA, CRI, CRA, debêntures. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so the description adds value by detailing mode-dependent behavior (open vs Pro mode, limits, base URL usage). It includes important caveats about data being indicative. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and filters. It includes necessary behavioral details, though slightly verbose in explaining modes and URLs. Overall, each sentence 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?
Given the lack of output schema, the description adequately explains the return behavior (max items, detailUrl, etc.) and mode differences. The warning about data being indicative adds trust. Minor gap: no explicit mention of return fields beyond links.
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 100%, but the description adds semantic context beyond the schema, such as mode-specific limit tetos and the distinction between open and Pro access. This enhances the agent's understanding of parameter 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 'busca as melhores oportunidades de renda fixa disponíveis na Meelion' (searches for best fixed income opportunities), specifying the verb and resource. It distinguishes from sibling tools like get_quotes or get_investment_details by focusing on the ranking/comparison aspect.
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 explicitly lists when to use: comparisons of CDB, LCI, LCA, etc., rankings by maturity, type, broker. It provides English keywords for broader understanding. However, it does not explicitly state when not to use or mention alternative tools, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_financial_indicatorsIndicadores financeiros do BrasilARead-onlyInspect
Retorna indicadores financeiros atualizados do Brasil acompanhados pela Meelion, incluindo Selic, CDI/DI, IPCA e poupança (valores vigentes). Para expectativas de mercado ou curva futura por ano, use get_future_projections. Use quando o usuário perguntar sobre taxas atuais, indicadores econômicos, inflação, juros, rentabilidade de referência ou contexto macroeconômico para investimentos de renda fixa. English keywords: Brazilian financial indicators, Selic, CDI, DI, IPCA, inflation, interest rates, savings account, fixed income benchmarks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the tool is clearly a read-only operation. The description confirms it returns 'valores vigentes' (current values), but does not add substantially beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with every sentence adding value. It front-loads the main purpose, then provides usage guidance and English keywords. It could be slightly shorter, but overall it is efficient and well-structured.
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?
Given the tool has no parameters and no output schema, the description fully covers what the tool returns and when to use it. It is complete for a simple read-only tool with clear annotations.
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, so schema description coverage is 100%. Baseline for no parameters is 4, and the description does not need to add parameter information. It appropriately conveys that no additional input is required.
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 it returns updated Brazilian financial indicators (Selic, CDI, IPCA, poupança) and distinguishes from sibling get_future_projections by specifying that for expectations or future curves, that sibling should be used. It also lists English keywords, ensuring an agent can select based on various phrasings.
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 explicitly states when to use: when user asks about current rates, economic indicators, inflation, interest, reference profitability, or macroeconomic context. It also tells when not to use (for expectations or future curves) and provides the alternative tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_future_projectionsProjecoes futuras de indices (Meelion)ARead-onlyInspect
Retorna projeções futuras agregadas por ano para Selic, DI (CDI), IPCA ou dólar (câmbio / Focus), conforme dados atualizados pela Meelion (mesma base que a API /api/indicadores/projecoes-futuras). Informe indice ou index com um dos valores: selic, di, ipca, dolar, cambio. Use quando o usuário perguntar sobre expectativas de juros, inflação futura, mercado implícito em DI, projeção do Copom, curva implícita ou cenário macro para renda fixa. English keywords: future Selic, DI futures curve, IPCA expectations, FX expectations, Focus report, implied rates, year-ahead inflation.
| Name | Required | Description | Default |
|---|---|---|---|
| ano | No | Ano civil para filtrar um único ponto da série; se omitido, retorna todo o período disponível. | |
| year | No | Alias em inglês de "ano". | |
| index | No | Alias em inglês de "indice" (obrigatório se indice omitido). | |
| indice | No | Slug do índice (obrigatório se index omitido): selic, di, ipca, dolar ou cambio (sinônimo de dólar). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's statement that it returns projections aligns. It adds minor context about the data source (Meelion) but does not disclose additional behavioral traits 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. It includes important usage context and keywords without excessive length. One sentence could be slightly tighter, but overall it's well-structured.
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?
No output schema is provided, yet the description does not detail the return format (e.g., array of objects, fields). It explains the input parameters well but leaves the agent guessing about the response structure, which is a gap for a tool with four parameters.
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 100%, so the description adds little beyond repeating schema details. It clarifies that indice or index is required, but the schema already states that in parameter descriptions. No new meaning is added for parameters.
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 returns future aggregated projections by year for specific indices (Selic, DI, IPCA, dollar). It uses a specific verb 'Retorna' and resource 'projeções futuras agregadas por ano', which distinguishes it from sibling tools like get_quotes or get_financial_indicators that deal with current data.
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 explicitly lists when to use the tool: 'Use quando o usuário perguntar sobre expectativas de juros, inflação futura...' and provides English keywords. However, it does not mention when not to use it or directly contrast with siblings, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_investment_detailsDetalhes de um investimentoARead-onlyInspect
Retorna detalhes completos de um investimento específico da Meelion a partir do ID ou slug, incluindo informações como tipo, emissor, distribuidor, rentabilidade, prazo, vencimento, garantias, riscos e demais campos disponíveis. Use quando o usuário quiser entender melhor uma oportunidade específica, comparar detalhes antes de investir ou aprofundar um item retornado por get_best_investments. English keywords: investment details, fixed income product, CDB, LCI, LCA, CRI, CRA, debenture, issuer, distributor, maturity, yield, guarantees, risk.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ID interno do investimento, se disponível. | |
| slug | No | Slug público do investimento na Meelion. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only and non-destructive. The description adds context about the return content (fields like type, issuer, yield, etc.), which is helpful. No contradictions. Could mention if any limitations apply (e.g., only published investments), but overall good.
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 one paragraph, informative but slightly verbose with both Portuguese and English. It is front-loaded with the core purpose. Minor redundancy in listing fields, but still efficient.
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?
Without an output schema, the description lists many fields, helping the agent understand what to expect. No mention of error handling or parameter requirements (e.g., at least one of id/slug). Still quite complete for a detail retrieval 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 100% with descriptions for id and slug. The description mentions using ID or slug but adds no additional syntax or format details beyond the schema. Baseline 3 is appropriate as the description provides marginal extra value.
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 returns complete details of a specific investment by ID or slug, listing many fields. It distinguishes itself from sibling get_best_investments (which returns a list) by focusing on a single item's details.
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?
Explicit usage guidance: 'Use when the user wants to understand a specific opportunity, compare details before investing, or deepen an item returned by get_best_investments.' This directly tells when to use and references the appropriate sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quotesCotacoes de moedas e ativosARead-onlyInspect
Retorna cotações atualizadas de ativos e moedas acompanhados pela Meelion, como dólar, euro, ouro, prata e Bitcoin. Use quando o usuário perguntar sobre câmbio, cotação atual, variação de moedas, metais ou criptoativos usados como referência de mercado. English keywords: USD/BRL, EUR/BRL, dollar, euro, gold, silver, Bitcoin, BTC, market quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| assets | No | Lista opcional de ativos desejados. Valores aceitos: usd, eur, gold, silver, btc. Se omitido, retorna todas as cotações disponíveis. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true and destructiveHint=false. The description adds that it returns 'atualizadas' (updated) quotes. No additional behavioral details like rate limits or data freshness are provided, but with annotations the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs (Portuguese and English), each sentence is necessary. No fluff, and the key 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 read-only quote tool with one optional parameter and no output schema, the description covers the core functionality, usage context, and examples. It could mention output format or that it returns only current quotes, but it's largely complete.
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 describes the 'assets' parameter with enum values and behavior when omitted (100% coverage). The description lists equivalent names (dólar, euro, etc.) but doesn't add significant new meaning beyond the schema. Baseline 3 is appropriate.
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 returns updated quotes for specific assets and currencies, with a list of examples. It explicitly says when to use it, providing strong purpose clarity.
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 gives explicit usage scenarios ('Use quando o usuário perguntar sobre câmbio, cotação atual...') and English keywords hint at contexts. It doesn't explicitly exclude other uses but is helpful for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.