iFood

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds important behavioral context: it can return a login link when no args are provided, and accepts a JWT token for session login. It also mentions a permanent config option. 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 only three sentences, highly concise. It front-loads the purpose and then efficiently explains the two usage methods without any extraneous words. Every sentence earns its place.

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 simple schema (1 optional param) and no output schema, the description provides enough context for an agent to select and invoke the tool correctly. It covers the two modes of authentication. It could mention that the token must be copied from the browser after login, but that's implied by 'log in in the browser, copy the access token'.

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 optional string parameter 'token' with 0% schema coverage. The description fully compensates by explaining that it should be a JWT token from the browser paste, and that omitting it returns the login link. This adds complete meaning.

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 is for authenticating IDE agents (Cursor, etc.) by logging in via browser and copying a token. It distinguishes itself from sibling tools (mostly ifood_* and others) as the sole authentication 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 explains when to use it: for authentication in IDE agents. It provides two usage scenarios (permanent config vs session paste) and indicates that no args returns a link. It does not explicitly state alternatives, but that's acceptable as no other sibling tool handles authentication.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds value by specifying two response scenarios (authenticated vs missing credentials) and returned fields like authenticated, pending[], connect_url. 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, no filler. Front-loaded with core purpose, then condition-specific details. Every sentence earns its place.

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?

Low complexity tool with 0 params and no output schema. Description covers the two possible return states sufficiently, making it complete for agent 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?

No parameters, so schema coverage is 100%. Baseline 4 applies; description correctly avoids adding parameter info since none exist.

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 connection status and URLs, with distinct cases for all providers connected vs. missing credentials. Differentiates from sibling 'authenticate' which handles auth flow.

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?

Implied usage is checking connection status before authentication or other operations, but no explicit guidance on when to use vs. alternatives like 'authenticate' or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only and idempotent. The description adds that it is chart-ready and supports batch execution. This supplements the 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?

The description is two sentences, each adding value: first sentence details the output, second adds bulk support. No filler words; front-loaded with 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 no output schema, the description adequately outlines return fields (totals, price range, category mix). It also covers batch behavior. Could hint at optional parameters, but overall sufficient for this summary 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%; description only explains merchant_ids for batch execution. It does not clarify account or merchant_id parameters, leaving ambiguity. Partial compensation for the bulk mention but insufficient for full parameter understanding.

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 provides a menu summary with chart-ready data, including totals, price range, and category mix. It distinguishes itself from sibling tools like ifood_list_catalogs and ifood_list_categories by focusing on aggregated metrics.

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 indicates it is ideal for menu composition charts and mentions bulk support for merchant_ids, implying it's for batch summary. However, it does not explicitly exclude other use cases or compare to similar summary tools like ifood_financial_summary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

As anotações já indicam readOnlyHint e idempotentHint, mas a descrição vai além ao informar que os dados são buscados automaticamente em janelas de até 8 dias, um detalhe comportamental importante. Não há contradição com as anotações.

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 descrição é concisa, com informações-chave (dados incluídos, formato de data, janela de busca) no início. Cada frase agrega valor, sem redundâncias. Apenas um ponto menor de estrutura: poderia separar melhor o que é retornado.

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?

Com 3 parâmetros e sem schema de saída, a descrição cobre razoavelmente o que é retornado (campos como total de pedidos, faturamento, etc.), mas não menciona aspectos como autenticação necessária ou limites de requisição, que seriam úteis para completude.

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?

A cobertura de descrição no schema é 0%, então a descrição precisa compensar. Ela explica o formato de data (YYYY-MM-DD) e o padrão de últimos 30 dias para start_date e end_date, mas não fornece detalhes sobre o parâmetro account, deixando uma lacuna.

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?

A descrição especifica claramente que a ferramenta fornece um resumo financeiro agregado do período com dados como total de pedidos, faturamento bruto e ticket médio, além de séries diárias e por forma de pagamento. Isso a diferencia de ferramentas irmãs como ifood_list_sales que listam vendas individuais, indicando um propósito distinto.

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?

