big-mcp-b3

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a distinct function: listing funds, details, fundamentals, indices, options chain, comparison, real-time quote, price history, and dividends. There is mild overlap potential between cotacao_ativo (real-time price) and comparar_ativos (which also shows cotação), and fiis_lista vs. other asset tools, but descriptions clarify the boundaries well.
Naming Consistency3/5
Most tools follow an [noun]_[verb/style] pattern (fiis_lista, fii_detalhes, indices_b3), but naming mixes Portuguese domain prefixes (fiis_, fii_) with generic resource suffixes (_ativo). The verbs also vary grammatically: lista (noun-like imperative), detalhes, comparar (infinitive), cotacao, historico. The pattern is readable but not fully uniform.
Tool Count5/5
Nine tools is well-scoped for a Brazilian stock exchange (B3) data server covering quotes, fundamentals, indices, options, dividends, FIIs, and history. Each tool clearly earns its place without being excessive or too thin.
Completeness4/5
The surface covers the major investor workflows: real-time quotes, price history, fundamentals, dividend history, FII browsing, index quotes, options chains, and cross-asset comparison. Minor gaps include missing order/book trading depth and news/earnings calendar, but agents can complete typical research workflows without dead ends.
Average 3/5 across 9 of 9 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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. It doesn't disclose whether this is a read-only operation (though implied), whether there are limits on the option chain returned, whether expired options are included, or how much data is returned. For a quote/chain retrieval tool, this is a notable 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 efficient sentence with zero waste. It's appropriately compact for a straightforward retrieval 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?
With no annotations, no output schema, and only a one-line description, this is under-specified. The description doesn't explain what data the option chain contains (strikes, expirations, Greeks, volume), nor the relationship to the tipo filtering. For a tool returning a complex data structure (option chains), more context is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description mentions 'calls e puts' which maps to the tipo parameter enum. However, the description doesn't explain the default behavior (todas) or how the tipo filter affects results. The ticker examples (PETR4, VALE3) are in the schema already, so the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Gets option chain of an asset (calls and puts)' with a clear verb+resource, but it doesn't distinguish it from siblings like cotacao_ativo or historico_ativo adequately. Options are a distinct instrument type, so it does have some differentiation, but the description is terse and doesn't specify what 'cadeia' includes (expiration dates, strikes, prices).
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 when-to-use guidance is provided. The description doesn't mention when this tool is appropriate over cotacao_ativo (spot price) or fundamentus_ativo (fundamentals), nor does it state any prerequisites like a specific market context. No exclusions or alternatives are named.
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. The description only states it lists funds with filters, but doesn't disclose pagination behavior, default return size (though schema has default 20), what fields each returned FII contains, or how limit/segmento affect results. It doesn't state whether this is a read operation (implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's appropriately short for a simple listing tool. Could arguably be seen as slightly under-specified, but what's there is front-loaded and clear.
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 listing endpoint with no output schema and no annotations, the description is thin. It doesn't describe the return format or fields, doesn't clarify filtering semantics, and doesn't explain what 'filtros opcionais' means concretely beyond the two schema parameters. Given sibling tools suggesting a rich FII ecosystem, this listing tool would benefit from describing what kind of projections/summaries it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (limit and segmento) are already documented in the schema. The description mentions 'filtros opcionais' which aligns with the optional parameter structure. The description adds minimal value beyond the schema - it doesn't clarify expected segmento values (schema shows examples like shoppings, logística, lajes) or the meaning of limit's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists FIIs (real estate funds) with optional filters. It's a clear verb+resource, but it doesn't distinguish itself from sibling tools like 'fii_detalhes' (which presumably gives detail on a single FII) beyond the plural 'lista'. The scope of what a 'list' returns versus 'detalhes' is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There's no mention of when a user would prefer fiis_lista over fii_detalhes or other siblings. Context is minimal - the description doesn't clarify whether this is for browsing all funds, or for initial discovery before drilling into details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full behavioral burden. It does not describe return format (candles? prices?), data source constraints, or whether this is a read-only operation. For a data-retrieval tool, the lack of response-shape disclosure is a 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?
Single concise sentence; zero waste. Efficient and to the point. Would benefit from more detail but scores well on conciseness itself.
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 historical-data retrieval tool with no output schema and no annotations, the description is thin. It doesn't disclose what the response contains, units, or any caveats. Compared to sibling tools with clearer scopes, this description is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (ticker, periodo, intervalo) are documented in the schema itself. The description adds minimal extra semantic value beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Obtém histórico de preços de um ativo da B3' states a clear verb+resource (gets price history of a B3 asset). It does not explicitly distinguish from siblings like cotacao_ativo (current price), but the word 'histórico' (history) implies time-series retrieval. Adequate but no sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description gives no indication of when to prefer this over cotacao_ativo, comparar_ativos, or proventos_ativo. Usage context is only implied by the name and description.
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. The tool performs a comparison and likely returns a table/format for multiple assets, but the description doesn't detail what the output contains, what data source is used, or any limitations on comparison granularity or assets that can be mixed.
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, efficient sentence that is front-loaded with the verb 'Compara' and conveys the full purpose. Zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is mostly adequate. However, since no annotations exist, it would benefit from stating what the returned comparison contains or how to interpret results, and it could compare with sibling single-asset tools to guide selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single parameter 'tickers' is already documented in the schema as a list with min 2 / max 10 constraints. The description says 'múltiplos ativos' which adds marginal context, but the description doesn't add semantics beyond what the schema already specifies for the one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action — compares multiple assets side by side — with specific aspects (cotação, variação, proventos). It distinguishes the tool as a multi-asset comparison tool versus siblings like cotacao_ativo or proventos_ativo which handle single assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies single vs multi-asset use case by nature of the tool, but doesn't name alternatives (e.g., use cotacao_ativo for a single asset). A distinction from sibling tools that serve similar single-asset purposes is implicit only.
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 states it's a web-scraping tool (via fundamentus.com.br) but doesn't disclose whether data is live or cached, potential rate limits, failure modes when the site is unreachable, or whether the tool handles format variations in ticker input (e.g., PETR4 vs PETR4.SA). For a scraping-based tool, these behavioral traits are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the purpose and source in ~15 words. No wasted words, appropriately front-loaded. It's slightly under-specified relative to the completeness needs, but for a single-line description it's appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a web-scraping tool with no annotations and no output schema. The description doesn't explain what the return data looks like, which fundamentals are included beyond the examples, whether data freshness varies, or error handling for invalid tickers. For a scraping tool reaching an external site, the description should disclose more about behavior and data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the single ticker parameter having a clear description with examples (PETR4, VALE3, ITUB4). The description does not add parameter information beyond the schema, so the baseline of 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Obtém' (obtains) with a clear resource 'fundamentos de uma ação' and lists concrete fields (P/L, P/VP, ROE, margens). It clearly states the data source (fundamentus.com.br). It doesn't explicitly distinguish from sibling tools like cotacao_ativo or historico_ativo, but the focus on fundamentals is reasonably distinct from those.
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 through the fields listed (fundamentals for stocks), but provides no explicit when-to-use guidance or exclusions. Siblings like cotacao_ativo (quotes) and historico_ativo (history) suggest the context, but there's no explicit direction on when to choose this tool over comparisons, options, dividends, etc.
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. The description only says 'obtém detalhes' (gets details) which implies a read operation, but it doesn't specify what details are returned, whether it requires network access, rate limits, or any other behavioral traits. The agent has no sense of what the 'detalhes' include.
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 concise sentence that states the tool's purpose with zero waste. For a one-parameter tool with a well-documented schema, this is appropriately sized and no additional text is warranted.
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 single-parameter read-style tool, the description is mostly adequate. However, with no annotations and no output schema, the agent has no idea what 'detalhes' actually contains (nav, dividend yield, price, etc.), or whether it complements or overlaps with sibling tools like cotacao_ativo or proventos_ativo. Given the low complexity, this is a minimal but somewhat thin package.
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 100% for the single 'ticker' parameter, which has a clear description including examples (HGLG11, XPML11, KNRI11). The parameter is self-explanatory and the examples add practical value. Since schema already documents the sole parameter well, the description adds minimal but adequate value here.
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 'Obtém detalhes de um fundo imobiliário específico' (Gets details of a specific real estate fund) clearly states the verb (obtém) and resource (detalhes de um fundo imobiliário). It distinguishes itself from siblings like fiis_lista (which likely lists all FIIs) by focusing on a 'specific' fund, though it doesn't explicitly name differentiating sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for specific fund detail lookup vs listing all funds (fiis_lista), nor does it clarify what specific details are returned. There's no when-to-use or when-not-to-use 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 provided, the description carries the full burden of behavioral disclosure. It states the tool fetches quotes but doesn't disclose return format, whether data is real-time or delayed, pagination/limits, or whether the optional indices parameter is mutually exclusive. For a data-fetching tool, the behavioral contract is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, compact Portuguese sentence that communicates the core function and gives concrete examples. No wasted words or redundant restatement of the name 'indices_b3'. Efficient and front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single optional parameter with full enum coverage, and the description names examples. However, with no output schema and no annotations, the agent doesn't know what the response shape looks like, whether quotes are current or delayed, or what units (points, percent change). For a simple one-parameter fetch tool, this is minimally adequate but leaves open questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% - the single parameter 'indices' has a clear description ('Lista de índices para consultar') and a complete enum of valid values with a sensible default. The description adds the example list but the enum in the schema already fully defines acceptable values. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Obtém cotações') and resource ('principais índices da B3'), listing example indices (Ibovespa, IFIX, IDIV, SMLL). It's in Portuguese, consistent with the tool naming and sibling tools which are also Brazilian market tools. It distinguishes from siblings since no other tool mentions indices explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for getting index quotes as opposed to individual asset quotes (cotacao_ativo) or fund-specific data (fiis_lista, fii_detalhes). However, it doesn't explicitly state when to use this vs alternatives, nor does it mention when NOT to use it. The implied usage context is clear but no exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the behavioral disclosure burden. The description identifies the types of data returned (dividendos, JCP, bonificações), which adds transparency about output content. However, it doesn't disclose whether this is a read-only operation, rate limits, or what happens with assets lacking proventos. The output content disclosure earns a modest score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without wasted words. It's appropriately brief given the tool's simplicity and complete schema coverage. It could be deemed slightly terse but is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the primary source of behavioral context. It explains what data comes back (provento types) but doesn't mention sorting order, pagination beyond the limit param, or response format. For a read-only query tool with a well-defined schema, this is minimally adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (ticker with an example value, limit with default/range) are already well-documented in the schema. The description adds marginal value by listing the types of proventos returned, which contextualizes what 'ticker' refers to, but does not exceed the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Obtém/obtains) and resource (histórico de proventos - dividend history) with examples of provento types (dividendos, JCP, bonificações). It distinguishes from siblings by being asset-specific ('de um ativo') versus broader tools like fiis_lista or indices_b3, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings. Sibling tools like cotacao_ativo, historico_ativo, and fundamentus_ativo overlap in the market-data domain, yet no exclusions or alternative recommendations are provided. Context is implied (one wants dividend history) but no when-not-to-use guidance exists.
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 states real-time pricing (which implies a read operation) and B3 market scope, but doesn't disclose potential delays, error behavior for invalid tickers, or whether it returns bid/ask versus last trade price.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that packs the key information: real-time scope, B3 market, and supported asset classes. No wasted words; well-structured for scanning.
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 single-parameter tool, the description covers the core purpose. However, it doesn't mention return format, market-hours behavior, or handling of invalid/nonexistent tickers, which would be helpful for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the ticker parameter with examples (PETR4, HGLG11, AAPL34). The description adds the asset-class context but doesn't add meaning beyond what the schema provides. Baseline 3 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 states the verb 'Obtém cotação em tempo real' and the resource 'ativo da B3', which is clear and specific. It lists asset types (ação, FII, BDR, ETF), providing useful scope. It distinguishes from siblings like historico_ativo (historical) and opcoes_ativo (options), though doesn't explicitly name them.
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 real-time quote usage but doesn't explicitly state when to use it versus alternatives like historico_ativo (historical data) or comparar_ativos (comparing assets). No explicit exclusions or alternative recommendations are given, though the asset-type enumeration provides some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![big-mcp-b3 MCP server](https://glama.ai/mcp/servers/danielvm-git/big-mcp-b3/badges/card.svg)](https://glama.ai/mcp/servers/danielvm-git/big-mcp-b3)

Score Badge

Copy to your README.md:

[![big-mcp-b3 MCP server](https://glama.ai/mcp/servers/danielvm-git/big-mcp-b3/badges/score.svg)](https://glama.ai/mcp/servers/danielvm-git/big-mcp-b3)

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/danielvm-git/big-mcp-b3'

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