Your consolidated B3 investment portfolio (the central depository): position by asset, net worth, tr
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.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 2.1/5.
Most tools have clearly distinct purposes, with consistent b3_get_/b3_list_ prefixes. However, there is some potential confusion among portfolio-related tools (b3_get_carteira, b3_get_patrimonio, b3_get_evolucao_patrimonial) and between b3_get_posicao and b3_list_ativos, though descriptions help mitigate ambiguity.
The B3-specific tools follow a consistent pattern (b3_get_/b3_list_ + noun), but the inclusion of platform tools like authenticate, connect, marketplace, report_bug, show_version, and toolkit_info breaks consistency by mixing languages (Portuguese vs English) and naming styles (verbs vs nouns).
With 20 tools, the count is slightly high but reasonable given the depth of B3 data covered (portfolio, transactions, dividends, etc.). The addition of 5 platform utilities could be seen as scope creep, but the core set is well-scoped.
The tool surface covers the main investor needs: authentication, portfolio overview, detailed position, historical evolution, transactions, dividends, and public offerings. Minor gaps like corporate actions or order placement exist, but the set is comprehensive for data retrieval.
authenticateAMCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true. The description adds context: config is permanent and non-expiring, token usage is session-only. It discloses the tool's behavior based on arguments, and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise and front-loaded with the main intent. It manages to pack multiple usage scenarios into a few sentences. Minor redundancy ('log in in the browser, copy the access token' could be tighter), but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention return values or error handling. Since there is no output schema, the agent is left guessing what happens on success (e.g., response with a session token or status). This is a notable gap, but the tool's core behavior is well-covered.
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?
Only one parameter 'token' with 0% schema description coverage. The description explains its meaning: call with token for session login, or omit to get the authentication link. This adds significant value beyond the schema.
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 is for authentication, detailing two methods: permanent via config or session via token. The verb 'authenticate' and resource are specific, and it distinguishes from sibling tools which are all B3-related or other actions.
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?
Explicitly explains when to use config for permanent auth, when to call with token for session, and when to call with no args to get the link. Includes a recommendation ('Best') and mentions the session-only alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_carteiraBResumo da carteira agrupado por classe de ativo (ações, FIIs, renda fixa, etc.) com valor e percentual de cada grupo.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| quantidade | No | ||
| agrupamento | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context about the output structure (grouped by class with value and percentage), which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded, but it omits all parameter information. While concise, it is incomplete for a tool with 3 undocumented parameters.
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 and 0% schema coverage for 3 parameters, the description is insufficient. It only describes the output purpose, leaving parameter usage entirely undocumented. The tool's complexity is moderate but the description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain the three parameters (account, quantidade, agrupamento) at all. This is a critical gap; the agent has no guidance on how to use these 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 it returns a portfolio summary grouped by asset class with value and percentage. This distinguishes it from sibling tools like b3_get_patrimonio (likely total portfolio) and b3_get_posicao (positions without grouping).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a grouped summary by asset class is needed, but does not explicitly state when to use this tool vs alternatives like b3_get_posicao or b3_get_patrimonio. No exclusions or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_evolucao_patrimonialCSérie histórica de evolução do patrimônio na B3.
| Name | Required | Description | Default |
|---|---|---|---|
| ap | No | ||
| data | No | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, idempotentHint: true, and destructiveHint: false, so the safety profile is clear. However, the description adds no additional behavioral context (e.g., data lag, authentication requirements, return format) 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 a single sentence, which is concise, but it is too short to be considered appropriately sized. It lacks essential details about parameters, output, and usage, making it incomplete.
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 3 undocumented parameters and no output schema, the description is grossly inadequate. It fails to explain what each parameter does, what the return value represents, or how the tool behaves. The description is completely insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (ap, data, account) with 0% schema description coverage. The description does not explain any of these parameters, leaving their meaning and usage completely unspecified. The description should compensate for the lack of schema descriptions, but it does not.
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 says 'Historical series of portfolio evolution on B3,' which gives a general purpose but is vague and does not differentiate from siblings like b3_get_patrimonio (portfolio) or b3_get_posicao (position). The verb 'get' implies retrieval, but the scope is unclear.
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?
No usage guidelines are provided. There is no indication of when to use this tool over alternatives, no prerequisites, and no context about typical use cases (e.g., historical analysis vs. current snapshot).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_patrimonioAPatrimônio total consolidado na B3 (soma de todas as corretoras) numa data. Retorna { valor, data }.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only and idempotent. The description adds context beyond annotations by explaining that the result sums assets across all brokers and returns only value and date. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and return format. Every word adds value, with no redundancy or unnecessary detail.
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 simplicity of the tool (two optional parameters, no output schema), the description covers the main operation and return format. However, it omits parameter details, leaving ambiguity about the 'account' parameter and date format. It is minimally viable but incomplete for an agent to use without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (data, account) with zero description coverage. The description only hints at the 'data' parameter by mentioning 'numa data', but does not explain its format or the purpose of 'account'. With 0% schema coverage, the description should compensate but fails to provide adequate parameter semantics.
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 retrieves total consolidated assets on B3 (sum of all brokers) on a date, and specifies the return format as {valor, data}. This is a specific verb-resource pair, and the description distinguishes it from siblings like b3_get_carteira (portfolio) or b3_get_posicao (position) by focusing on consolidated assets.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_perfilBCadastro/perfil do investidor (identidade da conta B3 conectada).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's minimal addition about identity context is acceptable but does not disclose any further behavioral traits like auth requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core purpose, but could benefit from additional structure or bullets for clarity without being verbose.
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 no output schema and a single optional parameter, the description is overly sparse; it lacks return value details and does not clarify how the account parameter affects results, leaving the agent under-informed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage and no parameter descriptions, the description fails to explain the optional 'account' parameter's meaning or default behavior, which is critical for correct invocation.
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 retrieves the investor's registration/profile ('Cadastro/perfil do investidor') and specifies it's for the connected B3 account, distinguishing it from sibling tools like b3_get_carteira or b3_get_patrimonio.
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?
No explicit guidance on when to use this tool versus alternatives; it only implies its purpose through the description, but does not discuss when not to use it or provide comparison with other b3_get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_posicaoAPosição DETALHADA por ativo numa data: ticker (codigoNegociacao), quantidade, preço de fechamento, valor atualizado, ISIN, instituição. Agrupado por tipo de produto. Paginado.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| pagina | No | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), description adds key behavioral traits: it is date-specific, grouped by product type, paginated, and includes specific fields like ISIN and institution. This provides useful context not in 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?
Single sentence conveys essential information efficiently, front-loading key components. However, it could be slightly restructured for clarity, e.g., listing parameters separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers returned fields, grouping, and pagination, which is adequate for a read-only tool with annotations. However, it lacks explanation of parameters and return format (especially since no output schema exists), leaving some gaps in understanding.
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 has 0% description coverage and no enums or required fields. The description vaguely hints that 'data' is a date and 'pagina' is for pagination, but does not explicitly describe each parameter's format, constraints, or how they relate to the output. More parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns detailed position by asset on a specific date, listing specific fields (ticker, quantity, close price, etc.) and is grouped by product type and paginated. This distinguishes it from siblings like b3_get_carteira or b3_get_patrimonio which provide different views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving per-asset position details on a given date, but does not explicitly state when to use this tool versus alternatives like b3_get_carteira or search tools, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_get_ultima_atualizacaoAData/hora da última carga de dados da B3 (a base é D-1). Use para saber quão fresca está a posição.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that data is based on D-1 (one business day delay), which is useful behavioral context beyond 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?
Two sentences: the first states what the tool returns, the second gives usage advice. No filler, front-loaded with key 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?
For a simple read-only metadata tool with one optional parameter and no output schema, the description covers main purpose and usage. However, it omits explanation of the optional parameter and the format of the returned date/time. Annotations mitigate safety concerns.
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 has one optional parameter 'account' (string) with 0% description coverage. The description does not explain what 'account' means or when to provide it, leaving the agent without guidance on its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns the date/time of the last B3 data load and implies its use to check data freshness. It is distinct from sibling tools like b3_get_carteira, but does not explicitly differentiate.
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 says 'Use para saber quão fresca está a posição' (use to know how fresh the position is), providing context for when to call it before using position-dependent tools. It does not state alternatives or exclusions, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_accountsCLista as contas da Área do Investidor B3 conectadas a este install — id, label.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal behavioral context: it confirms it lists accounts connected to the install. No additional traits like pagination or error states are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loads the purpose. However, it omits parameter documentation, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description only covers the basic purpose and output fields. The missing parameter documentation makes it incomplete for the agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'account' with 0% description coverage, and the description does not explain its meaning or usage. The agent has no information about what the parameter does or how to use it.
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 verb 'Lista' (lists) and the resource 'contas da Área do Investidor B3' (accounts from the B3 Investor Area), and specifies the returned fields 'id, label'. This distinguishes it from sibling tools like b3_list_ativos or b3_list_instituicoes.
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 provides no guidance on when to use this tool versus alternatives, such as other list tools. It does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_ativosADrill-down nos ativos de UM tipo de produto (informe codigoProduto), com valor e percentual de cada ativo do grupo. Para a posição COMPLETA de todos os ativos, use b3_get_posicao.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | ||
| agrupamento | No | ||
| codigoProduto | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, destructiveHint. Description adds return fields (value, percentage) and drill-down behavior, complementing annotations without contradiction.
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?
Two sentences, no fluff, front-loaded with action. Every sentence adds value.
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?
Covers main purpose, return fields, and sibling distinction. However, optional parameters are unexplained and no output schema exists, leaving gaps for agent decision-making.
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 has 0% description coverage. Description explains only codigoProduto (required). Optional parameters account and agrupamento are left undocumented, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'drill-down' for assets of one product type, and explicitly contrasts with sibling b3_get_posicao for full position. Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (single product type via codigoProduto) and when not to (for complete position, use b3_get_posicao). Provides clear alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_instituicoesCInstituições (corretoras) vinculadas ao investidor na B3.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so description doesn't add behavioral details. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure; it doesn't front-load essential details beyond a basic statement of function.
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?
Despite low complexity, the description omits parameter meaning and return value, making it incomplete for an AI agent to use effectively.
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 only parameter 'account' has no schema description and the tool description does not explain its purpose, leading to a complete lack of semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists institutions (brokers) linked to the investor, which is specific and distinct from other list tools in the sibling set.
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?
No guidance on when to use this tool versus alternatives like b3_list_accounts; no context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_movimentacaoBMovimentação de ativos (entradas/saídas: transferências, subscrições, bonificações, etc.) num intervalo. Paginado.
| Name | Required | Description | Default |
|---|---|---|---|
| pagina | No | ||
| account | No | ||
| dataFim | No | ||
| dataInicio | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe read. The description adds pagination behavior and date range scope, but does not disclose any additional behavioral traits like performance or authentication beyond 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 two sentences, front-loading the core purpose and key features (range, pagination). Every word earns its place with no verbosity.
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 lists paginated movements in a range, the description covers the main aspects. However, the 'account' parameter is not explained, and there is no return value description (output schema absent). Still, it is sufficiently complete for a straightforward listing tool with strong 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 input schema has 4 parameters with 0% documentation coverage. The description explains 'num intervalo' (date range) for dataInicio/dataFim and 'Paginado' for pagina, but does not mention the 'account' parameter. This provides partial semantic value but leaves one parameter unexplained.
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 handles asset movements (entries/exits like transfers, subscriptions, bonuses) within a date range and is paginated. This distinguishes it from siblings like b3_list_negociacoes (trades) and b3_list_ofertas_publicas (public offers). The verb is implied but not explicit, slightly reducing 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 provides no guidance on when to use this tool over alternatives. It does not mention when not to use it or compare to other list tools, leaving the agent to infer usage from the name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_negociacoesCNegociações (compras/vendas) num intervalo de datas. Paginado por page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| account | No | ||
| dataFim | No | ||
| dataInicio | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to restate safety. The description adds pagination behavior. However, it does not mention authentication requirements, rate limits, or any side effects 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 a single short sentence, which is very concise. It front-loads the core purpose and pagination detail. However, it could be slightly expanded without becoming verbose, e.g., adding a second sentence about required parameters.
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 exists, and the description does not describe the return format (e.g., list of trade objects with fields). It also lacks context about data freshness, authentication (sibling includes authenticate tool), or pagination limits. For a moderate-complexity tool with 4 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains page (paginated) and implies that dataFim/dataInicio define the date range. But no details on date format, account meaning, or any defaults. Users must guess the parameter semantics.
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 lists negotiations (compras/vendas) within a date range and mentions pagination. This is specific enough to distinguish from sibling tools like b3_list_ativos (list assets) or b3_get_carteira (get portfolio). However, it does not explicitly state the exchange context (B3) or that it returns a list of trades.
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?
No guidance on when to use this tool versus alternatives (e.g., b3_get_posicao for current positions, b3_list_movimentacao for different transactions). No mention of prerequisites, exclusions, or contexts where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_ofertas_publicasBOfertas públicas (IPOs/subscrições) do investidor num intervalo. Paginado por page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| account | No | ||
| dataFim | No | ||
| dataInicio | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description adds pagination and date-range context, but doesn't disclose behavior like empty results or rate limits. It adds moderate value beyond 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 extremely concise with two short sentences, front-loading the main purpose. Every word adds value, and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and 0% coverage, the description is too sparse. It fails to explain what 'ofertas publicas' means in this context or the role of the 'account' parameter. The agent may need to infer details that are not provided.
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 has 0% parameter description coverage, so the description must compensate. It partially explains 'page' for pagination and implies 'dataInicio' and 'dataFim' define the range, but doesn't clarify 'account' parameter. Given the low coverage, the explanation is insufficient.
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 lists public offerings (IPOs/subscriptions) for an investor within a date range. The verb 'list' and resource 'ofertas publicas' are specific, and pagination is mentioned. While it distinguishes from siblings by focusing on offerings, it doesn't explicitly differentiate from similar list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage with a date range ('num intervalo') and pagination ('Paginado por page'), but provides no explicit guidance on when to use this tool versus alternatives. No when-not or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_proventos_a_receberBProventos provisionados a receber (dividendos/JCP futuros) numa data de referência.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| pagina | No | ||
| account | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the behavioral detail that the list is scoped to a reference date, which adds some context beyond annotations. However, it does not disclose pagination behavior or data format expectations.
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?
A single sentence that is front-loaded with the key action. It is concise but could benefit from structuring around parameters and usage. The brevity does not sacrifice clarity for the core purpose.
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 three parameters with no descriptions, no output schema, and no examples, the description is too minimal to guide correct invocation. It does not explain date format, pagination mechanics, or account scope, making it incomplete for a tool that likely requires precise input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no meaning for the three parameters (data, pagina, account). The only hint is 'numa data de referência' which loosely relates to the 'data' parameter but offers no format or usage. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists provisioned earnings (dividends/future JCP) to be received on a reference date. It uses specific verbs and resources, and implicitly distinguishes from the sibling 'b3_list_proventos_recebidos' which lists already received earnings.
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?
No guidance on when to use this tool versus alternatives like b3_list_proventos_recebidos or others. The context signals show 19 sibling tools, but the description offers no comparison or usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
b3_list_proventos_recebidosBProventos já recebidos (dividendos/JCP pagos) num intervalo de datas. Paginado.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| account | No | ||
| dataFim | No | ||
| dataInicio | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that results are paginated and filtered by date range, which is useful but does not disclose additional behavioral traits such as authentication requirements, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose. However, it could benefit from a more structured presentation, such as listing parameters or grouping related 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 absence of an output schema and the presence of 4 parameters with no schema descriptions, the description is too sparse. It does not cover return values, date format requirements, or pagination details, leaving the agent with insufficient context to use the tool correctly.
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 has 4 parameters with 0% description coverage. The description only hints at date range and pagination but does not explain each parameter's meaning, format, or constraints. 'page', 'account', 'dataFim', and 'dataInicio' remain largely unexplained.
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 lists already received proceeds (dividendos/JCP pagos) within a date range and is paginated. It distinguishes from sibling 'b3_list_proventos_a_receber' which likely refers to pending proceeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving received proceeds with date filtering and pagination, but does not explicitly state when to use this tool versus alternatives like 'b3_list_proventos_a_receber' or other list tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectAReturns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only behavior. The description adds conditional behavior details (different responses based on connection state), which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return values for two key states but omits other possible states (e.g., partial connectivity) and error scenarios. Without an output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so the description does not need to add parameter meaning. Baseline of 4 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 connection status and URLs with specific conditions. However, it does not explicitly differentiate from the sibling tool 'authenticate', which might serve a related purpose.
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?
No guidance is provided on when to use this tool versus alternatives like 'authenticate'. The description does not mention prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaceAInspectThe official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them. Covers capability requests like "find an MCP that does X", "consulta um CPF", "is there a tool for Y". Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile (every tool with its id + params, pricing, auth) so you pick the right tool_id → invoke RUNS that tool. KEY: invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list. If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link (the user opens it, then you retry). Use install only to make an MCP PERMANENT in the active toolkit (its tools then show up natively in future sessions); prefer invoke for a single/occasional use. list_tools lists what is callable right now. subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits. Search/describe flag installed_in_toolkit vs installed_in_workspace. Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin. It also carries the mcp.ai PROMPT LIBRARY, which is about ready-made prompt TEXT rather than MCPs: search_prompts finds one, get_prompt returns its full text with {{variables}} filled, and publish_prompt saves a prompt and returns a shareable mcp.ai/p/ link that opens without login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| action | No | search | |
| mcp_id | No | ||
| message | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| immediate | No | ||
| tier_slug | No | ||
| prompt_body | No | ||
| prompt_slug | No | ||
| prompt_tool | No | ||
| prompt_vars | No | {} | |
| conversation | No | [] | |
| prompt_title | No | ||
| request_name | No | ||
| cancel_reason | No | ||
| cancel_comment | No | ||
| prompt_targets | No | ||
| report_context | No | ||
| prompt_category | No | ||
| request_details | No | ||
| prompt_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral traits beyond what annotations contain, including that invoke works even when the MCP is not installed, returns a connect link if credentials are needed, and returns a checkout/top-up link if the wallet is empty. It also clarifies that writes require workspace owner/admin and that the PROMPT LIBRARY is a separate feature area. No contradiction with annotations exists; in fact, it aligns with openWorldHint=true and readOnlyHint=false.
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 dense and information-rich, with no wasted sentences; every detail contributes to understanding the marketplace's breadth. However, it is a single unstructured wall of text, which could benefit from separation of the main MCP flow, the prompt library, and permission/edge-case notes. The length is justified given the tool's complexity, but the lack of structure makes it harder to scan.
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 tool with 14 actions, 23 parameters, and no output schema, the description covers an impressive amount of context: the end-to-end search/describe/invoke flow, install vs. invoke semantics, credential and payment handling, workspace permission requirements, and the separate prompt library. It even hints at return values (connect link, checkout link, shareable prompt link). The only minor gap is the lack of detailed return shapes for each action, but the description provides enough for an agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does explain the core parameter interactions: "action=search discovers MCPs by intent → describe returns one MCP's full profile... → invoke RUNS that tool." It also ties parameters like mcp_id, tool_id, and arguments to the action flow. However, several parameters remain undocumented (limit, immediate, tier_slug, cancel_reason, report_context, etc.), and their meaning is not inferable from the description, so the compensation is partial.
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 what the tool is: "The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them." It goes on to list concrete capabilities like search, describe, invoke, and install, and explicitly contrasts it with sibling tools by focusing on discovery and execution of MCPs. This makes the purpose unmistakable and distinct from the financial data tools (b3_*) and authentication tools.
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 provides explicit when-to-use guidance: "prefer invoke for a single/occasional use" and "use install only to make an MCP PERMANENT in the active toolkit." It also explains alternative flows, such as using list_tools for currently callable tools, report_bug for feedback, and request_mcp when nothing fits. This level of alternative and exclusion guidance is exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_bugAReport a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the tool's safety profile is known. The description does not add behavioral context beyond the annotations (e.g., what happens after reporting, if a ticket is created). The description provides no contradiction but also no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second gives a key usage tip. No redundant or irrelevant information. Every sentence adds value.
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 three parameters, no output schema, and existing annotations (idempotent, non-destructive), the description provides the core purpose and a crucial hint about the conversation parameter. However, it omits details about the required 'message' field, the optional 'context' parameter, and what the tool returns. Adequate but not fully complete for an agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), so the description must compensate. It explains the 'conversation' parameter's purpose ('include recent messages for reproduction'). However, it does not clarify 'message' (the primary required field) or 'context', leaving ambiguity. Partial compensation, but incomplete.
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's purpose: 'Report a bug, missing feature, or send feedback.' It specifies the verb 'report' and the resource types, and it distinguishes itself from sibling tools (e.g., financial tools, system tools) as the only feedback/reporting tool.
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 includes a usage hint ('Include the conversation array with recent messages for reproduction'), but does not explicitly state when to use this tool versus alternatives or note any conditions or exclusions. The hint is helpful but not comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_versionAShow the current MCP platform and adapter versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior; description adds specific context about what versions are shown, providing additional clarity beyond 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?
Single sentence, no extraneous words, efficiently conveys the tool's purpose.
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 tool with no parameters and no output schema, the description is fully sufficient to understand what the tool does and what it returns.
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?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter info; baseline score of 4 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?
Description clearly states verb 'Show' and specific resources 'MCP platform and adapter versions', distinguishing it from sibling tools that perform other actions like authentication or data retrieval.
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?
No explicit guidance on when to use this tool vs alternatives, but for a simple version display tool, usage is self-evident and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_infoAReturns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description aligns by stating it 'Returns' state. It adds behavioral context by enumerating the specific data fields returned, which is not in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and then lists the specific contents, making it easy to scan.
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, no-parameter read-only tool, the description covers the essential information: what it returns and the granularity of that data. No output schema exists, so this description must stand alone, and it does effectively.
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?
There are no parameters; schema coverage is trivially 100%. The baseline for zero params is 4, and the description adds no param semantics but also requires none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' and clearly identifies the resource: 'current toolkit state' with enumerated contents (installed MCPs, connection status, accounts, catalog tool counts), distinguishing it from sibling tools like show_version or marketplace.
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?
There is no explicit guidance on when to use this tool vs alternatives, but the description implies it should be used when you need an overview of the toolkit's current state, especially before connecting/authenticating. No exclusions or alternatives are mentioned.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.