A descrição menciona que é 'ideal pra gráficos de vendas no tempo', fornecendo um contexto de uso implícito. No entanto, não há orientação explícita sobre quando não usar esta ferramenta ou alternativas para outras necessidades, como filtrar por usuário ou workspace.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not contradict them. It adds the behavioral detail of bulk execution support, but this is already implied by the parameter merchant_ids. No further 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 redundant text. The first sentence lists return fields concisely, the second adds bulk support. 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 the tool is a simple get operation with no output schema, the description adequately lists the main return fields and notes bulk support. It is complete enough for an agent to understand what the tool does and what to expect, though it could clarify the account parameter.

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 0% description coverage. The description partially compensates by explaining merchant_ids for batch execution, but does not explain account or merchant_id. Thus it adds some semantic value but not complete for all parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves merchant details (nome, razão social, etc.), contrasting with sibling ifood_list_merchants which lists merchants. However, it does not explicitly differentiate when to use get vs list, so it lacks full sibling differentiation.

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 hints at usage by noting bulk support via merchant_ids, but does not provide explicit guidelines on when to use this tool versus alternatives like ifood_list_merchants, or 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: output structure (shifts with dayOfWeek, start, duration) and bulk execution support, which goes beyond annotation information.

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: first describes the output, second mentions bulk support. No redundant text, 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 tool with 3 optional parameters and no output schema, the description gives sufficient context: what is retrieved, the output format, and batch capability. Lacks explanation of the account parameter, but overall adequate.

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%. The description explains merchant_ids for bulk execution and hints at output structure, but does not clarify account or merchant_id parameters individually. Partial compensation for missing 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 it retrieves store opening hours, specifying the structure (shifts per day with dayOfWeek, start, duration in minutes) and mentions bulk support via merchant_ids. This distinguishes it from sibling tools like ifood_list_merchants.

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 indicates bulk support but does not explicitly state when to use this tool versus alternatives or provide prerequisites. Usage context is implied but not fully described.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 adds value by specifying the return format (CSV links) and the input format (YYYY-MM). However, it does not disclose further behavioral details like pagination or data 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 sentence, concise and to the point. It could be slightly more structured (e.g., bullet points for parameters), but it is not 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, the description partially explains the return (CSV links with financial data per order). However, it does not specify the exact structure of the response or error handling, leaving some gaps.

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 must explain parameters. It clarifies that 'competence' expects YYYY-MM format, but does not explain the 'account' parameter (optional). This leaves 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?

The description clearly states it retrieves financial reconciliation files (CSV links) for a given month (competência in YYYY-MM format). The verb 'get' and resource 'reconciliation' are clear, but it does not differentiate from sibling tools such as ifood_financial_summary or ifood_list_settlements.

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. The description does not mention when not to use it or provide context for choosing among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the real-time nature and the returned data (open/closed, available, reasons), which 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?

Two sentences, front-loaded with the primary purpose. No extraneous information, and 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?

With no output schema and three parameters (one explained), the description covers the core functionality and bulk support. Missing details about the account parameter, but overall it is reasonably complete for a status-check 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?

Schema description coverage is 0%, so the description must compensate. It explains merchant_ids for bulk execution but does not clarify account or merchant_id parameters. This is partially helpful but insufficient for full parameter understanding.

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 real-time operational status (open/closed, available, reasons). The verb 'get' and resource 'status' are specific, and the tool's purpose is distinct from sibling tools like ifood_list_merchants or ifood_get_opening_hours.

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?

