TOTVS Protheus

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

Annotations only provide safety/idempotency flags; the description adds the actual behavior: browser login flow, token copy, and the permanent-vs-session distinction. It is consistent with idempotentHint=true and destructiveHint=false and gives a good sense of side effects, though it omits error cases or invalid-token behavior.

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 compact and front-loads the core purpose before the usage alternatives. It contains informal asides like 'Best:' but every clause earns its place in explaining how the tool should be invoked.

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 one-optional-parameter tool this is nearly complete: it covers the token format, the no-args link mode, and the token lifetime trade-off. It does not describe the response shape or failure cases, and there is no output schema to fill that gap, so a small amount of uncertainty remains.

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 provides zero description coverage for the single optional token parameter. The description fully compensates by explaining the exact invocation contract: no args yields the login link, and passing { token: '<jwt>' } completes a session login. This is unambiguous enough to call correctly.

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 names the action (log in to MCP.AI), identifies the resource, and lays out concrete modes: browser login, copying an access token, configuring a permanent header, or pasting a token for a session. It is distinct from sibling tools like connect or the Protheus data 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?

It distinguishes permanent header configuration from session-only token pasting and explicitly states when to call with no args versus with { token: '<jwt>' }. It does not name an alternative sibling to prefer, but the two usage modes are sufficiently clear for an agent to choose correctly.

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 cover readOnly=true and destructive=false. The description adds concrete behavioral detail not covered by annotations: the two possible states (all connected yields authenticated:true with empty pending[], missing credentials yields connect_url). This is valuable since there is no output schema to convey this.

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

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

Two concise sentences that front-load the essential purpose and then clarify the two distinct output states. No wasted 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 that there is no output schema and no parameters, the description covers the core behavior adequately, describing both normal and missing-credential cases. It could mention potential error handling or edge cases, but these are minor for a status check tool given the 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?

Tool has zero parameters, so the schema contains all that is needed. Per the rubric, a 0-parameter tool gets a baseline of 4. The description does not need to elaborate on parameters and adds no redundant information.

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?

States a clear verb-resource pair: 'Returns connection status and URLs.' The description distinguishes this from siblings like 'authenticate' by specifying it returns status rather than performing authentication, so an agent can pick it without ambiguity.

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 its use case (checking connection status) but does not explicitly state when to use it versus alternatives or when not to use it. There is no direct exclusion or pointer to siblings like 'authenticate,' though the purpose is reasonably inferable.

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?

The description goes well beyond the sparse annotations by disclosing that invoke runs MCPs one-off without installing or bloating the tool list, that writes require workspace owner/admin, and that missing credentials/wallet produce connect/checkout links rather than failures. It also clarifies the prompt library operates on prompt TEXT, not MCPs, which is a key behavioral caveat.

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 text is long, but every sentence earns its place: definition, core flow, key invoke behavior, auth requirements, link-handling edge cases, and the separate prompt-library domain are each covered in distinct, dense passages. The use of 'KEY:', 'Core flow:', and uppercase emphasis makes the critical behavioral distinctions scannable despite the 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?

For a 23-parameter, 14-action tool with no output schema, the description covers the essential decision points: which action to pick, what invoke does differently, permission requirements, and what happens with missing credentials or empty wallets. Minor gaps remain — the `resume` action and `immediate`/`tier_slug`/`conversation` parameters are never explained, so a fully unassisted agent would still have to guess on those.

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, this description carries the full burden and largely delivers: it explains the action enum exhaustively (search, describe, install, invoke, etc.) and gives meaning to tool_id, mcp_id, arguments, and the prompt_* parameters through the flow narrative. However, it never mentions the `resume` action, `immediate`, `tier_slug`, or `conversation` parameters, leaving some of the 23 parameters semantically unattached.

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 opens with a precise definition: 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It clearly enumerates the two domains (MCP discovery/execution and prompt library) and walks through the search/describe/invoke flow, making it unmistakable what this multiplexer does and how it differs from the protheus_* and authenticate 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?

Explicit routing is provided for every major action: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', 'list_tools lists what is callable right now', and 'request_mcp asks us to build a NEW MCP when nothing fits.' It also tells the agent how to handle connect and checkout links (user opens it, then retry), so the call path is fully specified.

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 annotations já declaram readOnlyHint=true, destructiveHint=false e idempotentHint=true. A descrição adiciona que a operação é GET e somente leitura, reforçando as annotations, mas não oferece contexto comportamental extra, como formato de resposta, paginação ou limitações de uso. Sem contradição, mas sem grande valor adicional além das 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?

Duas frases curtas, sem repetição do nome da tool e com a informação essencial no início. Cada frase contribui: a primeira define a operação e o alvo; a segunda define quando usar e como descobrir a rota.

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?

