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

No annotations are provided, so the description carries the full burden. It discloses that a movement record is created, which is useful, but says nothing about whether stock can go negative, whether the adjustment is reversible, what permissions are needed, or what the operation returns.

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

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

A single tight sentence with the core action front-loaded. It wastes nothing, though it also delivers little beyond the minimum.

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 schema is fully self-documenting, so the agent can call it, but for an unannotated mutation tool with no output schema the description should explain the resulting state (new stock level?), negative-stock handling, and threshold alert behavior. Those gaps leave it merely adequate.

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

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

Schema description coverage is 100%, so all four parameters (including quantityDelta sign semantics and lowStockThreshold default) are already documented. The description's 'entrada/saída' restates the schema's sign convention rather than adding new meaning, so baseline 3 applies.

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 specific verb (ajusta) and resource (estoque de um produto) plus the side effect of logging a movement (entrada/saída). This clearly differs from destructive siblings like delete_product, though it doesn't explicitly contrast with novacrm_update_product, which could also plausibly touch stock.

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 instead of novacrm_update_product or novacrm_inventory_alerts, no prerequisites, and no exclusions. The agent must infer the usage context from the name alone.

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?

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: not whether cancellation is reversible, whether stock/refunds are affected, or what permissions are needed. It also says the reason is provided ('informando o motivo') while the schema marks 'reason' as optional, which blurs the requirement rather than clarifying it.

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

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

A single short sentence with no filler and the action front-loaded. Its brevity is efficient, though it borders on under-specification.

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 destructive mutation tool with no annotations and no output schema, the description should explain effects, irreversibility, and side effects such as stock or payment handling. None of that is present, leaving the agent insufficiently equipped to call it safely.

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 100% ('ID do pedido', 'Motivo do cancelamento'), so the schema already documents both parameters. The description only restates the reason parameter and adds no format, length, or constraint detail.

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 specific verb ('Cancela') and resource ('um pedido'), so the operation is unambiguous. However, it offers no differentiation from siblings such as novacrm_update_order_status, which could plausibly also result in a cancelled order.

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 when-to-use, when-not-to-use, or alternative guidance. The agent is left to guess why it should cancel outright rather than change status via novacrm_update_order_status, or what prerequisites exist.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one side effect (completion date is recorded) but says nothing about idempotency on an already-completed task, permissions, reversibility, or failure modes for an invalid id.

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

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

A single front-loaded sentence with zero waste; the action and its effect are stated immediately.

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-parameter state-transition tool with a fully documented schema, the description is adequate but thin: it omits idempotency, error behavior, and the alternative of update_task, which an agent would want when choosing between the two.

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

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

Only one parameter exists and the schema documents it fully at 100% coverage, so the baseline is 4. The description adds no extra meaning about the id, but nothing is missing either.

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 specific verb and resource ('Marca uma tarefa como concluída') plus a side effect ('registra a data de conclusão'). It is distinguishable from generic task tools, though it doesn't explicitly contrast with the sibling novacrm_update_task, which could also set status.

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 versus novacrm_update_task, no mention of prerequisites (task must exist, must not already be completed), and no exclusions. Usage is only implied by the name and the single sentence.

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?

No annotations exist, so the description carries the full burden, and it omits material behavior: a rule with isActive defaulting to true can immediately fire actions such as send_telegram or create_task, which are real external side effects. It says nothing about permissions, whether the rule activates immediately, or idempotency — significant gaps for a mutation tool with zero 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?

A single sentence that front-loads the verb and resource, then explains the mechanism with two parenthetical examples. Nothing is wasted and nothing important is buried.

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?

Six parameters, a nested object, two enums, and no annotations or output schema mean the description should do more; it explains the concept well but leaves activation defaults, side effects, and required actionConfig shape incompletely addressed for a 6-param tool.

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

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

Schema coverage is 100%, so the enum values and the nested actionConfig fields (taskTitle, taskType, delayDays) are already documented. The description adds a mild illustration by pairing a trigger example with an action example, but it does not explain the required coupling between trigger, actionType, and actionConfig beyond what the schema states.

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 specific verb+resource ('Cria uma regra de automação') and explains the trigger→action model with concrete examples, which makes the tool's role unmistakable. It does not explicitly contrast itself with novacrm_update_automation or novacrm_list_automation, but the 'create' verb plus sibling naming pattern makes the distinction inferable.

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 through the worked example (trigger order_paid → create_task), so an agent can infer how to invoke it. However, there is no guidance on when to choose this over novacrm_update_automation or when creating a rule is appropriate versus a one-off task/webhook, and no prerequisites are mentioned.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about what happens on duplicate names or e-mails, whether creation triggers automations/webhooks in the store, permission requirements, or what the response contains. Only the bare fact of creating a client record is conveyed.

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

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

One front-loaded sentence with zero waste, but it is terse to the point that nothing beyond the core verb phrase is communicated. Efficient structure, minimal content.

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 an 8-parameter mutation tool with a nested address object, no output schema, and no annotations, the description is far too thin. It never explains accepted values for 'status' or 'clientType', the shape of 'address', or what the created client identifier looks like in the response.

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 100%, so every one of the 8 parameters already has an inline description. The single sentence adds no meaning beyond the schema, which is exactly the baseline-3 case when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Cadastra um novo cliente'), making the create-client action unambiguous. It does not distinguish itself from siblings like novacrm_create_product or novacrm_create_opportunity, relying on the tool name for that separation.

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 novacrm_import_clients (bulk creation), novacrm_update_client, or novacrm_create_opportunity for a client that is also a sales lead. The agent must infer the choice entirely 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?

No annotations are provided, so the description carries the full disclosure burden, yet it only says a coupon is created. It does not mention uniqueness constraints on the code, whether the coupon is instantly active, what happens on duplicate codes, or what the call returns. For a mutation tool with zero annotation coverage this is a significant gap.

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?

It is a single short sentence with no wasted words, but it is essentially a restatement of the tool name and offers no other information. Appropriately brief, yet under-specified rather than efficiently informative.

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 annotations and no output schema, the description should supply more context: the uniqueness rule for coupon codes, whether the coupon is store-scoped, and what the creation returns (e.g., id, code, status). It leaves an agent able to call the tool but not to predict its outcome.

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 100%, with each of the four parameters (code, type, value, minPurchase) documented in the schema, including an enum explanation for type. The description adds no semantics beyond the schema, so the baseline 3 applies.

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 gives a clear verb ("Cria") plus a specific resource ("cupom de desconto"), so the agent immediately knows this tool creates a discount coupon. It does not distinguish itself from siblings like novacrm_list_coupons or novacrm_validate_coupon, but the create action is unambiguous.

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

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

There is no indication of when to use this tool instead of alternatives, no prerequisites (e.g., does the coupon code need to be unique?), and no mention of the sibling validate/list tools. The agent must infer all 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say what happens if clientName doesn't match an existing client, whether duplicates are rejected, what permissions are needed, or what is returned on success — significant gaps for a mutation tool with 9 parameters.

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

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