Provides explicit guidance on bulk support via merchant_ids parameter, indicating batched execution. However, it does not specify when not to use this tool or mention alternatives beyond the implicit bulk capability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate a safe, read-only operation. The description adds the scope 'linked to this install,' which provides useful context beyond annotations. However, no additional behavioral details (e.g., response format) are given.

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 efficiently. However, it could be structured more clearly with headings or bullet points for better readability.

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 lacks details on output format, pagination, or error handling. It mentions output fields (merchant_id, label) but does not explicitly state what the tool returns, leaving the agent uncertain about the response structure.

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 description does not explain the single parameter 'account' (type string). With 0% schema description coverage, the parameter's purpose is completely undocumented, forcing the agent to guess or test.

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 that the tool lists iFood stores (connections) linked to the install, and mentions output fields merchant_id and label. This differentiates it from other list tools like ifood_list_merchants, though the distinction could be sharper.

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 ifood_list_merchants. No examples or prerequisites provided, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds the constraint that it only lists anticipations if the store contracted anticipation, and specifies date format. Additional details like pagination or sorting are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences, no unnecessary words, and effectively communicates the core purpose. It is not overly verbose, but could be organized with parameter hints.

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 3 parameters with no output schema and many sibling tools, the description lacks details on return structure, error conditions, and the meaning of the 'account' parameter. It does not fully explain how the tool behaves.

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 must compensate. It mentions dates in YYYY-MM-DD format and that they are calculation dates, but does not explicitly describe the 'account' parameter or map each parameter to its meaning.

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 'receivables anticipations' in a period, using the verb 'list' and specifying the resource (anticipations) and scope (period). It distinguishes from sibling tools like ifood_list_settlements and ifood_financial_summary by focusing on anticipations.

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. It does not state when not to use it or mention related tools for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of bulk support adds some context. However, no additional behavioral details like pagination or rate limits are provided.

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 with no wasted words. Front-loaded with the core function and then bulk support. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers returned fields and bulk support adequately for a simple list tool, but lacks details on parameter interplay, defaults, or pagination. 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 coverage is 0%, and the description only explains merchant_ids for bulk. Parameters account and merchant_id receive no clarification, leaving their purpose and relationship unclear.

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' and resource 'catálogos', specifies returned fields (catalogId, groupId, status), and mentions bulk support, distinguishing it from sibling tools like ifood_list_categories.

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 ifood_catalog_summary. No explanation of prerequisites or context for batch vs single usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral details: default inclusion of items, and bulk support via merchant_ids and catalog_ids. This provides useful context 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 with no unnecessary words. It front-loads the core purpose and states bulk support efficiently.

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 6 parameters and no output schema, the description outlines return fields and bulk capability. However, it lacks detail on response structure (e.g., nesting, pagination) and does not cover all parameters or error scenarios.

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 must compensate. It explains that catalog_id is primary and that arrays are for batch execution, but does not explain account, merchant_id, or include_items in detail. It adds some meaning but is 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 it lists categories of a catalog with items by default, specifying the fields returned (id, name, status, items). It distinguishes from sibling tools like ifood_list_catalogs (which lists catalogs) by focusing on categories within a catalog.

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 versus alternatives. It mentions bulk support but does not compare to sibling tools or provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds that it lists 'active/scheduled' interruptions and supports batch execution via merchant_ids, providing 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 concise sentences with front-loaded purpose. No redundant information; every word earns its place.

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 basic purpose and bulk capability but omits details about output format, filtering, pagination, or parameter usage beyond merchant_ids. Given no output schema, more context would be helpful.

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 only adds meaning for merchant_ids ('bulk support'). Account and merchant_id parameters are left unexplained, 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?

The description clearly states it lists active/scheduled interruptions for a store (loja) and mentions bulk support. It distinguishes from sibling tools (e.g., ifood_list_merchants) by focusing on interruptions, 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?

No guidance on when to use this tool versus alternatives like ifood_list_merchants or ifood_get_status. No when-not or prerequisite conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool returns specific fields (id, nome, razão social) and that pagination is capped at max 10 items. This provides useful context beyond the annotations, though it does not describe the response format or potential errors.

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, consisting of two short sentences that front-load the main purpose. Every word adds value, and there is no redundant information. The structure is optimal for quick comprehension.

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 list tool with no output schema, the description covers the return fields and pagination limits. However, it leaves the `account` parameter unexplained and does not mention default values, ordering, or any filtering logic. This is 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?

