Insights for your iFood store right in your AI assistant's chat. Generate charts of sales and payout
MCP.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?
Beyond annotations (idempotentHint true), the description adds behavioral details: it explains the two authentication methods, the fact that config is permanent and token is for session, and the link retrieval. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph, but well-structured and front-loaded with audience context. Every sentence adds value, covering different scenarios 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?
Given no output schema and simple annotations, the description covers all necessary aspects: the authentication flow, two methods, and instructions for the agent. It is sufficiently complete for the tool's purpose.
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 one parameter 'token' with no description. The description fully explains its meaning (a JWT), how to obtain it (via browser login), and how to use it (paste and call with token or no args for link). This compensates for the 0% schema coverage.
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: to authenticate for IDE agents like Cursor. It specifies the action ('log in') and the resource (the MCP server), and distinguishes itself from sibling tools which are functional (e.g., ifood, toolkit).
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 guidance on two usage scenarios: permanent config setup (adding Authorization header) and session login (pasting token). It also explains that calling with no args returns a link, giving clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns 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 read-only and idempotent. Description adds specific behavioral details about return values in different credential states, which enhances transparency 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?
Two sentences, no filler. Purpose stated first, then conditional behavior. 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 the two main scenarios and explains output fields. No output schema, but description fills the gap. Could mention data format (JSON) but not essential.
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 explains return values, which is the relevant information for a parameterless tool.
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?
Clearly states it returns connection status and URLs. Distinguishes between authenticated state and missing credentials state. Sibling 'authenticate' implies this is a status check, not the action.
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?
Implies usage for checking connection status, but does not explicitly compare to sibling 'authenticate' or state when not to use. The description covers both possible states, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna o catálogo/cardápio da loja no iFood (produtos, categorias e preços).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds the specific return content (products, categories, prices), which helps the agent anticipate the data shape. No additional caveats are given, but for a simple read-only tool the annotations cover the key safety profile.
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, front-loaded sentence with no extraneous words. It directly states what the tool does and is easily parsable.
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 tool is simple, has no parameters, and benefits from strong annotations. The description clearly specifies the output domain (catalog with products, categories, prices), making it complete for selection and invocation in this 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?
The tool requires no parameters, so the description contributes nothing to parameter semantics. Per the rubric, a zero-parameter tool receives a baseline of 4, which is appropriate here.
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 the store's iFood menu/catalog (products, categories, prices), which is a specific verb+resource and distinguishes it from sibling tools that handle orders, availability, or financial data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the catalog/menu is needed, but it does not explicitly mention alternatives or state when not to use it. No sibling tools are named, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status de disponibilidade da loja no iFood (aberta/fechada, pausas e horários).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds context by detailing the content (open/closed, pauses, hours). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence conveys all essential information without filler or 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?
For a zero-parameter read-only tool, the description adequately communicates the return content (aberta/fechada, pausas, horários). Given no output schema, this provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description focuses on the output, which is appropriate since there are no parameters to explain.
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 'Status de disponibilidade da loja no iFood (aberta/fechada, pausas e horários)' clearly specifies the resource (store availability) and the kind of information returned, distinguishing it from sibling tools like cardápio, financeiro, and pedidos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when store availability status is needed, but it does not explicitly mention when not to use it or alternatives. For a simple status tool this is acceptable but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumo financeiro agregado do período (total de pedidos, faturamento, ticket médio, série diária), pronto para gráfico.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context about the returned data (orders, revenue, ticket, daily series) and its chart-readiness, going 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?
The description is a single sentence with no unnecessary words, front-loading the core purpose and immediately providing the key content. It is concise and effective for an agent 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?
Without an output schema, the description lists the return fields (total orders, revenue, ticket médio, daily series) and states the chart-ready aspect, covering the main functional expectations. It lacks details like date format or response structure, but for a low-complexity tool this is mostly sufficient.
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 zero description coverage (0%), and the description only mentions 'período' without explicitly mapping to start_date/end_date or explaining their format. This gives a conceptual hint that the dates define the range, but it partially compensates at best.
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 'Resumo financeiro agregado do período' clearly defines the tool as an aggregated financial summary for a period, listing specific contents (total orders, revenue, average ticket, daily series). This distinguishes it from sibling tools like pedidos_listar or repasses by focusing on the summary level.
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 an aggregated financial overview is needed, and 'pronto para gráfico' suggests a charting use case. However, it does not explicitly mention when not to use it or name alternatives, leaving some room for ambiguity with other financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dados da conta/loja no Portal do Parceiro iFood (perfil, papéis e permissões).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds content scope (profile, roles, permissions) but does not disclose additional behavioral nuances like auth requirements or response structure. This meets the baseline for annotation-supplemented tools.
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, clear sentence that front-loads the key information (account/store data) and provides useful specifics in parentheses. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters or output schema, the description gives enough context to understand the tool's purpose and data domain. It lists the key content areas, but could be slightly more explicit about what is not included, though this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter explanations are needed. The description makes no claims about parameters, and the high schema coverage (vacuously 100%) means there is no additional semantic load on the description.
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 account/store data from the iFood Partner Portal, listing specific content types (profile, roles, permissions). This distinguishes it from sibling tools that handle other domains like menu, orders, or financials.
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 clear context about when to use the tool (when needing account/store data), but does not explicitly mention alternatives or exclusions. The sibling list is available, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detalhe de um pedido específico do iFood (status, datas, distância de entrega, id do parceiro).
Bulk support: accepts order_ids for batched execution.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ||
| order_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying the kind of data returned (status, dates, distance, partner id) and the bulk execution behavior ('Bulk support: accepts order_ids'). This goes beyond what annotations alone convey, without contradicting them.
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 exceptionally concise: two sentences that front-load the core purpose and add a note on bulk support. Every word contributes meaning, with no redundancy or filler.
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 detail-retrieval tool with two parameters, annotations, and no output schema, the description is fairly complete: it names the returned fields and the bulk option. It lacks details on edge cases (e.g., when both order_id and order_ids are provided) but is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does add meaning to order_ids by clarifying it enables batch execution, but order_id is not explained beyond its name and required status in the schema. The description partially compensates for the schema's lack of documentation.
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: 'Detalhe de um pedido específico do iFood' (detail of a specific iFood order) and lists the specific data returned (status, dates, delivery distance, partner id). This distinguishes it from sibling 'ifood_vendas_pedidos_listar' which is for listing orders, and the scope is specific to a single order or batch of orders.
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 when to use it (for details of a specific order) but does not explicitly compare with alternatives or state exclusions. It mentions bulk support for order_ids, which is a usage hint, but lacks explicit 'when to use vs listar' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os pedidos da loja no iFood por período (agrupados por dia, com status, valores e id), via a API interna do Portal do Parceiro.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| size | No | ||
| status | No | ||
| end_date | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it groups results by day and includes status, values, and id in the output. It also mentions the internal API source. 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 a single, efficient sentence that front-loads the primary action ('Lista') and packs in the key details. There is no redundant or filler content, making it easy to parse.
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 5 parameters, no output schema, and zero schema descriptions, the description is insufficient for an agent to correctly invoke the tool. It omits pagination behavior, date format expectations, valid status values, and the output structure beyond stating fields like status/values/id. The agent would likely need to make assumptions or seek additional documentation.
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 zero descriptions for its 5 parameters, and the description does not compensate. It only mentions 'período' which relates to start_date/end_date, but does not explain date formats, pagination (page, size), or how status parameter works (filter vs. output). The agent would be left guessing 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's function: 'Lista os pedidos da loja no iFood por período' (Lists store orders on iFood by period). It specifies the verb, resource, and scope, and mentions grouping by day with status, values, and id. This naturally distinguishes it from sibling tools like ifood_vendas_pedido_detalhe, which focuses on individual orders.
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 clear context for when to use the tool: to list orders over a period, grouped by day. It does not explicitly mention exclusions or alternatives, but the context is evident. The addition of 'via a API interna do Portal do Parceiro' gives further situational clarity. Missing explicit 'use this instead of X' guidance keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os lançamentos financeiros / repasses da loja no iFood (extrato financeiro do Portal do Parceiro).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds source context ('Portal do Parceiro') and scope ('da loja'), but does not disclose behaviors like pagination, ordering, or date range. This is acceptable given the simple list operation, but not beyond what annotations cover.
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 clearly states what the tool does without any filler. It is well-structured and immediately readable.
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 no parameters and read-only annotations, the description is mostly sufficient. It explains the domain and source. However, since there is no output schema, a brief mention of the return format (e.g., a list of entries) would improve completeness, but it is not critical.
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 zero parameters, so the schema is trivially fully covered. The baseline for zero parameters is 4; the description does not need to explain parameters, and it correctly focuses on the tool's 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?
The description uses the specific verb 'Lista' (lists) and identifies the resource as 'lançamentos financeiros / repasses da loja no iFood' (financial entries/pass-throughs of the store on iFood). It also adds context that this is the financial statement from the Partner Portal, clearly distinguishing it from sibling tools like ifood_vendas_financeiro_resumo.
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 when one needs to list financial entries/repasses, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools such as financeiro_resumo exist, but no differentiation guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 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 key behavioral traits beyond the annotations: invoke works even when the MCP is not installed, it returns a connect link for credential needs, a checkout link for empty wallets, and the one-off install behind invoke requires owner/admin. These details are not present in the annotations and are critical for the agent to anticipate side effects and user interactions.
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 long and dense but front-loads the core purpose and flow. It covers a complex multi-action tool in a single paragraph without wasting words, but it could benefit from bullet points or separation of the prompt library section for improved scannability.
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's complexity (23 parameters, 14 actions), the description covers the main operational flow, special cases (credential/payment links), permissions, and the additional prompt library feature. It lacks detail on some actions like 'resume' or 'list_tools', but the overall behavior and return patterns are sufficiently explained 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?
With 0% schema description coverage, the description compensates well by explaining the purpose of major parameters: action=search/describe/invoke, mcp_id, tool_id, arguments, and the prompt_* parameters for the prompt library. It does not explain every parameter (like limit, immediate, tier_slug), but the most important workflow parameters are clearly described, making the schema more interpretable.
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 the official mcp.ai marketplace, functioning as both a catalog and execution platform for MCPs/tools. It uses specific verbs like 'search', 'describe', and 'invoke' to describe its core operations, and it distinguishes itself from sibling tools by being the primary access point for discovering and running MCPs.
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 an explicit core flow (action=search → describe → invoke) and directly compares alternatives: 'Use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use.' It also notes that search/describe flag installation status and that write actions require workspace owner/admin, giving clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report 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 provide idempotentHint=true and destructiveHint=false. The description adds context about including conversation array for reproduction but no additional behavioral details beyond what annotations offer.
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 deliver the core purpose and a critical usage hint (include conversation array) with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided. The description covers basic functionality but omits what happens after reporting (e.g., response, confirmation). For a simple feedback tool, this may be adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only elaborates on the 'conversation' parameter. It does not explain 'message' (required) or 'context', leaving agents to infer their meaning from names alone.
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 explicitly states the tool reports a bug, missing feature, or feedback, distinguishing it from all sibling tools which are unrelated (e.g., authenticate, ifood_*).
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 clearly indicates when to use the tool (reporting issues or feedback) but does not mention when not to use it or alternatives, though no similar sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show 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 declare readOnlyHint and idempotentHint; description adds only the scope of versions shown, no additional behavioral context.
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, front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple, zero-param, read-only tool with annotations; missing output schema or return format detail.
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 (100% schema coverage); description need not add param info, but could mention return format.
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 states 'Show the current MCP platform and adapter versions' – specific verb+resource, clearly distinct from sibling 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?
No guidance on when to use vs alternatives; usage is implied by the tool's simplicity and naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns 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 already declare this as read-only, idempotent, and non-destructive, so the bar is lower. The description adds behavioral context beyond the annotations by detailing the specific contents of the returned state (installed MCPs, connection status, accounts, tool counts). 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 a single, well-structured sentence that front-loads the core purpose ('Returns the current toolkit state') and then compactly lists the contained data. Every word adds value; there is no fluff.
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 is a simple read-only query with no parameters and robust annotations, the description fully captures the return scope without needing an output schema. It lists all key parts of the state, making the tool's behavior predictable and complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly does not discuss parameters, and the schema confirms no inputs are needed. Nothing more is required here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and identifies a clear resource ('current toolkit state'), then enumerates what that includes: installed MCPs, connection status, accounts, and catalog tool counts. This clearly distinguishes it from the ifood data tools listed as siblings.
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 a use case (checking toolkit state) but gives no explicit guidance on when to use this tool versus alternatives like 'connect' or 'authenticate'. It does not mention any exclusions or prerequisites, but the context of being a status/summary tool makes the primary use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
Manage your Jumpseller store with AI. Products, orders, customers, and more.
Connect your Nubank account to AI via Brazil's Open Finance: balances, statements, cards, investment
Manage your Savanto store from your AI: catalog, content, prompts, and analytics, by chat.
Add one secure layer between your agents and this server.
Each iFood-specific tool targets a distinct resource (catalog, availability, financial summary, store, order detail, order list, transactions). The generic platform tools (authenticate, connect, marketplace, etc.) are also distinct. The only slight overlap is between connect and authenticate, but their descriptions clearly separate connection status from token-based login.
Names are all snake_case but follow mixed patterns. The iFood tools use a consistent 'ifood_vendas_' prefix followed by nouns or noun phrases (cardapio, disponibilidade, financeiro_resumo, pedido_detalhe). Platform tools use imperative verbs (authenticate, connect, report_bug) or descriptive names (toolkit_info). No uniform verb_noun convention exists across the set.
13 tools is within a reasonable range, but 6 of them (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) are generic platform utilities unrelated to iFood. This makes the server feel like a mixed bag rather than a focused iFood integration, reducing appropriateness for the server's stated purpose.
The iFood tools cover read-only workflows: catalog, availability, financial summary, store data, order listing, order detail, and financial transactions. However, there are no write operations (e.g., update menu, cancel order) and no search/filter capabilities beyond basic period-based listing. Core read operations are covered, but the surface is incomplete for full lifecycle management.