A ferramenta é genérica e complexa, com 10 parâmetros sem descrição e sem output schema. A descrição informa o propósito e a rota de descoberta, mas não explica os parâmetros de consulta, formato de resposta ou comportamento de paginação, deixando lacunas significativas para uma invocação correta.

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 descritiva do schema é 0% e a descrição não explica nenhum dos 10 parâmetros (path, page, order, expand, fields, filter, params, account, page_size, sql_filter). O único indício é 'rota', que se mapeia a path, mas o restante fica totalmente sem semântica para o agente.

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 usa verbo específico (GET), recurso específico (qualquer rota REST do Protheus) e escopo claro, diferenciando-se das tools dedicadas. Menciona explicitamente APIs oficiais sem tool dedicada e endpoints MVC customizados, o que permite distinguir de imediato de protheus_catalogo e demais 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?

A descrição diz explicitamente quando usar (APIs oficiais sem tool dedicada e endpoints MVC customizados), quando não usar (APIs que já têm tool dedicada) e orienta a descobrir a rota com protheus_catalogo. Isso fornece orientação de seleção clara e acionável.

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 safety profile is covered. The description adds behavioral context by clarifying that the output is documentation, not live availability, and that it's extracted from public TOTVS documentation. This provides meaningful nuance beyond the annotations, though it doesn't describe other behaviors like pagination or error handling, which is acceptable for a read-only catalog.

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 three sentences with no filler. It front-loads the core purpose and immediately delivers the critical differentiation from siblings. Every sentence earns its place, and the structure is efficient and scannable.

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?

While the description clearly states the purpose and output fields, it omits any explanation of the parameters (which are fully undocumented in the schema) and does not describe the output shape beyond a list of fields. Without an output schema, the agent lacks details on how to properly filter or interpret results. For a tool with 4 parameters and no schema coverage, the description should have provided parameter guidance, making it incomplete for effective 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?

Schema description coverage is 0%, so the description must compensate for the four parameters (limit, termo, account, segmento). However, the description provides no explanation of any parameter or how they affect the results. It only discusses the tool's purpose and output fields. With zero schema coverage and no parameter information in the description, the agent has no semantic understanding of these parameters.

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

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