The input schema has 3 parameters with 0% description coverage. The description explains `page` and `size` (with max 10 for size), but does not mention the `account` parameter at all. With no schema descriptions, the tool description should cover all parameters, but it only covers two of three.

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 stores with id, name, and company name. It is specific to listing merchants, distinguishing it from singular tool `ifood_get_merchant`. However, it does not explicitly differentiate from other list tools like `ifood_list_accounts` or `ifood_list_catalogs`.

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 listing visible stores with optional pagination, but does not provide explicit guidance on when to use this tool versus alternatives such as `ifood_get_merchant` for a single store or `ifood_list_accounts` for accounts. No exclusion criteria 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about pagination and bulk execution via 'merchant_ids', which are beyond the annotation scope. 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 consists of two concise sentences, front-loaded with the core purpose and use cases. No extraneous 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?

With 5 parameters, no output schema, and no parameter descriptions in the schema, the description is too minimal. It covers only the overall purpose and bulk capability but lacks details on pagination limits, parameter meanings, and return structure.

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 5 parameters with 0% description coverage. The description only implies 'page' and 'size' via 'paginadas' and mentions 'merchant_ids' for bulk, but fails to explain 'account' or 'merchant_id'. The description does not sufficiently 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 it lists individual reviews (nota, comentário, data) and is paginated, with specific use cases (histogram of ratings or reading recent comments). It distinguishes from the sibling 'ifood_reviews_summary' which likely provides summary statistics.

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 use cases ('pra histograma de notas ou ler comentários recentes') and mentions bulk support via 'merchant_ids'. However, it does not explicitly state when not to use this tool or list alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds specific data fields and API constraint (max 8 days) beyond annotations (readOnly, idempotent, non-destructive). 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?

Two concise sentences with key information front-loaded: what it does (list raw sales), data included, and critical limitation. 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?

Covers purpose, usage constraints, and sibling distinction, but lacks parameter explanations and full output details. However, no output schema exists, so description could be more 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 has 3 parameters with 0% description coverage. Description mentions 'período' (period) implying date range but does not explain individual parameters like 'account' or provide format/details.

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 lists raw sales/orders with payment details for detailed analysis, distinguishing it from 'ifood_financial_summary' which handles long periods.

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 mentions when to use (detailed analysis of raw sales) and when not to (long periods, offering alternative 'ifood_financial_summary'). Also warns about API window limitation of 8 days.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and the description reinforces this by describing it as a list of received settlements. It adds useful behavioral context: the date format (YYYY-MM-DD) and that results include net value and balance, which go 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 clear sentence with no redundancy. It efficiently conveys the essential information without extraneous 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?

Given the moderate complexity (3 parameters, no output schema), the description explains the purpose and date format but omits the account parameter and provides no return structure details. With no output schema, more detail on returned fields 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?

Schema has 3 parameters with 0% description coverage. The description partially compensates by mentioning date parameters ('Datas YYYY-MM-DD') and the period concept, but does not explain the 'account' parameter. Thus, it adds meaning for two of three 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?

Description clearly states the tool lists settlements received in a period, with net transferred value and balance. The name already indicates the resource, and the description adds specifics. However, it does not explicitly differentiate from sibling list tools (e.g., ifood_list_anticipations), but the resource is distinct.

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. It implies a date range is needed but does not specify prerequisites, exclusions, or conditions for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 value by specifying bulk support ('accepts merchant_ids for batched execution'), but 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?

Two concise sentences, front-loaded with purpose. Every sentence adds value with no unnecessary 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?

Given simple tool with no output schema and 0 required params, description covers purpose and bulk support adequately. Lacks detail on fallback behavior when no params provided, but overall 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?

Schema coverage is 0%, so description must compensate. It clarifies 'merchant_ids' for bulk execution, but doesn't explain 'account' or 'merchant_id'. Partial compensation for low 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 'Resumo das avaliações da loja: nota agregada (score) e contagem total/válidas', using specific verb+resource (summary of reviews with aggregate score and counts). It distinguishes from sibling 'ifood_list_reviews' which likely provides individual reviews.

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?