A single efficient sentence with the core action front-loaded and no wasted text. It is terse rather than padded, though the terseness is a factor in the transparency gaps.

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 9 parameters, no annotations, and no output schema, the description should explain creation semantics, required-field implications, and the client linkage behavior. A one-line summary leaves the agent without enough context to call this correctly in edge 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 89%, so the schema already documents nearly every parameter including enums with defaults. The description adds no parameter-level meaning beyond the schema, which is acceptable at high coverage but earns only the baseline.

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+resource — 'Cria uma oportunidade (negócio)... no pipeline de vendas' — so the agent knows it creates a sales opportunity. It does not distinguish itself from siblings like novacrm_create_proposal or novacrm_create_order, which also create pipeline-adjacent objects.

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 indication of when to use this versus novacrm_update_opportunity, novacrm_create_proposal, or novacrm_create_client, and no prerequisites or preconditions are stated. The agent must infer usage purely from the 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?

With no annotations, the description carries the full disclosure burden and discloses almost nothing: it does not say whether stock is decremented, whether status defaults to 'new', whether an unknown customer name creates a client record, or whether the operation is reversible. For a multi-field mutation with nested items, this is a substantial gap.

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

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

A single short sentence is front-loaded and free of padding, but here brevity comes at the cost of under-specification rather than efficient information density. There is no waste, but also very little content.

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 five parameters including a nested items array, no annotations, and no output schema, yet the description never explains what is returned (e.g., an order ID) or how required fields like customerName and items are validated. Given the complexity, the definition is not complete enough to call confidently.

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 100% and every property (including nested item fields and the status enum) is documented in the schema, so the baseline of 3 applies. The description itself adds no parameter meaning at all beyond what the schema already states.

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?

"Registra um novo pedido para a loja" identifies the verb (register/create) and resource (order), but it is essentially a translation of the tool name with no added scope, field detail, or distinction from siblings such as novacrm_update_order_status or novacrm_cancel_order. An agent can guess the purpose, but the description does not sharpen it.

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 update_order_status, cancel_order, or the list/get order tools, and no mention of prerequisites such as whether the customer must already exist or whether the product catalog must be consulted. Usage is only implied by the verb.

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?

No annotations are provided, so the description carries the full burden of disclosure. It says nothing about whether duplicates are rejected, whether price/stock validation applies, what permissions are needed, or what the call returns on success or failure.

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

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

A single tight sentence that front-loads the action and resource with zero filler. It is appropriately sized, though being so short it leaves little room for the missing behavioral 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?

For a 6-parameter mutation tool with no annotations and no output schema, the description is too thin. An agent gets no information about create-time side effects, duplicate handling, or what a successful response looks like.

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 100%, with each of the six parameters documented inline including default stock value and price currency. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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 specific verb+resource: creates a new product in the store catalog. An agent can distinguish it from update_product or list_products by the word 'novo'. It does not explicitly name the sibling alternatives, so it stops short of 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?

No guidance on when to use this versus novacrm_update_product, novacrm_create_product vs bulk import, or what preconditions exist. The only usage signal is the implied 'new product' framing.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that subtotal and total are calculated automatically from items when omitted, but it omits permission requirements, side effects, whether creation is irreversible, duplicate handling, and what the response contains.

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, and the core action is front-loaded. Every sentence contributes: one establishes creation, the other discloses automatic total calculation.

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 an 11-parameter mutation tool with no annotations and no output schema, the description is too thin. Even though parameter descriptions are fully covered by the schema, the description does not explain return behavior, permissions, or side effects of creating a proposal.

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 100%, so the schema already documents all 11 parameters, making 3 the baseline. The description adds some value by explaining item-driven automatic totals, but that behavior references subtotal/total fields not present in the schema, so the added semantics are limited.

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 and resource: 'Cria uma proposta comercial' (creates a commercial proposal). It is clear enough to distinguish from list/get/update/delete proposal siblings, but it does not explicitly name or differentiate 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?

The description only states what the tool does, not when to use it versus novacrm_update_proposal or novacrm_create_order. No prerequisites, 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only states that a task is created. It says nothing about whether clientId must reference an existing client, how clientId/clientName/clientPhone interact, whether duplicate tasks are allowed, what permissions are needed, or what a successful call returns.

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

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

A single front-loaded sentence with zero padding, but it is arguably under-specified rather than truly tight, since the brevity leaves real gaps for a 9-parameter creation 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 9-parameter mutation tool with no annotations and no output schema, the description is too thin. It never addresses client linkage semantics, the optional dueTime, priority defaults, or the result of the call, leaving the agent to reconstruct behavior from the schema 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 100%, so the baseline is 3. The description adds only marginal meaning, since the listed task types loosely mirror the `type` enum and "agenda comercial" hints that dueDate/dueTime are scheduling fields, but it does not clarify the three alternate client-identification parameters or the priority default.

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 ("Cria") plus a specific resource ("tarefa na agenda comercial") and lists example task types (follow-up, ligação, reunião, e-mail). This clearly distinguishes it from list_tasks, get_task, update_task, delete_task, and complete_task, though the distinction comes from the verb alone rather than explicit naming of 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?

There is no guidance on when to create a task versus using novacrm_complete_task or novacrm_update_task, no prerequisites, and no exclusions. The agent must infer usage entirely from the verb.

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?

No annotations exist, so the description carries the full burden. It does add genuinely useful behavioral detail: the signing secret is returned only once in the response, which is operationally important. But it omits what the response otherwise contains, whether creation is idempotent for duplicate URLs, and any permission requirements.

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 short sentences, zero waste, with the core purpose front-loaded and the one-time-secret caveat appended where it is easy to catch.

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 mutation tool with no annotations and no output schema, the description covers the essentials (what it creates, the HTTPS requirement, the one-time secret) but leaves the returned payload structure and failure conditions undisclosed, so an agent still lacks a complete picture before calling it.

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

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

Schema coverage is 100%, so url, name, and events are already documented, including the '*' wildcard for all events. The description only reinforces the HTTPS constraint on url and adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('Cria um webhook') plus the constraint that the receiving URL must be HTTPS. An agent can immediately tell this is the creation tool for webhooks, distinct from novacrm_list_webhooks, even though the sibling is not named.

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 only implied by the verb 'create' — there is no explicit statement of when to use this versus novacrm_list_webhooks, no prerequisites, and no guidance on prerequisites such as an existing store or required authorization. The HTTPS requirement is a constraint, not usage 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?

No annotations are provided, so the description carries the full burden. It does disclose the most important trait — the deletion is permanent — which is genuine added value. However, it says nothing about permissions required, whether dependent tasks/history are affected, or how to recover from a mistaken deletion.

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

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

A single short sentence with the critical qualifier ('permanentemente') placed immediately, so it is front-loaded and waste-free. It is arguably too terse rather than too long.

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-parameter destructive tool with no annotations and no output schema, the description covers purpose and irreversibility but omits side effects and safety context an agent would want before deleting an automation. Adequate, not complete.

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

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

Schema coverage is 100% with a single well-described 'id' parameter, so the schema already does the work. The description contributes no additional meaning about the identifier or its format, which is acceptable at full coverage but adds nothing.

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 specific verb ('Exclui') and resource ('regra de automação'), so the agent knows exactly what the tool acts on. It does not explicitly differentiate itself from novacrm_update_automation or novacrm_get_automation, but the delete verb makes the distinction obvious enough.

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

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

No guidance on when to use this versus novacrm_update_automation or novacrm_list_automations, and no prerequisite or confirmation guidance. The word 'permanentemente' hints that this is irreversible, but no alternatives or exclusions are stated.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the single most important trait — that deletion is permanent/irreversible — but says nothing about required permissions, whether related records (tasks, proposals) are cascaded, or what happens when the id does not exist.

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

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