The description uses a specific verb ('Consults') and identifies the resource ('catalog of 125 official REST APIs from the Protheus line') and return fields (id, title, module, and read routes). It also clearly distinguishes itself from siblings by stating it serves to discover which route to pass to protheus_api and explicitly contrasts with protheus_diagnostico. This fully clarifies what the tool does and differentiates it from related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('to discover which route to pass in protheus_api') and when not to use it ('it's documentation, not availability; use protheus_diagnostico for what this installation responds'). It names the alternative and the condition that selects it, leaving no ambiguity about 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, idempotentHint, and destructiveHint, covering the safety profile. The description adds the internal-ID lookup mode and batch behavior, but does not explain pagination, parameter interactions, or what 'internal' means relative to external IDs.

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

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

The description is two short sentences with no filler. The core operation and batch capability are front-loaded, making it easy to scan.

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

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

With no output schema and 11 parameters at 0% schema coverage, the description leaves substantial gaps around filtering, pagination, field selection, and return shape. It covers the basic list/by-ID modes but is not complete enough for reliable invocation in complex cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only clarifies the 'id' and 'ids' parameters. The other nine parameters, including page, order, expand, fields, filter, params, account, page_size, and sql_filter, remain undocumented in both schema and 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 a specific verb and resource: listing accounting cost centers and/or querying one by internal ID. This differentiates it from the many sibling tools that target other Protheus resources.

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 directly conveys when the tool is appropriate: to list cost centers or fetch one by internal ID, with bulk execution support. It does not explicitly exclude alternatives, but the resource-specific scope makes the intended usage clear.

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, covering the safety profile. The description adds valuable behavioral context beyond those annotations: unfiltered calls return the entire collection, which implies potentially large results, and bulk execution via `ids` is supported.

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 compact and front-loaded with the tool's core purpose, followed by scoping semantics and bulk support. Every sentence adds useful information without 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?

Given the high parameter count (12), absence of an output schema, and no descriptions in the schema, the description covers only the core retrieval path. It omits pagination behavior, filter syntax, response shape, and other common usage details, so an agent may struggle with correct invocation in non-trivial cases.

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 and 12 parameters, the description must compensate, but it only explains `id`, `tipo`, and `ids`. Parameters like `page`, `page_size`, `filter`, `sql_filter`, `fields`, `order`, `expand`, `params`, and `account` remain undocumented, leaving significant ambiguity for an agent.

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 a specific verb and resource: consulting the customer/supplier registry via the CustomerVendor API. It also distinguishes behavior by input (`tipo`, `id`) and notes that no filter returns the whole collection, which sets it apart 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?

The description explains how to use the tool: no filter returns the full collection, `tipo` selects an entity type, and `tipo` plus `id` returns a specific record. However, it does not explicitly say when to prefer this tool over alternatives or mention exclusions, so context is clear but not comparative.

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 convey read-only, idempotent, and non-destructive behavior, so the description's burden is lower. It adds a useful behavioral detail about bulk execution via ids, but does not mention pagination, filtering behavior, or what the response looks like. This is adequate but not rich.

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 minimal and front-loaded: the purpose appears first, followed by a single high-value behavioral note. There is no redundant text 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?

Despite eleven parameters and no output schema, the description only explains the id/ids selection mechanism and bulk support. It omits pagination, ordering, filtering, expansion, field selection, and response shape, so an agent lacks enough context to call the tool correctly in many 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%, and the description clarifies only two of eleven parameters: 'id' and 'ids'. Several cryptic parameters such as 'expand', 'sql_filter', 'params', and 'page_size' receive no explanation, so the description does not compensate adequately for the 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 states a specific verb ('Consulta') and resource ('comissões de venda'), and clarifies that it can return a collection or a single commission by internal id. This clearly establishes the tool's core purpose, though it does not explicitly compare itself to 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 resource name and description imply the tool is for querying commission data, and the bulk support line gives some guidance on using ids for batched requests. However, there is no explicit statement of when to prefer this tool over alternatives or any exclusions, leaving usage partly to inference.

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 non-destructive behavior, and the description aligns by using 'Consulta.' The description adds useful behavioral context beyond annotations, such as bulk execution via `branch_ids` and the specific-record behavior with `branch_id` and `codigo`. 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 short, front-loaded with the core purpose, and every sentence adds operational value: filters, single-record lookup, and bulk execution. There is no filler or redundant repetition.

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 13 parameters, a 0%-coverage schema, nested objects, and no output schema, the description is not complete enough. It explains basic lookup and bulk behavior, but omits how to select between `pedido` and `solicitacao`, advanced filtering, pagination, and return-value expectations, all of which matter for a complex API surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate, but it only covers some parameters: the `params` filter keys (branchId, product, deliveryDate, warehouse), plus `branch_id`, `codigo`, and `branch_ids`. Important parameters such as `tipo`, `filter`, `sql_filter`, `fields`, `expand`, `account`, `page`, and `page_size` are left unexplained, so an agent may not know how to use them correctly.

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 ('Consulta') and clearly identifies the resource: purchase orders or MRP purchase requisitions. This is distinct from the many related protheus_* siblings, and an agent can understand both the domain and the object being queried.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage context: it explains which filters go into `params`, that `branch_id` plus `codigo` returns a specific record, and that `branch_ids` enables batched execution. It does not explicitly compare with alternatives, but the resource scope is specific enough to guide selection.

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 the tool read-only, idempotent, and non-destructive. The description adds useful behavioral detail about batched id execution and internal-id lookup, but does not disclose pagination or return format. This is acceptable given the strong annotation coverage.

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 brief, front-loaded with the core listing/lookup purpose, and contains no wasted words. The bulk-support note is dense and useful, though slightly more structural detail would improve scanning.

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 11 parameters, no output schema, and no per-parameter documentation, this description is too thin to fully support correct invocation. Important details such as pagination behavior, filtering, field selection, and response shape are absent.

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 needed to compensate for the 11 parameters. It only clarifies id/ids and batched execution; parameters such as page, order, expand, fields, filter, params, account, page_size, and sql_filter remain unexplained.

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

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

The description clearly names a concrete resource ('condições de pagamento') and states two explicit behaviors: listing all registered payment conditions and consulting one by internal id. It is specific and recognizable, though it does not explicitly distinguish itself 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?

It provides clear context for when to use the tool: to list payment conditions or fetch a specific one by id, with bulk execution supported via ids. It does not mention exclusions or alternatives, but sibling tools target different entities, so the context is largely sufficient.

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, covering the safety profile. The description adds the bulk execution behavior and the dual list/query mode, which goes beyond annotations. No contradiction is present, but no further behavioral context (e.g., error handling, pagination limits) is 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 two sentences with no wasted words. It front-loads the main purpose and immediately notes the bulk support. 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?

With 11 parameters and zero schema descriptions, and no output schema, the description is far from complete. It fails to explain pagination, filtering, field selection, or the 'params' object, leaving the agent unable to construct valid calls beyond basic id/ids 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?

The schema has 0% description coverage, so the description must explain all parameters. It only mentions 'id' and 'ids', leaving the other nine parameters (page, order, expand, fields, filter, params, account, page_size, sql_filter) completely undocumented. This is a severe gap that prevents correct usage.

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 and resource: it lists CRM contacts or queries a single contact by id. It distinguishes itself from sibling tools (e.g., protheus_clientes_fornecedores) by its specific focus on contacts, though it does not explicitly contrast with those 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?

It mentions bulk support through 'ids', which guides when to use that parameter vs a single 'id'. However, it does not provide any guidance on when to choose this tool over other protheus_* tools, nor any exclusions or prerequisites.

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?

While annotations already indicate read-only and non-destructive behavior, the description adds that it sends a minimal query to each API and classifies results into available, missing, permission-denied, or error. It also notes variability based on LIB version, licensed modules, and customizations.

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 core purpose, no redundant details. It delivers the essential information 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?

The description explains the tool's purpose and the variability of API availability, but omits the response format (beyond the classifications) and the parameter semantics. Since there is no output schema, the agent is left without the operational details needed for correct 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?

None of the three optional parameters (limit, termo, account) are explained in the description. With 0% schema coverage, the agent has no idea how to set these values, breaking correct invocation.

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

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

Clearly states it discovers which REST APIs a Protheus installation responds to, with specific details about probing the official catalog and classifying outcomes. It is distinct from sibling tools that focus on specific business 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?

Explicitly advises running this first on a new account, establishing it as a prerequisite step. Does not mention alternatives, but the 'primeiro' guidance gives a clear trigger 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description correctly avoids repeating those. It adds useful behavioral context: the two modules are distinct and may return divergent results, and it enumerates the MRP-included balances (blocked, consigned, quality control). 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 short (two sentences) but not optimally concise. It repeats 'saldo em estoque' and the second sentence is somewhat run-on. Still, it front-loads the key instruction about choosing the source.

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 10 parameters, no output schema, and no descriptions in the schema, the description is incomplete. It explains only the 'fonte' parameter and lacks guidance on filtering, pagination, or expected response shape. For a query tool, this is a significant 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?

Schema description coverage is 0%, so the description must compensate. It clearly explains the 'fonte' parameter with its two enum values and their semantics, which is valuable. However, it neglects the other 9 parameters (page, order, fields, filter, params, account, page_size, sql_filter) leaving them effectively undocumented, especially the complex nested 'params' object.

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 states a specific verb ('consulta' = queries) and a specific resource (stock balance) and distinguishes two sources (varejo vs. mrp) with concrete meanings. It clearly separates this tool from siblings like protheus_produtos or protheus_vendas_varejo by focusing on inventory balance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives. It only instructs on choosing between two internal sources ('fonte'), which is parameter selection, not tool selection. It never mentions sibling tools or conditions for preferring them.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the operation's safety profile is clear. The description adds useful context beyond annotations by identifying the API and explaining that the returned codes are consumed by other tools, clarifying response semantics. No contradiction exists.

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 filler, front-loading the verb and resource in the first sentence. The second sentence adds practical value by explaining why the tool matters, so every part 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 explains the tool's purpose, its role as a starting point, and the broad nature of the return data (company/branch codes), while annotations cover safety. However, with 9 undocumented parameters and no output schema, an agent gets no guidance on pagination, filtering, field selection, or response shape beyond the general statement, leaving clear 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% and none of the 9 parameters are documented in the schema. The description does not mention page, filter, fields, expand, or any other parameter, so it provides no compensation for the missing parameter documentation. This is a significant gap for a tool with this many 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 opens with the concrete verb 'Lista' and a specific resource ('empresas e filiais do grupo'), and identifies the underlying API (TSIBranches). This makes the tool's purpose clear and differentiates it from the many other protheus_* tools that concern different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly frames the tool as the 'ponto de partida prático' and explains that its output codes feed the tenantId header and branchId filters of other tools, giving clear when-to-use context. It does not list alternatives or say when not to use it, so it stops short of full exclusion guidance.

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 safety profile is covered. The description adds useful single-vs-batch behavior but does not explain pagination, filtering, or the response shape. This is adequate given the annotations, though not rich.

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 filler and fronts the purpose before the usage details. Every sentence earns its place, and the formatting clearly separates the base behavior from the bulk mode.

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 has 11 parameters and no output schema, yet the description only explains the two client-identifier parameters. Generic query and pagination parameters remain unexplained, and the expected return payload is not described. An agent could make basic calls but would be guessing about filtering, pagination, and response format.

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 the parameters. It only clarifies cliente_id and cliente_ids; the remaining nine parameters (page, order, expand, fields, filter, params, account, page_size, sql_filter) are left completely undocumented. This leaves a large risk of the agent misusing the generic query 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 opens with a specific verb-resource pair, 'Consulta o limite de crédito dos clientes', which clearly identifies what the tool returns. It goes on to distinguish the single-client path (cliente_id) from the batch path (cliente_ids), so an agent can tell its core behavior. It does not explicitly name a sibling for disambiguation, but the credit-limit resource is distinct enough among the protheus_* family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage direction: use cliente_id for one client and cliente_ids for batched execution. This is clear context for selecting the right invocation mode. It does not state when not to use the tool or mention alternatives, but for a read-only query tool the provided guidance is reasonably actionable.

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 non-destructive behavior, and the description's 'Lista' aligns with them. The description adds useful context by scoping the results to installations connected to 'this install' and by specifying the output fields (id e label).

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 redundant phrases. Every word contributes to explaining the tool's purpose and output.

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 is minimally viable: it explains the main action, scope, and output. However, the undocumented 'account' parameter and the absence of any usage guidance leave gaps that prevent a fully confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional parameter, 'account', with no description, and schema description coverage is 0%. The description never mentions this parameter, so an agent cannot determine whether it filters installations, identifies a connection, or serves another 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 a specific verb ('Lista') and resource ('instalações Protheus conectadas a este install'), and even states the returned fields (id e label). This clearly distinguishes it from the domain-specific 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?

There is no guidance on when to use this tool versus alternatives, and no mention of how the optional 'account' parameter should affect usage. Sibling tools are not referenced, so an agent must infer usage largely from the tool name.

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 cover readOnly, idempotent, and non-destructive behavior. The description adds that the tool indicates what is active, which is a useful behavioral insight beyond annotations. No contradiction found.

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

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

Two concise sentences that front-load the main purpose and add a key behavioral detail. No wasted words; structure is 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?

Despite being a read-only list tool, it has 9 optional parameters and no output schema. The description does not cover pagination, filtering semantics, response format, or any parameter usage, leaving a significant gap for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description provides no information about any of the 9 parameters (page, filter, expand, fields, sql_filter, etc.). The agent has no guidance on how to use these generic-looking parameters for this specific 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?

The description clearly states the action (lista/lists) and the resource (módulos do sistema Protheus) and adds a diagnostic purpose (helps explain why an API responds or not). It distinguishes the tool's role from other modules but does not explicitly differentiate from sibling diagnostic tools like protheus_diagnostico.

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 understanding active modules and diagnosing API behavior, but it does not state explicit when-to-use/when-not-to-use conditions or name alternative tools. The context is clear enough to infer but lacks direct guidance.

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 readOnly, idempotent, and non-destructive behavior. The description adds useful context around entrada/saída and canceled notes, but does not disclose return shape, pagination, or filtering behavior.

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 filler. It communicates the operation and key scope 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 11 parameters, no output schema, and no parameter descriptions, this one-sentence description is not enough for an agent to invoke the tool correctly. It lacks parameter semantics, filter behavior, and response expectations.

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 and 11 parameters, the description needed to compensate. It only echoes the entrada/saída distinction, which maps loosely to the 'tipo' enum, and leaves all other parameters like filter, expand, fields, canceladas, and page_size unexplained.

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

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

The description clearly identifies a specific verb ('Consulta') and resource ('totais de notas fiscais'), and adds scope: saída/entrada, varejo, and canceled notes. It is distinctive enough even though it does not explicitly compare itself to 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?

There is no guidance on when to use this tool instead of alternatives, no exclusions, and no usage context. The agent must infer the intended use from the name and sibling list.

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 readOnly, idempotent, and non-destructive behavior, so the description only needs to add extra behavioral context. It adds 'Bulk support: accepts ids for batched execution', which is genuinely useful. However, it does not disclose pagination, response format, or how filters behave.

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 short and front-loaded, with the main purpose in the first sentence and the bulk behavior in the second. It uses no filler words, though it could add a bit more useful detail without becoming bloated.

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

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

Despite having 11 parameters, no output schema, and no per-parameter documentation, the description only covers listing and id-based lookup plus bulk support. Missing details around filtering, expansion, ordering, and response shape make the tool incomplete for confident invocation.

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 for 11 undocumented parameters. It only clarifies 'id' and 'ids', leaving parameters like 'expand', 'fields', 'filter', 'params', 'sql_filter', 'page_size', and 'account' without any semantic explanation.

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 states a specific action and resource: listing CRM commercial opportunities or querying one by internal id. This clearly distinguishes it from the sibling protheus_* tools, which target different resources like products, orders, or proposals.

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 two usage modes (list all opportunities or fetch one by id) but gives no guidance on when to prefer this tool over related siblings such as protheus_propostas_comerciais, nor any exclusions or alternative conditions. Usage context is largely left to inference.

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, and the description's 'Consulta' is consistent with those. The description adds some behavioral value with 'Bulk support: accepts branch_ids for batched execution', but it does not disclose output shape, pagination behavior, or API limits, so its additional transparency is modest.

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 compact at three sentences, front-loads the primary purpose, and each sentence adds distinct information: core purpose, parameter/filter semantics, and bulk behavior. The unannounced switch between Portuguese and English and the unformatted filter list are minor structural blemishes.

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 has 12 parameters, no parameter descriptions in the schema, and no output schema, so the description should cover return format, pagination, and top-level filter/query syntax. It explains only a subset of parameters and says nothing about the response shape or how page, filter, and sql_filter behave, leaving an agent materially under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for missing parameter documentation. It does name key filters such as branchId, product, warehouse, deliveryDate, startDate, plus branch_id, codigo, and branch_ids. However, it leaves page, order, expand, fields, filter, account, page_size, and sql_filter unexplained, so compensation is partial.

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

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

The description opens with 'Consulta as ordens de produção do MRP', stating a specific verb and resource, and clarifies that it can fetch a single order using branch_id and codigo. It clearly identifies the tool as a read-only MRP production-order query, though it does not explicitly contrast it with 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?

The description gives useful context: filters can be passed in params, a specific order is retrieved with branch_id and codigo, and branch_ids enables batched execution. It lacks explicit alternatives, exclusions, or when-not-to-use guidance, but the provided usage modes are clear.

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?

The annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which match the 'Consulta' description; there is no contradiction. The description adds no extra behavioral detail such as pagination behavior, response shape, or data scoping, but the annotation safety profile covers the most important side-effect expectations.

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

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

The description is a single short sentence that wastes no words and front-loads the verb and resource. It is concise and easily scanned, though the brevity does mean less semantic support for the many parameters.

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

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

Despite helpful annotations, the tool has nine undocumented parameters, no output schema, and a large sibling set, so a single sentence leaves too much for the agent to infer. The description does not explain how filters, fields, params, or pagination interact, what the response contains, or what constraints apply. This is not complete enough for reliable invocation.

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 nine parameters and schema_description_coverage is 0%, yet the description does not explain any of them. Generic names like page, filter, fields, expand, params, account, page_size, and sql_filter may hint at REST-style usage, but the description provides no semantic compensation for the missing schema 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 states a clear verb ('Consulta') and resource ('os parâmetros de sistema do Protheus'), so an agent can identify what the tool does. It does not explicitly differentiate it from the many sibling Protheus tools, but the resource scope is specific enough to avoid confusion.

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 guidance on when to use this tool versus the many protheus_* siblings, and no mention of prerequisites or typical use cases. The description simply states the action without explaining when it is the right choice or when another tool should be selected.

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 establish readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context: returning line items when `id` is provided and supporting batched execution through `ids`. The description does not contradict the annotations, but it omits details like pagination limits, default list behavior, and response shape.

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 and front-loaded: the core listing behavior comes first, then the `id` special case, then bulk support. Every sentence earns its place and there is no redundant 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 tool with 11 parameters, no output schema, and zero schema-level parameter descriptions, this definition is incomplete. It gives no indication of response format, pagination semantics, filter syntax, or how this tool differs from closely related siblings, so an agent would need substantial external information to invoke it reliably.

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 for 11 undocumented parameters. It only explains `id` and `ids`, leaving `page`, `order`, `expand`, `fields`, `filter`, `params`, `account`, `page_size`, and `sql_filter` without any semantics. This is a significant gap for callers.

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 a specific resource ('pedidos de venda do varejo') and an action ('Lista'), and further distinguishes behavior by stating that passing `id` returns the items of that order. However, it does not differentiate this tool from the similarly named sibling `protheus_vendas_varejo`, so an agent may struggle to choose between them based solely on the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful internal usage guidance: `id` fetches order items and `ids` enables batch execution. It does not, however, explain when to choose this tool over siblings like `protheus_vendas_varejo` or `protheus_notas_totais`, so the when/why selection context is only implied rather than explicit.

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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond those annotations: product data is partitioned by module, and varejo and mrp are distinct registries rather than two views of the same data. This is a meaningful semantic warning that helps the agent interpret results correctly.

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 short, front-loaded with the core purpose, and each sentence adds necessary clarification about module partitioning and source selection. There is no filler or redundant restatement of the tool name.

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 10-parameter read query with no output schema and no parameter descriptions, the description is too thin: it omits filtering, pagination, account handling, return shape, and any prerequisites. The critical varejo/mrp distinction is covered, but most invocation options remain cryptic.

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 across 10 parameters, the description carries the burden of explaining parameters, but it only explains fonte and its allowed values. Parameters such as filter, sql_filter, expand, fields, params, account, and page_size remain undocumented, so an agent must guess at their 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 operation ('Consulta') and resource ('cadastro de produtos'), and explicitly defines the two module-specific sources (varejo/mrp). However, it does not explicitly distinguish this tool from sibling tools like protheus_catalogo or protheus_estoque, so the scope is clear but the sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance to choose a fonte because Protheus exposes products per module, and it warns that varejo and mrp are separate registries. It does not, however, explain when to prefer this tool over other product-related sibling tools, so the guidance is useful but incomplete.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the domain rule that a proposal lives inside an opportunity, making `oportunidade_id` mandatory, and the availability of batched execution via `oportunidade_ids` and `ids`. 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 short and front-loaded: the first sentence states the purpose and key constraint, and the second covers bulk support. Every sentence earns its place, 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?

The description covers the core purpose, the required parent ID, and batching, but does not explain how to request a specific proposal (e.g., using the `id` parameter), pagination defaults, output format, or how expand/filter behave. With no output schema, some return-value guidance would be expected. Adequate for a simple tool but with clear gaps for a 13-parameter API.

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 does explain the most critical parameter (`oportunidade_id`) and identifies `oportunidade_ids` and `ids` as bulk parameters. However, the remaining ten parameters (page, order, expand, fields, filter, params, account, page_size, sql_filter, id) receive no explanation, leaving significant semantic gaps for an agent trying to invoke the tool correctly.

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 action and resource: 'Lista as propostas comerciais de uma oportunidade, ou consulta uma proposta específica.' It also provides important scoping context by noting that a proposal lives within an opportunity and that `oportunidade_id` is required. This differentiates it from the many sibling protheus_* tools, none of which target commercial proposals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: use this tool to list proposals for an opportunity or to query one specific proposal. It does not explicitly mention alternatives or when-not-to-use, but among the siblings there is no competing tool for this resource, so the guidance is sufficient. The bulk support line further clarifies when multiple IDs can be passed.

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 no need to restate safety. The description adds valuable behavioral detail by describing the output granularity (headers, full table, items+prices) for each argument combination, which goes beyond the annotations.

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

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

Two concise sentences, purpose-led, with no superfluous content. The three usage modes are packed efficiently and are immediately understandable.

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

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

Given no output schema and a complex 11-parameter input, the description is incomplete. It covers the primary modes but omits any information about return format, error cases, or the purpose of the many generic parameters (e.g., page, filter, sql_filter). An agent would struggle to use the full capability of the tool based on this description alone.

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 the semantics of only two parameters (codigo and itens) out of 11; the other nine (page, order, filter, fields, expand, params, account, page_size, sql_filter) remain undocumented in both schema and description, leaving the agent without guidance on pagination, filtering, or selection.

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 resource (price tables) and the verb (consulta/query), and explicitly distinguishes three usage modes based on arguments (no args, with codigo, with codigo+itens), which differentiates it from the many protheus_* sibling tools that target other resources.

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?

It clearly states when to use the tool — to query price tables — and explains the argument-driven variations, which serves as usage guidance. It does not name alternative tools or explicitly say when not to use it, but the context is unambiguous given the resource-specific naming of 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?

Annotations already cover read-only, idempotent, and non-destructive safety. The description adds the bulk execution behavior via 'ids' and the list-or-single query distinction, which is useful beyond the annotations.

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

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

Two concise sentences, front-loaded with the core function and a separate line for bulk support. 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?

With 11 parameters and no output schema, the description is insufficient. It does not mention common query options (page, order, filters, expand, fields) nor response shape, leaving agents to guess or rely on patterns from other tools.

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% for 11 parameters. The description only clarifies 'id' and 'ids' (internal id and bulk), leaving pagination, filtering, ordering, expansion, field selection, and account parameters undocumented. It fails to compensate for the schema 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 operation: it lists registered carriers or queries one by internal id. This is a specific verb-resource pair and distinguishes the tool from siblings like protheus_clientes_fornecedores by naming the resource 'transportadoras' explicitly.

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 carrier lookups via the tool name, but it does not mention when to prefer this tool over alternatives or any exclusions. It only hints at bulk support, not a decision criterion.

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 cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description does not need to restate that. It adds some extra context by noting bulk execution support, but does not disclose other behavioral aspects like pagination or response behavior.

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 short, front-loaded, and contains no filler. It states the primary function first, the by-id variant second, and bulk support last, with every sentence earning 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?

Despite annotations covering the read-only/idempotent profile, the tool has 11 parameters and no output schema, yet the description only explains id/ids. Key operational details about filtering, pagination, expansion, account selection, and SQL filters are missing, making the description incomplete for complex calls.

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 only gives minimal meaning for 'id' and 'ids', while page, order, expand, fields, filter, params, account, page_size, and sql_filter are left completely undocumented.

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 states a specific action ('Lista os usuários do Protheus') and a secondary operation ('consulta um usuário por id'), clearly identifying both the verb and the resource. It distinguishes this tool from the many protheus_* siblings by naming the 'usuarios' resource explicitly.

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 offers clear context: use it to list users or fetch one by id, with additional bulk guidance via the ids parameter. It does not explicitly mention alternatives or when-not-to-use conditions, but the usage context is sufficiently clear.

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 need to restate read-only behavior. It adds bulk support and module requirement, which are useful beyond annotations. However, it does not describe pagination, error behavior, or return format, leaving some gaps. The additional context justifies a 3.

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—three short sentences—with no fluff. Each sentence earns its place: purpose, prerequisite, and bulk support are all stated efficiently. The structure is front-loaded and clear.

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 has 11 parameters, no output schema, and no parameter descriptions. The description only covers a fraction of them and does not explain return values, pagination, filtering, or how to combine parameters. This is incomplete for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains only 'id' and 'ids' (for bulk) but leaves 9 other parameters (page, order, expand, fields, filter, params, account, page_size, sql_filter) entirely undocumented. This is insufficient given the 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 the tool queries retail sales ("Consulta as vendas do varejo") or a single sale by internal id, which is specific and clear. However, it does not explicitly differentiate from sibling tools like protheus_pedidos_varejo, so it lacks the sibling differentiation that would warrant a 5.

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 guidance on when to use this tool versus alternatives. The only contextual note is a prerequisite ("Exige o módulo de varejo publicado nesta instalação"), which is not usage guidance. No exclusions or alternative routing are provided.

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?

The annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is additive. It adds useful behavioral context by stating the tool supports both single-code lookups and batched execution via ids. There is no contradiction with 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 two concise sentences with the primary action front-loaded and the bulk behavior clearly separated. There is no filler, redundancy, or unnecessary detail.

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

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

Even with strong read-only and idempotency annotations, the tool has 11 parameters, a nested params object, no output schema, and no parameter-level documentation. The description is too thin for an agent to understand filtering, pagination, expansion, or sql_filter behavior for non-trivial calls.

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%, leaving the description to compensate for 11 undocumented parameters. It only hints that 'id' is a seller code and 'ids' enables bulk execution; the remaining parameters such as page, order, expand, filter, params, account, page_size, and sql_filter are left unexplained.

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

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

The description clearly states the tool 'Lista os vendedores cadastrados' (lists registered sellers) or queries one by code, providing a specific verb and resource. It focuses on 'vendedores', which distinguishes it from sibling tools like protheus_usuarios, though it does not explicitly name those alternatives.

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 guidance on when to use this tool versus sibling Protheus tools. The bulk support note describes a capability rather than a contextual recommendation, and no exclusions or alternatives are mentioned.

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

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

Annotations indicate readOnlyHint=false (mutation), idempotentHint=true (safe to repeat), and destructiveHint=false. The description adds the instruction to 'Include the conversation array with recent messages for reproduction,' which gives practical context. However, it doesn't disclose what happens after reporting (e.g., ticket creation) or any side effects beyond the annotations. The description neither contradicts annotations nor adds significant behavioral depth.

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

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

The description is two sentences, front-loaded with the purpose and followed by the key reproduction instruction. Every sentence earns its place with no fluff. It is perfectly concise for a simple reporting tool.

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, the description is functional but incomplete. It lacks explicit guidance on the required 'message' parameter, which is crucial for the agent to formulate a valid call. With no output schema and no parameter descriptions, the description should clarify what to put in 'message' and 'context.' While the tool's purpose is straightforward, the missing parameter semantics reduce completeness.

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 all parameters. It explicitly mentions the 'conversation array,' which maps to the 'conversation' parameter, but it does not explain the required 'message' parameter or the optional 'context' parameter. An agent might infer that 'message' contains the bug description, but that's not stated. This is a significant gap given 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 states a clear purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb and resource, distinguishing it from the data-retrieval siblings (e.g., protheus_* tools). However, it doesn't explicitly name alternatives or differentiate itself further, so it doesn't earn a 5.

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?

Usage is implied: use this when you encounter a bug, missing feature, or want to give feedback. There's no explicit 'when to use' or 'when not to use' guidance, and no mention of alternative tools for similar actions. Given the sibling set is mostly data access, the intent is clear but not spelled out.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no further behavioral context—it does not mention output format, prerequisites, or any side effects. Since the tool is a simple read-only version check, the annotations suffice, but the description does not go beyond them. This meets the baseline but adds no extra disclosure.

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 says exactly what the tool does with no filler. It is front-loaded with the action and the specific resource. Every word earns its place, and there is no redundancy or extra explanation needed for such a straightforward utility.

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

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

For a tool with no parameters, no output schema, and a clear, minimal purpose, the description is fully complete. An agent can invoke it without any additional context or caveats. The simplicity of the tool means nothing is missing—no prerequisites, permissions, or return-value expectations are needed. The description fully satisfies the agent's informational needs.

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 schema already documents everything (trivially 100% coverage). The description does not need to add parameter explanations. Per the rubric, the baseline for 0 parameters is 4, and the description appropriately remains silent on parameters since there are none.

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

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

The description clearly specifies the verb 'Show' and the resource 'current MCP platform and adapter versions'. It is unambiguous and distinct from all sibling tools, as none of them appear to provide version information. The sentence is specific and leaves no doubt about the tool's function.

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?

While there is no explicit 'when to use vs alternatives' statement, the purpose is inherently obvious: use it when you need to know the platform/adapter versions. The context is clear, and there are no competing sibling tools that offer a similar capability, so no exclusions are needed. The description implicitly guides usage through its unambiguous purpose.

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, covering the safety profile of the operation. The description adds detail about what state is returned, which is useful but does not go beyond what annotations already establish regarding behavior.

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 purpose and packs the key return elements into a concise list. No unnecessary words or repeated 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 zero-parameter read-only introspection tool, this description is complete. It tells the agent exactly what information will be returned—installed MCPs, connection status, accounts, and catalog tool counts—so the agent can decide whether to call it and how to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the input schema is fully documented, so there are no parameter semantics to explain. The description appropriately focuses on the output contents instead, which is the only semantically relevant information for an agent.

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 names a specific verb ('Returns') and a clear resource ('current toolkit state'), then enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from sibling tools focused on specific Protheus entities or connection actions like authenticate and connect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when this tool is useful: whenever an agent needs a snapshot of the toolkit's installation and connection state. It does not explicitly name alternatives or exclusions, but the informational nature of the listed outputs makes the intended usage evident.

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