Describes ideal use case ('Ideal pra indicador de satisfação') and mentions bulk support. Although it doesn't explicitly state when not to use or name alternatives, the purpose is sufficiently distinct from siblings like 'ifood_list_reviews'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=false, the description discloses write behavior and permission needs. It explains that invoke runs tools without installation, returns connect links for credentials and checkout links for payment, and that install makes tools permanent. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but efficient, with every sentence adding value. It is front-loaded with the core flow. However, it could be more structured (e.g., bullet points) for easier scanning, given its length.

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 complex with 13 parameters and no output schema. The description covers the workflow and high-level parameter roles but lacks details for several parameters (e.g., arguments format, immediate flag). It is not fully complete for an agent to use without additional info.

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 must add meaning. It explains the action parameter and its values (search, describe, invoke, etc.), and mentions key parameters like mcp_id, tool_id, and arguments. However, many parameters (immediate, tier_slug, conversation, etc.) are not explained, leaving gaps.

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: the official marketplace for MCPs and tools, with a core flow of search, describe, and invoke. It distinguishes itself from siblings and external registries, providing specific use cases like 'find an MCP that does X'.

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 when to use this tool first over alternatives, differentiates between invoke (one-off) and install (permanent), explains permission requirements (admin for writes), and details next steps for auth or payment issues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate idempotentHint=true (safe to repeat), readOnlyHint=false (write operation), and destructiveHint=false (not destructive). The description adds that the tool reports a bug, implying a write action, but offers no additional behavioral context beyond what annotations provide. The description is consistent with annotations, so no 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?

The description is a single, concise sentence that front-loads the purpose and key usage instruction. Every word is meaningful with no 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 tool with 3 parameters and no output schema, the description is adequate but incomplete. It covers the main purpose and hints at using the conversation parameter, but lacks details on the format of 'conversation' (presumably a JSON string) and the role of 'context'. The description does not explain return values or what happens after reporting, but given the tool's nature, a score of 3 is reasonable.

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 0% description coverage, so the description must compensate. It partially explains the 'conversation' parameter (to include for reproduction) but does not explain 'message' (required) or 'context' (optional). No format or additional semantics are provided for these parameters, 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?

The description clearly identifies the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb ('Report') and resource ('bug/missing feature/feedback'), and it is distinct from sibling tools, which are primarily focused on iFood operations.

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 guideline: 'Include the conversation array with recent messages for reproduction.' This tells the user when to include the conversation parameter, providing clear context. However, it does not explicitly state when not to use the tool or provide alternative tools, but given its unique purpose, this is acceptable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds specific context about what versions are shown (platform and adapter), enhancing 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?

A single, front-loaded sentence with no waste. Every word contributes to the 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 no parameters, no output schema, and comprehensive annotations, the description provides sufficient context for a tool that simply displays version information.

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, and schema coverage is 100%. Baseline for zero parameters is 4, and the description does not need to add 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 explicitly states the tool's function: showing current MCP platform and adapter versions. It clearly distinguishes from siblings like ifood tools or 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?

No explicit guidance on when to use this tool vs alternatives such as 'toolkit_info'. However, for a simple informational tool, usage is implied when version details are needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the specific return content (MCPs, connection status, catalog tool count), which is useful context 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 that front-loads the purpose ('Returns the current toolkit state') and includes precise details without any waste.

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 fully explains the return values (installed MCPs, connection status, catalog tool count). For a no-parameter, informational tool, this is sufficient and 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?

No parameters exist, and schema coverage is 100% (trivial). According to guidelines, 0 params yields baseline 4. The description correctly mentions no parameters are 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?

The description specifies the verb 'Returns' and the resource 'toolkit state', and lists the exact content (installed MCPs, connection status, catalog tool count). It clearly distinguishes itself from sibling tools like ifood_* which are domain-specific.

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 implies the tool is for obtaining an overview of the toolkit's installed MCPs and their status. It does not explicitly state when not to use or list alternatives, but the context is straightforward for a no-parameter info tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.