A single short sentence with the destructive qualifier placed where it will be read first; nothing is wasted. It is arguably too terse for a destructive operation, but there is no filler or redundancy.

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

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

For a one-parameter destructive tool with no annotations and no output schema, the description covers the core action and its irreversibility but leaves gaps around confirmation expectations, cascade effects and failure behavior. It is minimally adequate rather than complete.

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

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

Only one parameter, and the schema already documents it at 100% coverage ("ID da oportunidade"). The description adds no format hints, no indication of whether a human-readable or internal ID is expected, and no error semantics for an invalid id.

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 names a specific verb ("Exclui permanentemente") and resource ("uma oportunidade do pipeline"), so an agent can distinguish it from novacrm_delete_task, novacrm_delete_proposal and the non-destructive opportunity tools. It is clear but does not explicitly contrast itself with the sibling delete 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 statement of when to use this instead of novacrm_update_opportunity or novacrm_move_opportunity, no prerequisites, and no warning about when not to call it. The only usage signal is the adverb "permanentemente", which implies caution but is not framed as 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?

With no annotations, the description carries the full burden and does well: it discloses that the default path is reversible, that permanent=true is irreversible, and that the hard-delete path requires the 'dangerous:delete' scope. It omits whether confirmation is needed and what happens to dependent records (orders, stock history).

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 short sentences, zero padding, and the safety-critical distinction (reversible by default vs irreversible with a privileged scope) is front-loaded in the second clause.

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 2-parameter destructive tool with no annotations and no output schema, the description covers the essential facts: default behavior, irreversibility, and permission requirement. A line about the response (e.g. whether the deleted/archived product is returned) would close the remaining 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 coverage is 100%, so both parameters (id, permanent) are already documented including the default. The description reinforces the permanent flag's meaning but adds no new parameter-level detail such as ID format or behavior when id is unknown — baseline 3 applies.

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 specific verb and resource ('Remove a product from the catalog'), which is unambiguous and clearly distinct from novacrm_create_product / novacrm_update_product. It does not explicitly name a sibling alternative (e.g. archiving via update_product), so it stops just short of the top mark.

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?

Explains the two operating modes and which parameter selects each: default = archive (reversible), permanent=true = definitive deletion. This is exactly the decision the agent needs. It does not say when archiving is preferable to updating the product or what to do if the product is referenced by orders.

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

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

With no annotations, the description carries the full behavioral burden, and it only discloses that the deletion is permanent. It says nothing about required permissions, whether related records (opportunities, orders) are affected, error behavior for invalid IDs, or what the call returns.

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

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

One short sentence with zero filler; the irreversible nature is folded in rather than buried. The terseness is efficient, though it borders on under-specification rather than verbosity.

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

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

For a destructive single-parameter tool with no annotations and no output schema, the description should indicate what a successful deletion returns and any side effects or safeguards. Neither is present, so an agent cannot predict the outcome of a call.

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

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

Schema coverage is 100% and the single 'id' parameter is documented in the schema as 'ID da proposta'. The description adds no format, source, or validation semantics beyond that, so the baseline 3 applies.

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 specific verb+resource pair ('Exclui ... uma proposta') and adds the qualifier 'permanentemente', so the agent knows exactly which entity is being removed. It doesn't explicitly distinguish itself from sibling mutations like update_proposal or delete_task, but the naming and scope are unambiguous.

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

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

There is no guidance on when to delete a proposal versus updating it, or any prerequisite such as ownership/state checks before deletion. The only cue is the tool name itself, leaving the agent to infer usage conditions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the one trait that matters most for a delete tool — that removal is permanent and irreversible — but says nothing about required permissions, whether related data (e.g., subtasks) is affected, or what happens when the ID does not exist.

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

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

A single short sentence with zero filler, front-loading the destructive verb. It is appropriately sized, though at this brevity the terseness borders on under-specification rather than disciplined economy.

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 destructive single-parameter tool with no annotations and no output schema, the description covers the essential fact (permanent deletion) but omits consequences, error behavior, and confirmation requirements. It is minimally sufficient to avoid misuse but leaves real gaps for an irreversible operation.

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 100% and the single parameter 'id' is documented in the schema as 'ID da tarefa', so the schema does the heavy lifting. The description adds no additional meaning about identifier format or source (e.g., from novacrm_list_tasks), which is the baseline-3 outcome for full-coverage schemas.

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 ('Exclui') and resource ('uma tarefa') and adds the qualifier 'permanentemente', which meaningfully distinguishes it from novacrm_complete_task and novacrm_update_task. It does not, however, explicitly name those siblings or contrast with novacrm_delete_automation, so differentiation is implied rather than stated.

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 novacrm_complete_task, novacrm_update_task, or any other close alternative, and no stated prerequisites. The only hint is the word 'permanentemente', which implies 'use with caution' but leaves the agent to infer the decision boundary entirely.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the shape of the result (condition, action, execution statistics) and, via "Obtém", implies a read-only operation, but it says nothing about permission requirements or what happens when the ID does not exist.

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

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

A single front-loaded sentence with the verb, resource, key, and returned fields in that order. Nothing is redundant and nothing obvious is padded in.

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-parameter read tool with no output schema, the description covers identification and return contents, which is nearly everything an agent needs to call it correctly. Only edge-case behavior (not-found, permissions) is 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 coverage is 100% — the single `id` parameter is documented as "ID da automação" — so the schema already does the parameter work. The description's "pelo ID" merely restates it and adds no format, source, or validation detail, matching the baseline 3 for a fully covered schema.

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

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

States a specific verb ("Obtém"), resource ("regra de automação") and lookup key ("pelo ID"), and even previews the payload (condição, ação, estatísticas de execução). This clearly separates it from novacrm_list_automations and the create/update/delete siblings, though no sibling is named 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 when-to-use is implied: fetch a single automation when you already have its ID. There is no explicit guidance on where the ID comes from (e.g., novacrm_list_automations) nor any note about when to prefer listing instead, so usage remains inferred rather than stated.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that the operation is read-only, what happens if the ID does not exist, whether the lookup is scoped to a workspace, or anything about the response shape for a single-record retrieval.

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

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

A single, front-loaded sentence with no wasted words. It is economical, though its brevity is also the source of its informational gaps rather than a deliberate structural choice.

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-parameter read tool with no output schema and no annotations, the description covers the core action but leaves the return payload and failure modes unexplained. It is minimally adequate rather than complete.

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

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

Schema description coverage is 100%, and the single 'id' parameter is documented in the schema as 'ID do cliente'. The description only repeats that filtering is by ID, adding no format, type, or validation detail beyond the schema, so the baseline 3 applies.

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 ('Obtém') and resource ('detalhes de um cliente específico pelo ID'), which clearly distinguishes it from list_clients, create_client, and update_client in the sibling set. It is clear what the tool does, though it does not explicitly name the sibling alternative.

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 phrase 'pelo ID' implies usage when a single client's details are needed, but there is no explicit when-to-use guidance and no mention of novacrm_list_clients as the alternative for enumerating clients. Usage is only inferable from the name and verb.

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?

No annotations are provided, so the description carries the burden. It does disclose the aggregated content of the response (revenue, ticket médio, order counts by status), which implies a read-only, store-scoped operation, but it never states explicitly that it is read-only, whether the scope is a single store or the whole account, or whether there is any time-window default. Adequate but with clear disclosure gaps.

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

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

One sentence, front-loaded with the scope (loja) followed by the enumerated metrics; no filler. It is slightly compressed to the point of omitting a verb and any usage clause, but nothing present is wasted.

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-required-parameter, single-enum tool with no output schema, the description usefully enumerates what the default response contains, which compensates for the missing output schema. The remaining gap is the absence of any statement about scoping or time range, which matters for interpreting the numbers.

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 100% and the single enum parameter is documented in detail in the schema, including what each of revenue/orders/products/clients/inventory/visits returns. The description adds nothing about the detail parameter, so this is the baseline 3 case where the schema does all the work.

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 names the resource (loja analytics summary) and enumerates the concrete metrics returned: faturamento pago, ticket médio, pedidos por status, total de clientes e produtos. That clearly separates it from the CRUD siblings like novacrm_list_orders or novacrm_list_clients. It is a noun phrase rather than a verb+resource statement, so it stops short of 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 call this versus alternatives. In particular, novacrm_inventory_alerts and novacrm_get_store_visits are siblings that overlap with the inventory and visits modes exposed by the detail enum, and the description never explains which to prefer. The detail parameter's role in selecting among views is left entirely to the schema.

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?

No annotations are provided, so the description carries the full burden. It is clearly a read operation and it discloses the main payload fields (cliente, valor, estágio), which is useful, but it says nothing about behavior for an invalid/unknown ID or whether the result is scoped to the authenticated store.

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

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

A single front-loaded sentence with the verb first and no filler. Every clause, including the returned-field list, adds 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 one-parameter read tool with no output schema, the description is nearly sufficient: it names the lookup key and summarizes the returned fields. Only error behavior and store scoping are missing, which are minor for this complexity.

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 100% with a single required 'id' parameter already documented as "ID da oportunidade". The description's "pelo ID" merely restates the schema, adding no format or sourcing guidance, so the baseline 3 applies.

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 and resource ("Obtém uma oportunidade pelo ID") and even names the key fields returned (cliente, valor, estágio). It implicitly distinguishes itself from novacrm_list_opportunities by the singular/ID-based framing, but never explicitly contrasts with it or with novacrm_update_opportunity.

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 only implied: an agent can infer you call this when you already hold an opportunity ID and need its details. There is no explicit 'use this instead of list_opportunities when searching' guidance, and no stated prerequisites or exclusions.

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

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

No annotations are supplied, so the description must carry the behavioral burden. It does disclose the shape of the returned data, which compensates for the missing output schema, but says nothing about read-only semantics, error behavior for an unknown ID, or any auth/permission requirements.

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

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

One short sentence, front-loaded with the action and followed by the useful return-content parenthetical. Nothing is wasted, though there is little structural elaboration beyond the single clause.

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-parameter read tool with no annotations and no output schema, the description covers what an agent most needs: that it returns a single order's details and what those details include. Missing only edge-case behavior (not-found handling, permissions).

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 is a single required parameter whose schema description coverage is 100%, so the schema already documents 'id' as the order ID. The description adds no format, example, or source hint (e.g., where to obtain the ID) beyond that, which is the baseline case for high schema coverage.

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

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

States a specific verb and resource ('Obtém os detalhes de um pedido específico') and enumerates the payload it returns (items, customer, address, payment). This clearly separates it from novacrm_list_orders, though it never names that sibling 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?

Usage is only implied: 'específico' signals it takes a single identifier, so an agent can infer it should be used after a list call. There is no explicit when-to-use, when-not-to-use, or named alternative such as novacrm_list_orders.

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?

No annotations are provided, so the description carries the full burden. 'Obtém' implies a read, but it says nothing about behavior on an invalid/nonexistent ID, permissions, or what is returned (a full product object vs partial).

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

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

A single, front-loaded sentence with no waste. It is appropriately sized for a one-parameter getter, though it could carry slightly more routing detail without bloat.

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 single-parameter lookup with a fully documented schema, the description is minimally adequate. Without an output schema, however, it doesn't describe what 'detalhes' includes, leaving the return shape unknown.

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 100%, with the only parameter 'id' documented as 'ID do produto'. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Obtém os detalhes de um produto específico pelo ID'), making the single-record fetch unambiguous. It does not explicitly contrast with siblings like novacrm_list_products, but the 'específico pelo ID' phrasing implies the distinction.

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

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

There is no explicit guidance on when to use this instead of novacrm_list_products or what preconditions apply (e.g., product must exist). Usage is only inferable from 'pelo ID'.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the payload includes the related client, line items and totals — content not derivable from the input schema — but says nothing about read-only semantics, not-found behavior, or permissions. Given the low-risk nature of a single-ID fetch, this is adequate rather than 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?

A single, front-loaded sentence with zero filler: verb, resource, key, and returned contents in one pass. Nothing could be removed without losing 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 one-parameter read tool with no output schema, the description is sufficient — it names the key and summarizes the returned structure (client, items, totals). Only the absence of not-found or error behavior keeps it short of full 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?

There is one required parameter with 100% schema description coverage ('ID da proposta'), so the schema already does the work. The description only restates that the lookup is by ID, adding no format or sourcing detail beyond the schema.

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

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

States a specific verb and resource ('Obtém uma proposta') plus the lookup key ('pelo ID'), and enumerates what is bundled in the response (cliente, itens, totais). It is clearly distinguishable from novacrm_list_proposals, though it never names the siblings it contrasts with.

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 only implied by 'pelo ID' — fetch a single known proposal. There is no explicit guidance on when to prefer this over novacrm_list_proposals or how to obtain the ID in the first place, so the agent must infer the single-record vs. list split.

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?

No annotations are provided, so the description carries the full burden. It usefully clarifies that only public store data is returned (scoping what is exposed), but it doesn't confirm read-only safety, whether authentication is required, or error 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?

A single front-loaded sentence with the verb and resource first and the field enumeration in a parenthetical. No redundant or filler text.

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 parameters and no output schema, the description is the only source of return-value information, and it partially delivers by listing key fields. It stops short of describing the full response shape or behavior on missing store, which is a minor gap for such a simple tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumerated return fields add value since no output schema exists.

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 specific verb ('Obtém') and resource ('informações públicas da loja') and enumerates the returned fields (nome, descrição, WhatsApp, tema, horários). This clearly separates it from mutation siblings like novacrm_update_store or novacrm_set_store_status, though it never names them 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 word 'Obtém' plus the read-only framing implies this is the retrieval counterpart to novacrm_update_store, but the description never states when to use it versus alternatives or any preconditions. Usage must be inferred 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?

No annotations exist, so the description carries the full burden. It does disclose two meaningful traits: the data is anonymous and aggregated, and the window is fixed at 30 days with no parameters. It does not state read-only safety explicitly, nor return format, freshness, or rate limits, leaving real gaps for a tool with zero structured metadata.

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

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

A single sentence, front-loaded with the resource and time window, followed by a compact enumeration of returned metrics. Every listed item earns its place because there is no output schema to carry that information.

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

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

With no input parameters, no annotations, and no output schema, the description's enumeration of returned metrics is exactly the compensation needed. It is nearly complete; only the absence of any note on data freshness or how the aggregate is scoped (store-level vs. account-level) leaves a small gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The baseline of 4 applies; the fixed 30-day window in the description usefully confirms the agent cannot narrow the range.

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 specific verb+resource ("Acessos à loja pública") plus a fixed window ("últimos 30 dias") and enumerates the metrics returned, so the agent knows exactly what it retrieves. It does not explicitly distinguish itself from sibling analytics tools like novacrm_get_metrics or novacrm_get_store, which keeps it below 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 when-to-use / when-not-to-use guidance and no mention of alternatives such as novacrm_get_metrics, which is the closest sibling for analytics. The only implicit cue is the fixed 30-day scope, which tells the agent this is not parameterizable but not when to prefer it.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that the response embeds a linked client and date fields, which is useful return-shape context beyond the schema, but it says nothing about permissions, errors when the ID is unknown, or whether the read is side-effect free.

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

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

A single short sentence with the key operation front-loaded and zero padding. Nothing could be removed without losing 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 one-parameter read tool with no output schema, the description covers what it fetches and roughly what it returns (linked client, dates). Auth requirements and not-found behavior are the only notable omissions, and those are modest for a simple getter.

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

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

Schema coverage is 100% and the single parameter 'id' is documented in the schema as 'ID da tarefa'. The description restates that lookup is by ID but adds no format, source, or acquisition guidance (e.g., where to obtain the task ID), so the baseline of 3 applies.

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 and resource ('Obtém uma tarefa pelo ID') and adds what comes back (linked client and dates). It is clearly a single-record fetch, distinguishable in spirit from novacrm_list_tasks, though the sibling is never named.

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 only implied by 'pelo ID' — an agent can infer this is the single-task retrieval tool that requires an identifier. There is no explicit when-to-use/when-not or comparison against novacrm_list_tasks or novacrm_get_client for the linked-client data.

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?

No annotations, so the description carries full burden. It does add one real behavioral fact — the 500-records-per-call ceiling — but says nothing about duplicate/conflict handling, atomicity or partial failures, required permissions, or whether existing clients are updated or rejected, all critical for a bulk write.

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

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

A single sentence that front-loads the action, the batch limit, and the intended scenario. Nothing is redundant and nothing could be trimmed without losing 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 bulk mutation with no annotations and no output schema, the description should state what happens on invalid rows or duplicates and what the call returns (count imported, per-item errors). None of that is covered, leaving the agent unable to predict failure behavior.

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

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

Only one parameter with 100% schema description coverage, and the schema already notes records use "mesmos campos do create_client". The description adds only the 500-item cap, which is a volume constraint rather than per-field meaning, so baseline 3 applies.

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 specific verb and resource ("Importa clientes") plus a batch cap of 500 per call, which separates it from the single-record novacrm_create_client. It never names that sibling explicitly, so differentiation is implied through "em lote" rather than stated.

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?

"ideal para migração de dados de outro sistema" gives a scenario for use, but there is no explicit when-not guidance or pointer to novacrm_create_client for one-off records. The agent must infer the routing from the word "lote".

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

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

With no annotations at all, the description carries the full burden, and it does disclose the default threshold of 5 units — real behavioral information. However, it says nothing about whether out-of-stock (zero) items are included, result ordering, or size limits, which matters for a list/alert tool.

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

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

A single compact sentence with the core filtering rule front-loaded and zero filler. Nothing can be trimmed without losing 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 one-optional-parameter read tool this is adequate — the agent knows what it returns conceptually (products with low stock). But without annotations or an output schema, the description should say more about what a caller receives (product fields, inclusion of zero-stock items).

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 100% and the single threshold parameter is documented in the schema, so the baseline is 3. The description restates the default value (5) already present in the schema, adding no new meaning about units or how equality at the boundary is treated.

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+resource pair ('Lista produtos em estoque baixo') that an agent can act on immediately, and it defines what 'low' means (below the threshold, defaulting to 5). It does not explicitly distinguish itself from the nearby novacrm_list_products or novacrm_adjust_stock siblings, so it stops short of 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?

The low-stock framing implies the use case (finding products that need restocking) but there is no explicit when-to-use or when-not-to-use guidance, and no reference to the alternative novacrm_list_products. An agent must infer the routing decision from context alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses that archived duplicates exist as a byproduct of the duplicate-review process, but says nothing about permissions, read-only nature, result ordering, or how many rules are typically returned.

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 short sentences with no filler; the core purpose comes first and the flag guidance follows. Every clause carries 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 read-only listing tool with three optional, fully documented params and no output schema, the description covers what is returned (triggers and actions) and the archival nuance. Only the relationship to novacrm_get_automation and pagination expectations are unaddressed.

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

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

Schema coverage is 100%, so limit, offset, and includeArchived are already documented with defaults and ranges. The description adds only a rationale for includeArchived (copies archived by duplicate review) and no extra detail on paging behavior, so the baseline of 3 applies.

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 specific verb ('Lista') and resource ('regras de automação da loja'), and clarifies the content of those rules (gatilhos e ações). It is clearly distinct from novacrm_get_automation for a single rule, though it never explicitly contrasts itself with 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 second sentence gives guidance only for the includeArchived flag, not for when to choose this tool over novacrm_get_automation or how to page through results. Usage as a bulk listing tool is implied by the verb rather than stated.

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

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

With no annotations, the description must carry the behavioral burden; it confirms pagination and store scoping, which is useful, but says nothing about read-only safety, result ordering, or whether totals are returned. Adequate for a simple list tool 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?

A single short sentence with the core action and scoping front-loaded and no filler. It is efficient, though slightly under-specified rather than overly long.

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 3-optional-parameter list tool with no output schema, the description covers the essentials (what is listed, pagination) supported by complete schema docs. It leaves gaps an agent might want: sort order, what a page contains, and archived default behavior (only found in schema).

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 100%, so limit, offset, and includeArchived are already fully documented with ranges and defaults. The description's mention of pagination aligns with the schema but adds no syntax or format detail beyond it, so the baseline 3 applies.

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 specific verb+resource ("Lista clientes da loja") and mentions pagination, which separates it from mutation siblings like create_client/update_client. It does not explicitly contrast with get_client or import_clients, so differentiation is implied rather than stated.

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 listing nature implies when to use it (enumerating clients rather than fetching one), but the description never says when to prefer novacrm_get_client for a single record or how it relates to import_clients. Usage is inferable from the name only.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It never states that the call is read-only, whether results are paginated or capped, whether expired/inactive coupons are included, or what fields come back — all meaningful for an agent deciding how to use the output.

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

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

A single short sentence with no filler, and the verb-plus-resource core is front-loaded. It is efficient rather than padded, though the brevity is a symptom of under-specification rather than deliberate economy.

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 list tool there is little an agent strictly needs in order to call it, and no output schema exists to explain the return. Still, the description omits whether the result set is filtered (active only), how large it may be, or whether pagination exists — gaps that matter when a coupon list could be long.

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

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

The schema has zero properties, so there are no parameters to document and the baseline of 4 applies. The description correctly implies the tool takes no arguments, consistent with the empty object schema.

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

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

States a specific verb ("Lista") and a specific resource ("os cupons de desconto da loja"), so an agent immediately knows this is a read operation over coupons. It does not, however, distinguish itself from sibling coupon tools such as novacrm_create_coupon or novacrm_validate_coupon, so it falls short of 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?

The description gives no guidance on when to call this versus the other coupon-related siblings, no prerequisites, and no mention of scope (all coupons vs. active only). The only usage signal is the implicit "list" semantics.

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?

No annotations are supplied, so the description carries the full behavioral burden; 'Lista' does establish this as a read-only, non-mutating operation. However, it says nothing about default result ordering, whether all stages are returned by default, or behavior on empty results, so an agent must infer those traits.

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

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

A single front-loaded sentence with the verb first and the two scoping dimensions attached; there is no filler and nothing is buried.

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 zero-required-parameter list tool with a fully documented schema and no output schema, the description is sufficient to call it correctly. Minor gap: it does not hint at what a returned opportunity contains or whether results are sorted, which would help an agent interpret the paged output.

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 100% and all three parameters carry their own descriptions, defaults, and an enum for stage, so the baseline of 3 applies. The description only echoes 'filtro por estágio e paginação' without adding constraints such as max limit or stage semantics beyond the schema.

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

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

States a specific verb and resource ('Lista oportunidades do pipeline de vendas') plus the two dimensions it exposes (stage filter, pagination). It is clearly distinct from the singular sibling novacrm_get_opportunity, though it never names siblings 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 presence of an optional stage filter and pagination implies the browsing/filtering use case, but there is no explicit when-to-use or when-not-to-use statement, and no routing toward novacrm_get_opportunity for a single record or novacrm_list_proposals for a different resource.

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

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

With no annotations, the description carries the safety burden, and 'Lista' conveys a read-only, non-destructive operation plus that filtering and pagination are optional. It stops short of documenting ordering, default page size behavior, or any auth/scope constraints.

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

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

A single front-loaded sentence with no redundant text. It is efficient, though its brevity means it never develops the pagination or filtering guidance it teases.

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, fully documented 3-parameter list tool with no output schema, the description covers the essentials but omits what the returned list looks like (fields, ordering, total count) and how pagination terminates, which an agent must infer.

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 100%, including the enum values for status and ranges for limit, so the baseline is 3. The description only restates that status filtering and pagination exist, adding no format, default, or interaction details beyond the schema.

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

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

The description uses a specific verb and resource ('Lista pedidos da loja') and names the two modifying dimensions (status filter, pagination). It implicitly distinguishes listing from the single-order sibling novacrm_get_order, but never explicitly routes between them.

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 only implied: 'filtro opcional por status' hints at when to filter, but there is no statement of when to use this versus novacrm_get_order or status-mutating siblings like novacrm_update_order_status. No exclusions or prerequisites are given.

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?

No annotations are provided, so the description must disclose the behavior itself. It notes pagination but does not say what the default ordering is, whether archived items are returned (only the schema hints at this), whether the call is read-only, or what the response contains.

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

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

A single front-loaded sentence with no filler. The tool's action and pagination scope appear immediately.

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-required-parameter list tool with full schema coverage and no output schema, the description covers the core action but leaves out the behavioral context (ordering, archived behavior, read-only nature) that the absence of annotations makes important.

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 100% and all three parameters already carry defaults and ranges, so the schema does the parameter documentation. The description only repeats the pagination concept and adds no new semantics such as ordering or filtering behavior.

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 + resource ("Lista produtos do catálogo da loja") that unambiguously separates it from the singular novacrm_get_product and from novacrm_create/update/delete_product. It does not name a sibling explicitly, so it falls short of 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?

The description gives no guidance on when to use this instead of novacrm_get_product or novacrm_inventory_alerts, and no exclusions or prerequisites. Usage is only inferable from the name and the word "catálogo".

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?

No annotations are provided, so the description carries the burden. The verb 'Lista' implies a read-only, non-destructive operation, and the mention of filtering and pagination adds useful behavioral context, but the description says nothing about what fields are returned, result ordering, or whether pagination has a total count.

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

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

A single efficient sentence with no waste, front-loading the resource (proposals) and then its two scoping controls. Slightly under-specified rather than over-long.

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 3-parameter read-only list tool with full schema coverage and no output schema, the description covers the essentials but omits what a caller gets back and how results are ordered, which would matter for an agent deciding between this and get_proposal.

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 100%, including an enum for status and explicit defaults for limit (50) and offset (0), so the schema does the heavy lifting. The description only echoes that status filtering and pagination exist, adding no syntax or format detail beyond the schema.

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

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

The description states a specific verb and resource ('Lista propostas comerciais') and mentions the two dimensions that shape the result (status filter and pagination). It is clearly a list operation, but it never distinguishes itself from siblings like novacrm_get_proposal or novacrm_list_opportunities, leaving the agent to infer the boundary.

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 versus novacrm_get_proposal for a single record, nor any mention of prerequisites or exclusions. The agent must infer usage from the verb alone.

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?

No annotations are supplied, so the description carries the full disclosure burden; it implies read-only via 'Lista' and signals that pagination exists, which is genuinely useful. It does not cover ordering of results, whether the list is scoped to a user/workspace, how archived records behave by default, or rate limits — meaningful gaps for an unannotated tool.

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

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

A single front-loaded sentence with no filler, and the filter/pagination capabilities come early. It is efficient, though so terse that it borders on under-specification rather than crisp brevity.

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

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

For a read-only list endpoint with four optional parameters, a fully documented schema, and no output schema, the description is minimally adequate. It omits result ordering, the default status scope ('todas'), and any routing advice, which an agent would need to use it correctly alongside the many sibling 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 coverage is 100%, with each of the four parameters documented (limit range 1–100 default 50, offset, status enum, includeArchived default false). The description only echoes 'status' and 'paginação' and adds no format or interaction detail beyond the schema, so the baseline 3 is right.

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 gives a specific verb and resource ('Lista tarefas da agenda comercial') plus the two axes of control (status filter, pagination), which lets an agent separate it from novacrm_get_task or novacrm_create_task. It stops short of naming any sibling explicitly, which keeps it out of 5 territory.

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 never states when to reach for this tool versus novacrm_get_task, novacrm_list_opportunities, or the other list endpoints, and offers no exclusions or prerequisites. The agent has to infer the use case from the tool name alone.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not say whether this is read-only (implied), whether results are paginated, whether auth is required, or what fields a webhook entry contains.

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

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

A single short, front-loaded sentence with no filler. It is arguably too terse rather than bloated, but nothing needs trimming.

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 tool this is nearly enough, but with no output schema and no annotations the description never indicates the shape of the returned list (ids, URLs, subscribed events) or ordering. An agent can call it correctly but cannot anticipate the response.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering inputs beyond the store scope.

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 specific verb ('Lista') and resource ('webhooks') scoped to the store, which clearly distinguishes it from the sibling novacrm_create_webhook. It is clear what the tool does, though it does not call out the contrast with any alternative 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?

There is no statement of when to use this versus alternatives, nor any prerequisites or exclusions. The only implied guidance is the word 'Lista' versus the sibling 'create_webhook', which an agent must infer.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose real side effects: won sets probability to 100, lost zeroes it and consumes a loss reason. It does not say whether transitions are validated or reversible, whether stages can be skipped or moved backwards, or what permissions are needed.

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 dense sentences with no filler, and the core action plus stage ladder is front-loaded before the won/lost side effects. Nothing is wasted, though the loss-reason clause could be folded in more tightly.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the stage side effects well but omits error conditions, transition rules, and what the call returns. It is adequate to invoke correctly, but not complete for a write operation with zero annotation coverage.

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 100%, so the schema already documents id, stage (with enum), and lossReason, making 3 the baseline. The description adds some meaning by presenting the stages as an ordered funnel and clarifying that lossReason is only meaningful when stage=lost, but it adds no format or constraint detail beyond that.

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 ('Move') and resource ('oportunidade de estágio no funil') and enumerates the full stage ladder (lead → contact → proposal → negotiation → won/lost), so the operation is unambiguous. It does not distinguish itself from the sibling novacrm_update_opportunity, which plausibly could also change stage, leaving that boundary 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?

There is no statement of when to use this tool versus novacrm_update_opportunity, and no prerequisites or exclusions. The only guidance is implicit in the funnel-stage framing; the second sentence describes side effects, not usage conditions.

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

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

With no annotations, the description carries the full burden: it correctly implies a read-only diagnostic and discloses that it exercises API-key authentication, which is useful pre-flight context. However, it says nothing about what a failure looks like, whether errors surface as tool errors versus a status payload, or about latency/rate-limit cost.

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 short sentences, front-loaded with the purpose and followed immediately by the operational instruction. Nothing is padded or restated from the 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 zero-parameter health check the core intent is covered, but with no output schema and no annotations the description should say what the call returns or how auth failure manifests, since that is the only thing an agent would call this tool to learn.

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 takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed and that credentials come from configuration rather than arguments, which is worth stating given the auth framing.

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 specific verb and resource ('Testa a conectividade e a autenticação da chave de API') against a named system, NovaCRM. It is unmistakably distinct from every sibling, which all operate on CRM entities rather than on the connection itself.

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?

'Use antes de qualquer outra ferramenta para validar a configuração' gives an explicit sequencing instruction relative to the 40+ sibling tools. It lacks a when-not clause (e.g., after a successful auth already established in the session), so it stops just short of full routing 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?

No annotations are provided, so the description carries the full burden, yet it says nothing about permissions, whether omitted booleans leave existing state untouched, or whether the change is visible immediately to customers/marketplace. It only restates the two toggles that the schema already defines.

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

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

A single short sentence with no filler, front-loaded with the action verbs. It is efficient, though the terseness comes at the cost of clarity and the description is in Portuguese while the tool name and most siblings are English.

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 two-optional-boolean mutation tool with no annotations and no output schema, an agent can still call it, but it must guess how omitted parameters behave and what the tool returns. The description is not wrong, just thin for a state-changing operation on a live storefront.

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 100%, and the property descriptions ('Loja aberta para pedidos?', 'Vitrine publicada no marketplace?') already explain each boolean's meaning, so the schema does the heavy lifting. The description adds the mapping of toggle direction (open/close, publish/unpublish) but no default or partial-update 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 sentence names specific operations (open/close store, publish/unpublish storefront) applied to the store resource, which is enough to grasp intent at a high level. However, it does not distinguish this from the close sibling `novacrm_update_store`, which plausibly also mutates store state, nor does the title help. Purpose is identifiable but not clearly differentiated.

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 statement of when to use this tool versus `novacrm_update_store` or `novacrm_get_store`, no preconditions, and no note that both parameters are optional. The agent must infer usage entirely from the tool name and schema.

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?

No annotations are provided, so the description carries the full behavioral burden. It conveys partial-update semantics but says nothing about required permissions, whether changes are reversible, side effects on active rules, or the response shape for a mutation tool.

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

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

A single tight sentence with no waste, and the partial-update instruction is placed inline where it is immediately useful. Appropriately sized, though there is little content to structure.

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 7 parameters, a nested actionConfig object, no output schema, and only 29% schema coverage, the description is too thin. An agent lacks guidance on enum values, the payload shape of actionConfig, and the mutation's behavioral constraints.

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 low at 29%, so the description should compensate but only adds the partial-update rule. It does not explain the trigger/actionType enums or the nested actionConfig object, leaving most parameters undocumented in either place.

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 specific verb and resource ('Atualiza uma regra de automação existente'), which cleanly distinguishes it from the create/list/get/delete automation siblings in name and verb. It does not explicitly name those siblings, keeping it just below 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?

The parenthetical 'envie apenas os campos a alterar' gives useful partial-update guidance, implying when to use it over a full replace. However, there is no explicit statement of when not to use it or how it differs from novacrm_create_automation or novacrm_delete_automation.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose partial-update semantics, but says nothing about permission requirements, irreversibility of the mutation, behavior for a nonexistent id, whether fields can be cleared, or how nested objects like 'address' merge.

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

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

A single front-loaded sentence with zero filler; the mutation caveat is bundled into the parenthetical where it belongs. It is efficient, though the compression leaves little room to expand any of the missing 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?

For a 9-parameter mutation tool with no annotations, no output schema, a nested object parameter, and 11% schema coverage, this one-liner is far too thin. An agent cannot confidently determine field semantics or post-call expectations from what is given.

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 only 11% – just 'id' is documented – so the description must compensate and does not. It adds the meaningful partial-update rule, but the remaining eight parameters (tags, status, clientType, the nested address object) are left entirely without semantics or allowed values.

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 names a specific verb ('Atualiza') and resource ('dados de um cliente existente'), which also implicitly distinguishes it from novacrm_create_client. However, it never names the sibling read/creation tools or clarifies scope beyond 'existing client', so an agent must still infer the boundary with novacrm_get_client.

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 parenthetical '(envie apenas os campos a alterar)' gives a genuine calling convention for a partial update, which is useful. But there is no guidance on when to prefer this over create_client or get_client, no prerequisites (must the client already exist / what happens otherwise), and no notes on which of the nine fields can actually be updated.

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?

No annotations are provided, so the description carries the full behavioral burden for a mutation tool, and it discloses only that the update is partial. It says nothing about permissions, side effects of moving stage to won/lost, whether lossReason becomes required, or what happens when the id does not exist.

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

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

A single short sentence with the partial-update caveat placed immediately after the action, so nothing is buried. It is efficient, though the brevity is achieved by omitting detail rather than by tight phrasing of complete information.

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

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

With nine parameters, no annotations, no output schema and near-zero schema documentation, the description is too thin for the complexity of the tool. An agent cannot tell from it how fields interact, what validation applies, or what a successful update returns.

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

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

Schema description coverage is only 11% — just the id field is documented. Eight parameters, including value, probability, expectedCloseDate, lossReason and notes, have no description anywhere, and the description does not compensate by explaining their meaning or constraints (e.g. the lossReason/stage=lost relationship).

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 gives a specific verb and resource ("Atualiza uma oportunidade existente"), which clearly distinguishes it from the create/list/get/delete/move opportunity siblings. It stops short of naming a sibling to disambiguate against, but the core purpose is unambiguous.

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

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

The parenthetical "envie apenas os campos a alterar" is a real usage instruction, telling the agent this is a partial update rather than a full replace. However, it gives no guidance on the notable overlap with novacrm_move_opportunity, which appears to also change stage, nor any prerequisites for when this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden: it implies a mutation but says nothing about permissions, whether status transitions are validated, side effects (stock, notifications, emails), or reversibility. The single example 'marcar como pago' also references a 'paid' state that does not exist in the enum, which could mislead an agent.

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

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

One short sentence with zero filler, and the verb+resource is front-loaded. It is efficient, though the space saved is not spent on the transition/permission details that would actually help an agent.

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 mutation tool with no annotations and no output schema, the description omits what an agent needs beyond the schema: allowed transitions, error conditions, side effects, and what is returned. The enumerated statuses are supplied by the schema, so the description adds little to it.

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 100% and the enum fully enumerates the five valid statuses, so the schema does the heavy lifting; the description only restates the intent. The illustrative 'pago' example is not in the enum, weakening rather than enriching the parameter 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?

States a specific verb and resource ('Atualiza o status de um pedido') and gives concrete examples of target statuses, so the operation is immediately understandable. It falls short of a 5 because it never distinguishes itself from the overlapping sibling novacrm_cancel_order, which appears to set one of the same enum values ('cancelled').

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 — notably novacrm_cancel_order, which overlaps directly with the 'cancelled' status. No preconditions (order must exist, allowed transitions, permission level) are stated, leaving the agent to infer everything from the 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?

No annotations are provided, so the description carries the full burden. The partial-update contract ('send only the fields to change') is genuinely useful, but there is nothing on permissions, whether omitted fields are left intact, reversibility, or error behavior for an invalid id.

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

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

One compact sentence with the mutation target and the partial-update rule front-loaded; nothing is wasted. It is slightly too terse for a 7-parameter mutation tool rather than padded.

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 mutation tool with no annotations, no output schema, and 6 undocumented parameters needs substantially more description than a single sentence, especially given the overlapping adjust_stock sibling.

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 only 14% (just id), leaving 6 of 7 parameters undocumented. The description groups fields as 'dados, preço ou estoque', which hints at name/description/category/imageUrl vs price vs stock, but it does not compensate for the large coverage gap on category, imageUrl 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 names a specific verb ('Atualiza') and resource ('um produto existente') plus the fields it can touch (dados, preço, estoque). It is clear what the tool does, but it does not distinguish itself from the sibling novacrm_adjust_stock, which overlaps on stock mutation.

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 statement of when to use this versus novacrm_adjust_stock for stock changes, nor versus novacrm_create_product/delete_product. The parenthetical 'envie apenas os campos a alterar' is invocation mechanics, not usage 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?

No annotations are provided, so the description carries the full burden. It says the tool mutates an existing proposal but says nothing about partial-update semantics (are omitted fields preserved or reset?), which is the critical ambiguity for an 8-parameter update, nor about authorization or reversibility.

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

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

A single short sentence, front-loaded with the operation and resource, with no filler. It is efficient rather than bloated; the problem is under-specification, not verbosity.

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

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

For a mutation tool with eight parameters, no annotations, no output schema and a 25% schema coverage, the description should explain update semantics and the undocumented fields. As written, an agent cannot confidently construct a call beyond `id` plus `status`.

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

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

Schema coverage is only 25%, so the description must compensate and does not. It only restates the status parameter (whose enum the schema already enumerates) and leaves items, notes, title, discount, validUntil and paymentTerms completely undocumented, including whether they replace or merge.

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 specific verb and resource ('Atualiza uma proposta existente') plus a scoped emphasis on status changes. It does not distinguish the tool from its close siblings novacrm_create_proposal, novacrm_get_proposal and novacrm_delete_proposal, so the agent must infer the split from names.

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?

Only an implicit cue ('existente') signals that a proposal must already exist. There is no statement of when to prefer this tool over create/delete/get, no prerequisites about required permissions, and no note that only `id` is mandatory.

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

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

With no annotations, the description carries the full burden. It does disclose one genuinely useful behavioral trait — partial-update/PATCH semantics, where unspecified fields are left untouched — but says nothing about permissions, validation rules, failure modes, or what happens to nested structures like openingHours.

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

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

A single short sentence with the key partial-update hint in parentheses, front-loaded with the action. No waste, though the brevity reflects under-specification rather than disciplined editing.

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?

Eight parameters, a nested object, no output schema, and no annotations demand a richer description than one sentence. The definition leaves an agent without enough to correctly populate or validate the fields, and offers no insight into the mutation's effects.

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 only 13% (only themeColor is documented), so the description must compensate and does not. It gives no per-field meaning for the eight parameters and leaves the nested openingHours object entirely undefined in both schema and description; the "only send changed fields" note applies generically but adds no field-level 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?

"Atualiza informações da loja" states a verb (update) and resource (store), but "informações" is generic and the description never names which aspects of the store it covers or how it differs from sibling store tools like novacrm_set_store_status or novacrm_get_store. An agent can tell it mutates store data, but not the scope.

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 only guidance is the parenthetical about sending only changed fields, which is invocation semantics rather than when-to-use. There is no mention of prerequisites, of when to prefer novacrm_set_store_status, or of any conditions that should steer an agent here versus elsewhere.

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?

No annotations are provided, so the description carries the full burden. It states the operation is an update and that only changed fields need sending, but does not say what happens with an unknown id, whether omitted fields are preserved or cleared, whether changes are reversible, or what permissions are needed.

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

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

A single short sentence with the mutation verb front-loaded and the partial-update rule tucked in parentheses; nothing is wasted. It is efficient, though the brevity comes at the cost of the missing detail noted elsewhere.

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 an 11-parameter mutation tool with no annotations, no output schema, and near-zero schema coverage, the description is far too thin. It leaves an agent unable to determine field formats, error behavior, or how this differs from the sibling task 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 only 9% (just the id is documented), and 10 other parameters — including three enums and free-text date/time fields — are undocumented. The description adds only the general partial-update rule, with no format hints for dueDate/dueTime or meaning for clientId vs clientName/clientPhone.

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 names a specific verb and resource ("Atualiza uma tarefa existente"), so an agent immediately knows this is a mutation on an existing task. It does not distinguish itself from close siblings like novacrm_complete_task, novacrm_delete_task, or novacrm_create_task, so the agent must infer the boundary.

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?

"(envie apenas os campos a alterar)" gives real invocation guidance: this is a partial/PATCH-style update, not a full replace. However, it offers no when-to-use-vs-alternative guidance, e.g. whether to use this with status=completed or the dedicated novacrm_complete_task.

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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses little: it does not say whether validation is side-effect free, whether an invalid coupon raises an error or returns a negative result, or how expiry/minimum-value rules are handled. For a validation tool with zero annotation coverage this is a significant gap.

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

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

A single well-formed sentence with no filler, and the core action is front-loaded. It is efficient but so terse that there is no room for the qualifying information the agent needs.

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 no annotations, the description should explain what validation returns (a boolean, a discount amount, an error reason), but it does not. For a 3-parameter validation tool whose entire value is the result it produces, this leaves a critical hole.

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 100%, so the baseline is 3; the description reinforces that subtotal drives the discount computation. It adds nothing about the optional 'items' array, which is the one parameter whose effect on coupon eligibility (e.g., product-scoped coupons) is genuinely non-obvious.

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+resource pair ('Valida um cupom') plus a secondary effect ('calcula o desconto'), which is far more informative than the tool name alone. It doesn't distinguish this tool from siblings like novacrm_list_coupons or novacrm_create_coupon, so the agent must infer the difference itself.

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 statement of when to use this versus listing or creating coupons, and no prerequisites (e.g., the coupon must already exist, the subtotal must meet a minimum). The 'para um determinado subtotal' phrase hints at a checkout context but leaves the trigger condition implicit.

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