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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states the write action ('Adiciona') without mentioning permissions, reversibility, idempotency, whether the note is appended or replaces existing notes, or the shape of the response. This is a significant gap 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, concise sentence that immediately communicates what the tool does, where the note goes, and which entities are supported. Every word earns its place; there is no redundancy or filler.

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

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

The definition is adequate for a simple create operation with 100% schema coverage, but no output schema exists and no annotations are present. The description does not mention what the tool returns on success, failure modes, or any rate limits, which an agent would need for robust invocation and error handling.

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 description coverage is 100%, so the structured data already documents all four parameters. The description adds the semantic context that the note lands on a timeline and that entity_type maps to Lead, Contact, or Company, which aligns with the enum. It does not add detail beyond that, matching the baseline of 3.

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 ('Adiciona' - adds), a precise resource ('nota/observação de texto (common note)'), and the target ('linha do tempo de um Lead, Contato ou Empresa'). It fully distinguishes this operation from any sibling tool; no other sibling creates notes.

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 context of use is implied: when you need to attach a text note to an entity's timeline. However, there is no explicit guidance about when to prefer this over alternatives (e.g., get_notes for reading, or create_task for actions), and no mention of prerequisites like whether the entity must exist or whether client_slug must match an available client.

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 discloses only that the tool mutates (adds users) but says nothing about bulk-operation semantics (partial failures when creating multiple users), duplicate-email behavior, permission requirements, or rate limits. For a mutation tool, 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 front-loaded sentence with zero waste that clearly states the core purpose. It is efficient and every word earns its place, though additional behavioral context would improve completeness.

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 mutating bulk-create tool with no annotations and no output schema, the description is too thin. Key missing context: what happens on duplicate emails, whether partial failures occur when creating multiple users, and what the response contains. The schema covers parameters, but the surrounding behavior is undocumented.

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 with no param info needed from the description. The schema already documents client_slug and the users array (name, email, password, rights_role_id) adequately, and the description adds nothing beyond what the schema provides.

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 ('Adiciona' - adds), a clear resource ('novos usuários' - new users), and scope ('à conta do Kommo'). It unambiguously identifies this as the user-creation operation and is inherently distinguishable from all get_* siblings (get_users, get_user_by_id), which are read operations on the same resource.

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

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

No guidance is given on when to use this tool vs alternatives, prerequisites (e.g., admin permissions), or exclusions. An agent must infer entirely from sibling names that this is the creation counterpart to get_users/get_user_by_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?

With no annotations, the description carries the full burden, but it only states that the task is marked complete and an observation may be added. It doesn't disclose reversibility, permissions, or return behavior, and it contradicts the input schema by calling result_text optional when the schema requires 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?

The description is one front-loaded sentence with no filler, and every clause contributes to understanding the operation. Structure is appropriate for a simple 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 mutation with no annotations, no output schema, and a required parameter that the description calls optional, this is not complete enough. It fails to clarify the response/return behavior and leaves a schema contradiction that could cause an agent to invoke the tool incorrectly.

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?

All three parameters already have schema descriptions, so the baseline is 3. The description's extra value is limited to restating the notion of completion, and its 'opcionalmente' wording actively misleads about the required result_text parameter.

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 ('Marca uma tarefa como concluída') and clearly conveys the state transition. It doesn't explicitly distinguish itself from siblings such as update_task or add_note, so it doesn't reach the top score.

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 intended use is clear: call this tool when a task should be marked as completed and optionally record an outcome. It provides no exclusions or comparison with update_task/add_note, so it misses the 'when not to use' guidance that would earn a 5.

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 burden, and it does state the core side effect (batch creation) and target catalog. However, it does not disclose error/partial-failure behavior, duplicate handling, or response format, which would add useful transparency.

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-structured sentence that front-loads the action and includes the batch and catalog qualifiers. No redundant words.

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

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

For a low-complexity create tool with three well-described required parameters, the description plus schema is nearly sufficient. It lacks explicit output/return expectations and a note about what happens after creation, but those are not critical for selecting the tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds only a small amount of context ('em lote', 'ex: produtos') without going deeper than 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 ('Cria novos elementos') and names the resource, the batch mode, and the destination catalog. This clearly distinguishes it from the read/update siblings (get_catalog_elements, update_catalog_elements).

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

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

It establishes when to use the tool: to create new catalog elements in bulk. It does not explicitly name the alternative update tool as a 'when not to use' case, but the word 'novos' makes the creation-vs-update boundary clear enough.

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

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

Annotations are absent, so the description must carry the full transparency burden. It only states the mutation ('cria') and adds no detail on side effects, permissions, duplicate handling, or response behavior.

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

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

A single concise sentence with no filler. The core action is front-loaded and appropriately sized for a simple create operation.

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

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

The tool is simple and the schema fully covers parameters, so the description is minimally viable. However, it omits what the call returns, whether client_slug must reference an existing client, and how custom_fields_values should be structured.

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 schema already documents name, client_slug, and custom_fields_values. The description adds no parameter semantics beyond what the schema provides.

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') and resource ('nova empresa no CRM'), clearly distinguishing it from siblings like update_company and get_companies. It does not explicitly name alternatives, 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?

No guidance is provided about when to choose create_company over other create tools like create_lead or create_contact. Prerequisites such as requiring a valid client_slug are also not 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?

With no annotations provided, the description carries the transparency burden. It does add useful behavioral facts: the operation packs creation and attachment into a single request and supports duplicate-control rules. However, it leaves ambiguous whether embedded contacts/companies are created or only linked, and it omits expected return behavior or duplicate-handling semantics.

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 states the core purpose first ('Cria um lead de forma complexa'), then the key capabilities and the duplicate-control feature. There is no filler or redundant restatement of the schema.

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 7-parameter tool with nested objects, no output schema, and no annotations, the description plus a fully-described schema gives a usable picture of inputs. But the defining behaviors—how duplicate-control rules behave, whether related entities are created or linked, and what the response contains—are left vague, so an agent cannot fully anticipate side effects or results.

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

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

Schema description coverage is 100%, so the baseline is 3 even with no parameter detail in the tool description. The description provides minimal extra signal beyond the schema—mapping '_embedded' to contacts/companies/tags—but does not clarify parameter syntax or formatting 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?

The description uses a specific verb ('Cria um lead') and a specific resource ('lead'), and immediately distinguishes the tool from sibling 'create_lead' by labeling it 'complexa' and listing what it does differently (attach contacts, companies, tags, etc. in one request). An agent can tell this is the batched/related-entity creation entry point.

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

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

The description clearly communicates the context for use: create a lead when you need to immediately attach related entities and exercise duplicate-control rules. It does not explicitly name the simpler alternative 'create_lead' or state a when-not-to-use condition, so it stops one step short of the best-practice explicit routing.

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 discloses only the core mutation—creating a contact—but not return value, idempotency, required permissions, duplicate behavior, or error handling. This is minimal behavioral disclosure for a write operation.

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

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

The description is a single, front-loaded sentence with no wasted words. It is efficiently concise, though it offers very little beyond the basic action and target system.

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 create operation with fully described parameters, the description is minimally adequate. However, with no output schema and no annotations, it lacks return-value expectations and any usage context, which could leave an agent uncertain about how to confirm success or handle the created contact.

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 description coverage is 100%, with all four parameters already described. The tool description adds no parameter-level detail beyond what the schema provides, 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 clearly states a specific action and resource: 'Cria um novo contato no Kommo CRM' (Creates a new contact in Kommo CRM). This distinguishes it from siblings such as get_contacts, update_contact, and create_lead.

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 like update_contact or create_lead. No exclusions, prerequisites, or context are provided, leaving the agent to infer usage solely from the generic description.

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 provided, the description carries the full burden of behavioral disclosure. It mentions the action (creates) and allowed types, but fails to disclose any side effects, required permissions, or outcomes (e.g., what the response contains). For a mutation tool, 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?

The description is a single concise sentence that front-loads the action and includes useful type examples. It is appropriately sized with no wasted words. Slightly more structure (e.g., listing required fields) would improve it, but it is efficient.

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

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

For a tool with 5 parameters, 2 required, and no output schema, the description is minimal. It does not explain the relationship between entity_type and custom fields, nor does it mention that required fields (name and client_slug) exist. However, the schema provides detailed parameter descriptions, so the agent can infer some context. The description is adequate for basic use but lacks depth.

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 80% (per signal), and most parameters have descriptions. The description adds limited value beyond the schema—listing example types that overlap with the schema's own type description. It does not clarify the meaning or constraints of parameters like group_id or client_slug beyond what the schema provides. Baseline 3 applies because schema covers most of the parameter semantics.

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

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

The description clearly states the tool creates a new custom field for an entity, with specific verb+resource. It provides example types (text, numeric, checkbox, select, date) and distinguishes from siblings like get_custom_fields or update_custom_field. Aims 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 description gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, differences from other custom field operations, or scenarios where this tool is appropriate. It merely describes the action without 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 must carry the full behavioral burden. It states only that a new group is created, with no mention of prerequisites, valid entity types, side effects, permissions, or response behavior.

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

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

The description is a single, front-loaded sentence with no filler. It states the action, the resource, and a helpful parenthetical clarification ('aba/seção') without wasting words.

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

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

For a mutating tool with no annotations and no output schema, more context is needed: how the group relates to custom fields, what entity_type values are supported, and what the API returns after creation. The current description is too sparse to fully support correct invocation.

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

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

Schema description coverage is 75%, so the schema already documents name, sort, and client_slug. The prose adds no parameter-specific meaning, and the undocumented entity_type parameter is not explained, but the high schema coverage keeps this at 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 uses a specific verb ('Cria') and resource ('grupo de campos') and clarifies that this is a tab/section within an entity. This distinguishes it from field-level tools like create_custom_field, though it does not explicitly name or contrast sibling tools.

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

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

There is no guidance about when to use this tool versus alternatives such as update_custom_field_group, delete_custom_field_group, or create_custom_field. The only signal is the verb 'creates,' which leaves context to be inferred.

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 disclosing behavior. It only restates the core action of creating a lead; it does not mention required permissions, side effects, idempotency, response behavior, or what happens if required fields are missing. This is a minimal disclosure 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?

The description is a single short sentence with no filler: 'Cria um novo lead no Kommo CRM.' Every word earns its place, and the CRM context is useful and front-loaded.

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

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

For a tool with seven parameters, no annotations, no output schema, and a closely related sibling create_complex_lead, this description is too sparse. It lacks usage routing, behavioral context, and any indication of what the agent should expect after invocation, despite the schema covering parameter semantics.

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 input schema already documents all seven parameters meaningfully. The tool description itself adds no parameter-level detail, but because the schema handles this, the baseline score of 3 is appropriate.

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

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

The description states a clear verb and resource: 'Cria um novo lead no Kommo CRM' (creates a new lead). It is specific enough to identify the operation, but it does not differentiate from the sibling tool create_complex_lead, which also creates leads, so it loses a point for missing sibling differentiation.

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

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

There is no guidance about when to use this tool versus create_complex_lead or other lead-related tools. The description simply states what it does, leaving the agent to infer when it is appropriate. No exclusions, prerequisites, or alternatives are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action. It does not disclose side effects (e.g., whether default stages are created or how is_main conflicts are resolved), permission requirements, or what the tool returns. The mutation nature is implied by the verb, but no additional behavioral context is added.

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

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

The description is a single efficient sentence that front-loads the core purpose with no wasted words. It is well-structured, though slightly under-sized given the amount of contextual information an agent would need.

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 creation tool with no output schema and no annotations, the description is thin. It does not explain the prerequisite that client_slug must be an available client, what happens on success, or how this relates to creating pipeline stages. An agent knows what the tool does but lacks invocation-level context for a real workflow.

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 (name, sort, is_main, client_slug) are already documented in the schema, meeting the baseline of 3. The description adds no parameter-level meaning beyond the schema. It could have added value by noting that client_slug must match an existing client, but the schema already handles the documentation burden.

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 ('Cria' = creates), a specific resource ('novo funil de vendas (pipeline)'), and a scope ('no CRM'). This clearly differentiates it from read/update/delete pipeline siblings and from create_* tools for other entities. However, it does not explicitly differentiate from the pipeline-stage creation sibling, leaving entity-level ambiguity that the agent must resolve from tool 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?

The description gives no guidance on when to use this tool versus alternatives. It does not mention that client_slug must reference an existing client obtainable via get_available_clients, nor that stages are added separately via the pipeline-stage creation sibling. No exclusions or alternative conditions 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says the tool creates a stage. It does not mention permissions, side effects, uniqueness constraints, default ordering/color behavior, or failure modes.

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

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

The description is a single efficient sentence that states the core action and target without filler. It is front-loaded and easy for an agent to parse.

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

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

For a create operation with five parameters, no annotations, and no output schema, this minimal description is not enough. The agent is left without expectations about required pipeline existence, defaults, the response, or confirmation of success.

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?

All five parameters are fully documented in the schema (100% coverage), so the description does not need to explain them. The description adds no parameter-specific meaning, but the schema already covers this dimension adequately.

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' – creates) and names the resource ('nova etapa (status) dentro de um funil de vendas existente'). This clearly distinguishes it from sibling tools like update_pipeline_stage and delete_pipeline_stage.

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

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

It establishes the prerequisite that the pipeline must already exist ('existente'), which gives some context for when to call it. However, it does not explicitly name alternatives or state when not to use this tool versus update_pipeline_stage.

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 state the core effect (creates a task) and adds a useful validation constraint (complete_till must be a UNIX timestamp), but it omits any mention of permissions, side effects, auth requirements, or response behavior. This is a minimal but not misleading disclosure.

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

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

Two concise sentences in Portuguese, front-loaded with the purpose and followed by the one critical formatting constraint. Every sentence earns its place, with 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 7-parameter creation tool with no annotations and no output schema, the description is adequate but thin. The schema handles parameter details, and the description covers purpose and the timestamp constraint, but it does not mention return/confirmation behavior or explicitly guide entity association. There are clear gaps, but the core invocation requirements are present.

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 a small clarification with examples of task text and reinforces the complete_till format, but it does not add meaning beyond what the input schema already provides for the other parameters.

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

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

States a specific action and resource ('Cria uma nova tarefa no CRM') and gives concrete task-type examples (ligar, reunião, email). This clearly differentiates it from sibling tools like get_tasks, update_task, and complete_task, which operate on existing tasks rather than creating new ones.

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

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

The description implies that this tool is for creating a new task, but it does not explicitly say when to prefer it over update_task or complete_task, nor does it mention any exclusions or prerequisites. The word 'nova' provides basic usage context, but no alternatives are named.

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 disclosing behavior. It states that the tool creates a new template, but does not mention side effects, validation behavior, required relationships (e.g., client_slug must reference an existing client), or WABA-specific requirements beyond a single type hint. A mutation tool like this needs more behavioral context.

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

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

The description is only two sentences, with the primary purpose front-loaded in the first sentence and a helpful WhatsApp-specific hint in the second. No filler or redundant details are present.

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

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

There is no output schema, no annotations, and no usage guidance, so the description needs to provide more context than it does. For a 7-parameter create operation, it should at least mention prerequisites like an existing client_slug, explain WABA category/language expectations, or note what the tool returns. The current description is too thin to fully support correct invocation.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a small extra hint that 'type' is usually 'waba' for WhatsApp, but it does not clarify interactions between type, waba_category, and waba_language. Since the schema already documents parameters well, the description offers only marginal added value.

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') and resource ('novo modelo de chat (template)'), clearly indicating the tool creates a template. This differentiates it from sibling tools like get_templates, update_template, and delete_template. It could be slightly more precise about the relation between 'modelo' and 'template', but overall it is clear.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as update_template or delete_template. The only additional context is a hint about the 'type' parameter for WhatsApp, which is parameter guidance rather than usage context. There are no prerequisites, exclusions, or scenario descriptions.

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 provide useful behavioral information: the registered webhook will trigger POST requests to the destination upon specified events. However, it does not disclose response/return behavior, idempotency, or any permission or webhook-limit 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?

One compact sentence states the action and the key behavioral consequence, with no filler. The most important information is front-loaded and every clause earns its place.

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

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

For a simple three-parameter creation tool with no output schema, the description provides enough context: purpose, destination behavior, and event triggering. It lacks explicit success-response details, but this is not essential given the tool's simplicity.

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 three parameters. The description reinforces the relationship between destination and the POST delivery, but adds little beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Inscreve') and resource ('webhook'), then states the observable effect: Kommo will send POST requests to the destination URL when specified events occur. This clearly distinguishes create_webhook from sibling tools like get_webhooks and delete_webhook.

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 purpose is explicit: use this to register a new webhook. It does not list exclusions or alternatives, but the context is clear and no competing create-variant exists among siblings, so an agent can infer the correct time to use it.

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

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

Annotations are absent, so the description must carry the burden of behavioral disclosure. It only communicates the destructive nature through 'Exclui' but does not state whether the deletion is permanent, irreversible, permission-dependent, or what happens to entity_type-scoped fields. This is a significant transparency gap for a destructive operation.

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 one concise sentence with no filler, directly stating the action and resource. It is appropriately front-loaded and every word contributes to the core meaning.

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 is too sparse to fully inform an agent's invocation. It lacks response expectations, side effects, or any clarification about entity_type or prerequisites, which is inadequate for a 3-parameter destructive 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 description adds no parameter-level information; it does not mention id, client_slug, or entity_type. While the schema documents id and client_slug briefly and gives entity_type as an enum, the description fails to compensate for the undefined meaning of entity_type at 67% schema coverage. It provides zero additional semantic value beyond the schema.

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

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

The description 'Exclui um campo customizado existente' uses a specific verb (Exclui/deletes) and a clearly defined resource (custom field), distinguishing it from sibling tools like delete_custom_field_group. An agent can quickly understand that this tool removes an existing custom field rather than creating, updating, or reading one.

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

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

No explicit when-to-use or alternative guidance is provided, such as when to prefer delete_custom_field_group or update_custom_field. The verb 'Exclui' implies the intended use case is deleting a custom field, but the description does not mention prerequisites like having the custom field id or client_slug.

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 explaining behavioral traits. It discloses only that a field group is deleted, but not whether deletion is irreversible, cascades to contained fields, or requires special permissions. This is minimal behavioral transparency for a destructive operation.

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

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

The description is a single, front-loaded sentence with no redundant wording. It is concise, though so brief that it leaves behavioral and usage details unaddressed.

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 is too sparse for a destructive tool. It fails to mention side effects, restrictions, return values, or the significance of entity_type. An agent has only the input schema to work with, which is insufficient for confident invocation.

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

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

Schema descriptions already cover id and client_slug, and entity_type has an enum and default value. The tool description adds little semantic value beyond naming the resource type, but the schema provides enough baseline meaning for the required parameters. The role of entity_type in deletion remains unexplained.

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

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

The description states a specific verb ('Exclui') and resource ('um grupo de campos'), clearly identifying this as a deletion operation on a field group. It is distinguishable from sibling delete tools like delete_custom_field, though it does not explicitly say 'custom' field group.

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 tool versus alternatives, such as delete_custom_field, nor does it mention any conditions or prerequisites for deleting a field group. An 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?

Annotations are absent, so the description carries the full burden of behavioral disclosure. It does convey that this is a destructive whole-pipeline deletion, but it does not disclose whether associated stages or leads are also deleted, whether the action is reversible, or what permissions are required.

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 one short, front-loaded sentence with no filler or redundant information. It is concise and easy to parse, though the brevity leaves out important behavioral details.

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 tool with no annotations and no output schema, this description is incomplete. It does not explain cascading consequences, irreversibility, validation behavior, or any conditions that should be checked 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 only 50%: client_slug has a description but pipeline_id does not. The description adds no parameter-level meaning, so the agent must rely on the parameter names alone to understand that pipeline_id identifies the pipeline to be deleted.

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

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

The description states a clear action ('Exclui' = deletes) and a specific resource ('funil de vendas inteiro' = entire sales pipeline). It also distinguishes itself from the sibling delete_pipeline_stage by emphasizing that it deletes the whole pipeline.

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. It does not mention prerequisites, such as whether the pipeline must be empty, or caution against using it when only a stage should be removed. The agent must infer usage from the tool name and high-level description.

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 of behavioral disclosure. It conveys that the action is a deletion but does not mention irreversibility, potential impact on associated data, required permissions, or side effects.

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

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

The description is a single clear, front-loaded sentence with no filler. Every word contributes meaning, and the verb-object relationship is immediately visible.

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 with three required parameters, no output schema, and no annotations, this description is too sparse. An agent still lacks enough information about parameter semantics, prerequisites, and consequences to invoke it 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 only 33%, and the description does not compensate. It does not explain that status_id likely identifies the stage, what pipeline_id refers to, or how client_slug scopes the operation.

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 ('Exclui' – deletes) and a specific resource ('etapa específica de um funil' – a pipeline stage). This clearly distinguishes it from siblings such as delete_pipeline, create_pipeline_stage, and update_pipeline_stage.

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 states only what the tool does and gives no guidance on when to use it versus alternatives like delete_pipeline. No context, prerequisites, or exclusions 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It adds valuable context about a Kommo API limitation: deletion only works for templates created by the same integration using the same token. This is important behavioral information beyond the basic 'delete' semantics, though it does not cover all potential side effects or error cases.

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

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

The description is brief and front-loaded: it states the function in the first sentence and then highlights a critical limitation. Every sentence adds value, and there is no redundant wording.

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 two-parameter delete operation with no output schema, the description covers the core purpose and a critical API constraint. It could mention what happens if the template is not owned by the current integration, but the limitation itself already implies that such deletions are not allowed.

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

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

The input schema already provides 100% parameter descriptions for 'id' and 'client_slug', so the baseline is 3. The description does not add any additional semantic detail about the parameters themselves, but it does not need to compensate for schema gaps.

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

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

The description clearly states the action and resource: 'Exclui um modelo de chat' (deletes a chat template). This is specific enough to identify the tool's core function, though it does not explicitly contrast it with sibling tools like create_template or update_template.

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

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

The description implies the tool is used to delete chat templates, and it provides a key usage restriction: only templates created by the current integration/token can be deleted. However, it does not explicitly state when to choose this tool over alternatives or mention any other 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 provided, so the description carries the behavioral burden. It discloses the exact-match requirement for the destination URL, which is genuinely useful, but does not mention permanence of deletion, error behavior when the webhook is not found, or whether client_slug must also match the registration. This is adequate but not comprehensive.

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

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

Two concise sentences with no filler. The primary purpose is front-loaded and the critical usage requirement follows 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 simple delete tool with two required parameters, the description plus schema covers the essential invocation. However, it does not clarify whether client_slug also needs to match the original registration, and there is no output schema or note about success/failure behavior, leaving some gaps for an agent.

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

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

Schema coverage is 100%, establishing a baseline of 3. The description adds extra meaning to the destination parameter by specifying that it must exactly match the registered URL, which is a non-obvious constraint beyond the schema's simple 'URL do webhook a ser removido'.

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

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

The description states a specific action and resource: 'Remove um webhook existente' (remove an existing webhook). This clearly distinguishes it from sibling tools like create_webhook and get_webhooks, and from the many other resource-specific tools in the list.

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 a clear usage condition: the destination URL must be exactly the same as the one previously registered. It does not explicitly name alternatives or when-not-to-use, but the delete context is unambiguous.

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 behavioral context. It does add some useful filtering information by saying 'configurados e disponíveis', indicating the client list is scoped to configured and available items. However, it does not clarify whether this is a read-only operation requiring no side effects, any authentication assumptions, error behavior, or what happens when no clients are configured. For a simple zero-parameter fetch, this is adequate but has clear 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?

The description is a single, front-loaded sentence with no filler. It states the action, the resource, and the scope efficiently, earning a top score for conciseness.

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, no-output-schema tool, the description is nearly complete: it tells the agent that the result is a list of available configured client slugs, which is enough to know what to expect. However, it omits any usage context or qualifications (e.g., when the list might be empty, whether slugs are strings), and the lack of an output schema means a bit more detail about the return shape would have been helpful. Still, the simplicity of the operation keeps it close to fully specified.

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

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

The input schema has zero properties and 100% schema description coverage, so the baseline is 4. The description reinforces that no parameters are needed and clarifies that the result is a list of slugs, adding semantic context beyond the empty schema. Nothing more is required for a parameterless tool.

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

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

The description clearly states the verb 'Busca' (fetches) and the resource: 'a lista de todos os clientes (slugs) configurados e disponíveis neste servidor MCP da agência.' It specifies both the output (client slugs) and the scope (configured and available on this agency's MCP server). Among the large sibling list, no other tool targets 'clientes (slugs)' at this agency level, so it 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 guidance about when to use this tool versus alternatives, no exclusions, and no mention of a use case. The description only says what it does; it does not tell the agent when to prefer this over, for example, get_companies or get_contacts. Usage context is entirely absent.

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; 'Retorna' does signal a read-only retrieval and names the returned content (configurations and custom_fields). However, it does not comment on permissions, not-found behavior, or output shape, which is a noticeable gap 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 sentence with no filler; the verb and object are front-loaded and every word contributes. It is appropriately concise for a simple getter.

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-parameter read tool with fully documented params, the description adequately states what is returned (settings and custom_fields). It lacks error or auth context, but the tool is simple enough that the description is largely complete; no output schema exists, so the high-level return content needs to be, and is, mentioned.

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

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

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds no parameter-specific details beyond implying the catalog is identified by the existing catalog_id parameter.

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 ('Retorna') and a specific resource ('configurações e campos (custom_fields) de um catálogo específico'), so an agent can tell it is a singular catalog lookup rather than a list operation. It does not explicitly name or contrast sibling tools like get_catalogs or get_custom_field_by_id, so it slightly misses the top bar.

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 'catálogo específico' implies using this tool when a particular catalog's settings and custom fields are needed, but no when-not-to-use guidance or explicit alternatives are provided. The agent is left to infer the contrast with get_catalogs from the name and wording.

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 carry the behavioral disclosure burden. It mentions a return value and a textual search field, but it does not disclose pagination behavior, error conditions, or explicit read-only semantics beyond the verb 'Retorna'.

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 one concise, focused sentence with the main purpose front-loaded and no filler. It is well structured for its length, though it omits useful context that could make it more 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?

For a simple list retrieval tool with fully documented parameters, the description plus schema is minimally viable. However, with no annotations, no output schema, and no sibling disambiguation, the agent is left without enough behavioral or selection context for confident autonomous use.

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

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

Schema description coverage is 100% and all five parameters are documented in the input schema. The description's mention of a search field merely echoes the query parameter description and adds no new semantic value, 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 clearly states the verb ('Retorna') and the resource ('lista de itens/produtos... dentro de um catálogo'), so an agent can tell this is about retrieving catalog elements. However, it does not explicitly differentiate from sibling tools like get_catalog_by_id or create_catalog_elements, so the distinction remains 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 when-to-use guidance, no exclusions, and no mention of how this compares to sibling tools. The description simply states what the tool returns, forcing the agent to infer usage context from the tool name and sibling set.

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 behavioral disclosure burden. It clearly indicates a read operation that returns a list, but it does not describe pagination behavior, response shape, or any account-level constraints beyond what the schema already covers.

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

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

The description is two concise sentences with no filler. The core action and resource are front-loaded, and the practical use case is included without unnecessary detail.

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

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

Given the low complexity of a listing tool, the description sufficiently explains what it returns and why an agent would use it. It would benefit from a brief mention of the response format, but the schema already covers parameters and the purpose is clear.

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?

All three parameters (client_slug, page, limit) already have descriptive schema text explaining their meaning and defaults, so schema coverage is 100%. The description adds no additional parameter-level meaning beyond the schema, making the baseline score of 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?

The description uses a specific verb and resource: 'Retorna a lista de todos os catálogos (Lists)' and clearly scopes it to catalogs configured in the account. It also states a concrete use case, discovering catalog IDs, which distinguishes it from related tools like get_catalog_by_id.

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 'Muito útil para descobrir o ID de listas de Produtos' provides a clear context for when this tool should be used: when the agent needs catalog IDs. It does not explicitly name alternative tools or exclusion conditions, but the intended use case is clear enough for a straightforward listing tool.

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 states that the tool searches for a list, but it does not disclose pagination behavior, the need for client_slug, whether results are read-only, or any other operational 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?

The description is a single, efficient sentence with no filler words. It is front-loaded with the main action, though it could be slightly more informative without losing conciseness.

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 list tool with no output schema and no annotations, the description is too thin. It does not mention pagination defaults, the required client_slug, what fields are returned, or how this list differs from similar entities like contacts or leads.

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 50%: query and client_slug have descriptions, while page and limit do not. The tool description does not explain the pagination parameters or how query relates to filtering, so it fails to compensate for the undocumented parameters.

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

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

The description clearly states the action and resource: 'Busca uma lista de empresas cadastradas no CRM' (searches for a list of companies registered in the CRM). This makes the tool's purpose understandable, though it does not explicitly differentiate it from siblings like get_contacts or get_leads.

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 such as get_contacts, get_leads, or create_company. The description provides no context about use cases, exclusions, or prerequisites beyond simply listing companies.

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 disclose side effects, auth needs, and operational scope, but it only says a list is searched. It does not mention whether results are paginated, how the query parameter affects behavior, or any constraints. 'Busca' hints at a read operation, but the behavioral context is mostly absent.

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

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

The text is a single concise sentence with no wasted words. However, it is under-specified rather than efficiently structured; a short description can still be complete, but this one omits usage and parameter context.

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

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

For a tool with no annotations and no output schema, the description should supply more context about return data, pagination, and when to use it. The required client_slug and query semantics are only partially covered by the schema, and the description itself adds no operational context.

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

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

Schema description coverage is only 50%, so the description should compensate for undocumented page and limit, but it says nothing about any parameter. The description adds no meaning beyond the schema, leaving page and limit semantics to inference from their names and defaults.

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 ('Busca'/'searches') and a clear resource ('lista de contatos no Kommo CRM'), so an agent can identify this as the contact-list retrieval tool among siblings like get_companies and get_leads. It does not explicitly call out sibling boundaries or filtering behavior, 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 about when to prefer get_contacts over alternatives such as get_leads, get_companies, or create_contact, and no mention of how query filtering or pagination should be used. The intended usage has to be inferred from 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 are provided, so the description carries the full disclosure burden. It only states the action and one filter, without mentioning pagination, result limits, required client_slug, or any other behavioral caveats.

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 core purpose and one useful filter. No unnecessary detail or repetition.

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

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

For a list endpoint with six parameters and no output schema, the description is serviceable but incomplete: it doesn't surface pagination, the entity_type/entity_id combination, or the requirement of client_slug. The schema helps, but the description alone would leave an agent uncertain about pagination and filtering options.

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 covers 4 of 6 parameters with descriptions, leaving page, limit, and entity_type/entity_id relationship mostly to inference. The description only rephrases contact_id filtering already present in the schema, adding little semantic value beyond it.

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

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

The description uses a specific verb ('Busca') and resource ('lista de conversas (Talks) na Kommo'), and names the contact_id filtering capability. It clearly identifies what the tool does and is the only tool among siblings dealing with conversations, though it doesn't explicitly contrast with any sibling.

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

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

The description indicates a clear use case (fetch conversations, optionally filtered by a client), but it doesn't state when to prefer this over other tools or any exclusions. With no conversation-specific sibling tool, the guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates the basic read-only intent, but does not disclose how entity_type scopes the lookup, what happens for missing or invalid IDs, or how client_slug factors into the request. This is a real gap for a getter with three 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, front-loaded sentence with no filler. It states the action, the object, and the key selection criterion immediately, which is ideal for an agent scanning tool definitions.

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

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

Given no output schema and no annotations, the description is incomplete for non-default lookups. It does not explain that entity_type defaults to 'leads' and must be changed for contacts, companies, or catalogs, nor does it point to get_custom_fields as the list counterpart. For a simple default use it suffices, but not for correct handling of the full parameter space.

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

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

The description only mentions the ID, which the input schema already documents. It does not explain client_slug or the entity_type parameter, though the schema covers 67% of parameters with descriptions and provides an enum for entity_type. The description adds no real parametric meaning beyond the schema, but the schema already handles most of the burden.

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

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

The description states a clear verb ('Busca') and resource ('detalhes de um campo customizado específico') and identifies the retrieval mechanism ('usando o ID'). This effectively separates it from list-style siblings like get_custom_fields and from group-level getters like get_custom_field_group_by_id, though it does not explicitly name those alternatives.

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

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

No guidance is provided about when to use this tool versus alternatives such as get_custom_fields, nor about when the optional entity_type should be changed from its default. The agent must infer usage from the name and sibling list, which is insufficient.

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?

Não há annotations nem output schema, então a descrição carrega todo o peso comportamental. Ela apenas indica leitura ('Obtém detalhes'), sem falar de comportamento de não-encontrado, permissões, erros, ou formato do retorno.

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?

Uma frase curta e direta, com a informação principal no início. Não há redundância, enrolação ou conteúdo enterrado.

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?

Para uma ferramenta sem annotations e sem output schema, a descrição é esparsa demais: não informa o formato do retorno, semântica de erros, nem por que entity_type é relevante. O schema cobre IDs obrigatórios, mas o contexto geral é apenas minimamente viável.

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

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

A cobertura do schema é 67% e a descrição não adiciona significado além de 'por ID', que apenas repete a descrição do parâmetro id. O parâmetro entity_type tem apenas enum, sem descrição, e a descrição não compensa essa lacuna.

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

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

A descrição é específica: verbo 'Obtém', recurso 'grupo de campos de entidade', e chave 'por ID'. Isso distingue claramente de irmãos de listagem como get_custom_field_groups e de get_custom_field_by_id, que busca um campo individual.

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?

O 'por ID' sugere implicitamente que esta é a busca pontual para um ID conhecido, contrastando com get_custom_field_groups. Porém, não há menção explícita a alternativas nem condições do tipo 'use quando tiver o ID, não para listar grupos'.

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 only states the listing purpose and does not mention read-only guarantees, pagination, ordering, response format, or potential side effects.

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 one short, front-loaded sentence with no redundancy or filler. It efficiently conveys the core action and resource without unnecessary details.

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

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

The tool is relatively simple and the schema supplies parameter constraints, so this is minimally viable. However, without annotations or an output schema, the description leaves out return shape and behavioral caveats, and it does not differentiate from sibling get_custom_fields.

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 50%: client_slug is documented, but entity_type is not. The description does not add meaning for either parameter beyond the generic phrase 'de uma entidade', so the agent must infer that entity_type selects the entity kind.

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

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

The description uses a specific verb ('Lista') and a specific resource ('grupos de campos'), clarifying that these are tabs/sections of an entity. This clearly distinguishes the list operation from sibling tools like get_custom_field_group_by_id.

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 such as get_custom_field_group_by_id or create_custom_field_group. The entity scope is implied but no exclusions or selection criteria 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?

With no annotations, the description must carry the behavioral disclosure, and it does convey a read-only list/search operation via 'Busca' and 'estrutura'. However, it does not mention return format, whether entity_type filters results, pagination, or any account-scoping nuance beyond 'da conta'.

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 operation, and includes an illustrative example without filler. Every part contributes to understanding the tool's purpose.

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

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

The tool is a simple read/list with only two well-documented parameters and no output schema. The description plus schema provide enough to select and invoke it; only the exact response shape is left implicit, which is a minor gap for this 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 description coverage is 100%, so the parameters are already documented (client_slug and entity_type with enum/default). The description adds a practical example but no extra meaning about the parameters 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?

The description uses a specific verb ('Busca') with a clear resource ('a estrutura de campos customizados da conta') and a concrete use example (discovering the ID of 'CPF' or 'Origem' to fill a Lead/Contato). This is enough to distinguish it from siblings like get_custom_field_by_id, which targets a single field by ID.

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 a clear when-to-use context: you need the custom-field structure to discover field IDs before filling a Lead/Contato. It does not explicitly name alternatives or exclusions, but the use case is specific enough for an agent to select it over field-level mutations or lookups.

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 only restates the operation implied by the name and does not mention what happens for missing/invalid IDs, required client_slug context, permissions, or response behavior.

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

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

The description is a single concise sentence with no wasted words. It front-loads the verb and resource, making it easy to scan.

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

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

For a simple get-by-id tool, the schema fully documents the two required parameters, and the description states the general purpose. However, without annotations or an output schema, it omits useful context such as not-found behavior and the explicit relationship to get_events. It is minimally adequate but has clear gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no extra parameter meaning, matching the baseline of 3 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?

The description uses a specific verb 'Busca' and identifies a distinct resource ('detalhes de um evento específico') accessed by ID. This clearly separates it from the plural sibling get_events, which would be the listing 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 description implies the tool is for retrieving one specific event when an ID is known, but it does not explicitly mention when to prefer get_events or provide any when-not-to-use guidance. Usage context is only implied, not 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 and no output schema, the description carries the burden of explaining behavior. It does state the main behavior (returns a list/account timeline) and gives concrete examples of event categories. Still, it does not disclose pagination behavior, ordering, response shape, or any side-effect safety information, so transparency is only partially satisfied.

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

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

The description is concise: two sentences, no filler. The first sentence front-loads the core operation and scope, and the second adds a valuable use case with concrete examples, earning its place.

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

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

The description gives enough context to understand what events are and why they matter, but it leaves gaps: no mention of pagination defaults, no output shape, and no routing guidance between get_events, get_event_by_id, and get_event_types. Since there is no output schema, more detail about the returned event list would improve completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic context above the schema by framing events around lead history, stage changes, notes, and tasks, which helps an agent understand how filter_type, filter_entity_id, and filter_entity_type would be used together.

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

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

The description states a clear verb and resource: it fetches the list of events (history/timeline) for the account. It goes beyond a bare restatement by providing examples of event types. However, it does not explicitly differentiate this tool from the sibling get_event_by_id or get_event_types, so it is a 4 rather than 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 implies the tool is useful for investigating what happened to a lead, including stage changes, notes, and tasks. This gives an agent a reasonable context for when to use it, but it does not state when to prefer alternatives such as get_event_by_id or get_event_types, nor does it mention 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 present, so the description carries the full burden. 'Busca' implies a read-only search operation, and the scope is stated as 'disponíveis no sistema'. Yet the description does not explicitly confirm the absence of side effects, nor does it clarify whether results are scoped by the required client_slug or global to the system; the return format is also unspecified.

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

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

The description is a single, front-loaded sentence with no filler. The parenthetical examples immediately illustrate the expected result values, making the description informative without unnecessary length.

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

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

For a simple list tool with one required parameter and no output schema, the description is largely sufficient: it conveys the operation and provides examples of the returned values. It is incomplete only in not clarifying the role of client_slug relative to the 'system-wide' event types or outlining the return shape, which is a minor gap for such a straightforward 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 description coverage is 100%, so the baseline is 3. The tool description adds no information about client_slug beyond the schema's 'Identificador do cliente (slug)', and it does not explain how this parameter influences which event types are returned.

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 ('Busca'/'search') and a specific resource ('todos os tipos de eventos disponíveis no sistema'), reinforced by concrete examples ('lead_added, task_completed'). This makes it easy for an agent to distinguish it from sibling tools that handle event instances, such as get_events and get_event_by_id.

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 intended usage is implied rather than explicit: the agent can infer that this tool should be used when it needs the enumeration of valid event types. However, the description does not mention when not to use it, nor does it reference alternatives like get_events or get_event_by_id, so the decision logic is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. The verb 'busca' signals a read operation, but the description does not disclose what happens when the ID does not exist, whether the 'with' parameter changes the response shape, or role/permission requirements. For a simple fetch-by-id these gaps are acceptable but not ideal.

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 zero filler. The core purpose is front-loaded and no words are wasted; it achieves maximum clarity in minimal space.

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 3-parameter lookup with fully self-documenting schema fields, the description covers the essential purpose adequately. However, it omits any usage context versus get_leads, says nothing about output or not-found behavior, and there is no output schema to compensate. Minor but real gaps for an agent deciding when to invoke this 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 description coverage is 100%, so all three parameters are already documented in the schema. The description only echoes the id parameter ('usando o ID') and adds no new meaning about parameter formats, defaults, or relationships between parameters. Baseline 3 is correct.

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 'Busca os detalhes de um lead específico usando o ID' clearly states a specific verb (busca), resource (detalhes de um lead), and retrieval mechanism (ID). It is immediately distinguishable from the sibling get_leads, which implies list behavior, and from lead mutation tools like create_lead and update_lead.

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 'usando o ID' implies the tool is for when a specific lead ID is already known, and the contrast with the plural get_leads is reasonably inferable. However, there is no explicit guidance on when to prefer this tool over alternatives, nor any mention of exclusions or prerequisites such as requiring a valid client_slug.

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 provided, the description carries the full burden of behavioral disclosure. It states the operation is a search/list ('Busca uma lista de leads') and reveals pagination and query-filtering behavior, which is appropriate for a read-only tool. It does not contradict any annotation and adds relevant context beyond the schema.

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

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

Two short, front-loaded sentences: the first names the action and resource, the second lists the key capabilities. No redundant words or repetition of schema details.

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 list operation with no output schema, the description clearly conveys that a list of leads is returned and how to control it (pagination/query). It could explicitly differentiate from get_lead_by_id, but the word 'lista' already signals that; the schema fills remaining parameter details.

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 parameters are already well-documented. The description only vaguely references pagination and search, which maps to page/limit and query, but adds no parameter-level detail beyond the schema. 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 uses a specific verb 'Busca' and resource 'uma lista de leads no Kommo CRM', clearly indicating this tool fetches a list of leads. It also mentions pagination and search, which distinguishes it from the sibling get_lead_by_id for a single lead.

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

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

The description implies usage for listing leads with pagination or term search, but it does not explicitly say when to prefer this tool over alternatives like get_lead_by_id, nor does it mention any exclusions. The context is clear but not explicit about alternatives.

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 responsibility for conveying behavior. The verb 'Busca' and the phrase 'ler o histórico' imply a read-only operation, which is helpful. However, it does not disclose pagination behavior, response format, or that entity_type must be specified to fetch notes for contacts or companies rather than defaulting to leads.

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, purposeful sentences with no filler. It front-loads the core action and resource, then adds the practical LLM use case, making every word earn its place.

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

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

For a simple read-only tool with 5 parameters and no output schema, the description supplies the essential context: what it retrieves and why an LLM would use it. Minor gaps remain around pagination and the optionality of entity_type, but the schema defaults and clear purpose make the tool sufficiently callable.

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 description coverage is 60%, covering entity_id, client_slug, and entity_type, while page and limit are left undescribed. The description adds meaningful context by mapping entity types to Lead, Contato, or Empresa, but it does not explain pagination parameters or further clarify required identifiers beyond what the schema already provides.

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 ('Busca') and resource ('as notas') targeting a specific Lead, Contato or Empresa, which clearly distinguishes it from sibling tools like add_note. It also explains the intended use case, making the tool's purpose immediately obvious.

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

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

The description explicitly says the tool is useful for the LLM to read history or previous summaries, which gives clear context for when to use it. It does not mention exclusions or alternative tools, but there is no competing read-notes sibling, so the guidance is sufficient without being exhaustive.

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 discloses that this is a read operation and that stages are included, but it does not describe error behavior, response shape beyond 'details', or whether the client_slug is used for scoping.

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 with no filler, front-loading the action and object, and adding the important stage-inclusion detail. Every word earns its place.

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

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

For a simple get-by-id tool with two required parameters, no output schema, and no annotations, the description conveys the essential purpose and the notable stage inclusion. But it omits the response envelope, error cases, and the relationship between pipeline_id and client_slug.

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 50%: client_slug has a description, while pipeline_id has none. The description's 'usando o ID' clarifies that pipeline_id is the funnel identifier, but it does not explain how client_slug relates to the lookup or how to obtain it. Partial compensation for the undocumented parameter.

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 ('Busca') and resource ('detalhes de um funil específico'), and explicitly notes that the response includes stages. It distinguishes this tool from list-oriented siblings like get_pipelines and from pipeline mutation tools.

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

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

The context is implied: use it when you have a specific pipeline ID and need its details. However, it does not explicitly mention alternatives such as get_pipelines for listing all funnels, nor does it state when not to use this tool.

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?

Como não há anotações, a descrição carrega o peso de informar o comportamento. Ela indica que é uma operação de leitura e que o retorno é uma lista de pipelines, o que é útil. Porém, não detalha paginação, necessidade de permissões, formato de resposta ou possíveis erros, deixando lacunas comportamentais.

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

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

A descrição é uma única frase direta, sem redundâncias, e comunica com precisão a ação e o objeto da operação. Todo o conteúdo é relevante e de fácil leitura para o agente.

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?

Para uma ferramenta simples de listagem com apenas um parâmetro obrigatório e cobertura total do schema, a descrição é suficiente para o agente saber o que esperar: uma lista de todos os pipelines da conta. A ausência de output schema é parcialmente compensada pela palavra 'lista'. Faltam apenas detalhes opcionais como ordenação ou paginação, mas não comprometem o uso.

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?

O parâmetro client_slug já está 100% documentado no schema, e a descrição apenas reforça que a busca é feita na conta Kommo, sem acrescentar informações semânticas relevantes além do que o schema oferece. O baseline 3 é adequado.

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

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

A descrição usa verbo específico ('Busca') e recurso claro ('lista de todos os funis de vendas (pipelines) da conta Kommo'), diferenciando-se de get_pipeline_by_id, que busca um funil específico, e de get_catalogs, que trata de catálogos. O escopo 'todos' e 'da conta' define bem a operação.

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

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

A descrição deixa implícito que a ferramenta deve ser usada quando se deseja obter todos os pipelines da conta, mas não menciona explicitamente alternativas, como usar get_pipeline_by_id quando um funil específico já é conhecido. Também não há orientação sobre quando não usar esta ferramenta.

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 'Retorna' implies a read-only operation, and 'permissões exatas' hints at the return content, offering some behavioral context. However, it does not disclose error behavior, authentication requirements, or whether the response includes only permissions versus full role details.

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 concise sentence that is front-loaded with the core action and resource. No redundant words or filler, making it efficient for an agent to parse.

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

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

For a simple get-by-id tool with two well-documented parameters, the description is largely sufficient. It could be slightly more complete by referencing get_roles for listing scenarios or clarifying the return structure, but overall it provides adequate context for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both role_id and client_slug. The description adds minimal semantic value beyond reinforcing that the tool fetches 'pelo seu ID'; it does not explain why client_slug is required or how it relates to role_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 clearly states the action ('Retorna' - returns) and the specific resource ('permissões exatas de um perfil de acesso (Role) específico pelo seu ID'). This distinguishes it well from sibling get_roles, which likely lists roles, by emphasizing exact permissions for a single role.

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 by-ID phrasing implies use when a specific role_id is known and exact permissions are needed, but the description does not explicitly mention when not to use it or point to get_roles as the alternative for listing roles. Usage context is implied 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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation with no side effects, but does not mention output shape, pagination, or permissions. Adequate for a simple list tool, but thin.

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

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

Two concise sentences with the primary behavior front-loaded and the use case immediately after. No wasted words.

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

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

For a simple one-parameter list tool with no output schema, the description is sufficient: it states what is returned and why an agent might need it. It could include return-value details, but these are not critical here.

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 client_slug is already fully documented. The description adds only the contextual notion of 'da conta' (of the account), which reinforces scope without meaningfully expanding on the parameter semantics.

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

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

The description clearly states the action ('Retorna todos os perfis de acesso (Roles) da conta') and the exact resource. It distinguishes itself from sibling get_role_by_id by emphasizing 'todos' (all) roles.

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

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

Provides an explicit use case: 'Use para descobrir qual o role_id de um Gerente ou Vendedor.' This tells an agent when to call the tool, even though it does not explicitly mention get_role_by_id as an alternative.

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 provided, the description carries the burden of indicating that this is a read-oriented lookup rather than a mutation. The verb 'Busca' clearly communicates retrieval of details, which is the core behavioral trait. It does not detail error behavior or authorization, but for a simple get-by-id tool this is acceptable.

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 Portuguese sentence conveys the essential purpose and scope without any filler. Every word contributes meaning.

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 straightforward get-by-id tool, the description plus a fully documented schema provides enough to invoke it correctly. The main omission is not explicitly relating this tool to the sibling get_salesbots listing tool or mentioning the role of client_slug in the description, but the schema covers that.

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

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

The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description reinforces that the ID is the lookup key but does not add meaning beyond the schema.

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

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

The description clearly states the action ('Busca os detalhes'), the specific resource ('um Salesbot específico'), and the lookup method ('usando o ID'). This distinguishes it from the sibling tool get_salesbots, which is a plural listing tool.

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

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

The description implies this should be used when fetching a single Salesbot by ID, and 'específico' hints at contrast with listing. However, it does not explicitly mention when to use get_salesbots instead or provide any when-not-to-use 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 of behavioral disclosure. It only states that it fetches a list of Salesbots and gives no information about pagination behavior, read-only safety, authentication needs, or possible error conditions.

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

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

The description is a single clear sentence with no filler. The verb and resource are front-loaded, and every word contributes to the basic purpose.

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

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

For a tool with no output schema, no annotations, and only 33% schema parameter coverage, the description is too thin. It does not mention pagination defaults, the required client_slug usage, or how this tool relates to get_salesbot_by_id, leaving an agent without enough context to invoke it with confidence.

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 33%, and the description adds no parameter-level meaning. It does not explain page, limit, or how client_slug relates to the account context beyond what the schema already states, so it fails to compensate for the large documentation gap.

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 ('Busca') and resource ('lista de Salesbots') and conveys that this tool fetches the collection of Salesbots for the Kommo account. It is clearly a list operation and is distinguishable from the singular get_salesbot_by_id sibling, though it does not explicitly contrast itself with that sibling.

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 tool versus alternatives like get_salesbot_by_id, launch_salesbot, or stop_salesbot. A listing use case is implied, but there are no exclusions, alternatives, or contextual 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 provided, the description carries the full behavioral burden. It correctly indicates a read-only search operation, but it does not disclose additional behavioral traits such as pagination, ordering, or the default entity_type behavior when the parameter is omitted. The mention of 'existentes na conta' adds some context but remains thin.

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

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

The description is a single, front-loaded sentence that names the action, resource, and scope with no redundant words. Every word earns its place.

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

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

For a simple list tool with no output schema, the description is adequate but not complete. It lacks any indication of return value shape, default behavior, or broader usage context, though the schema fills in the default for entity_type. An agent could call it correctly but would be guessing at the output format.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only vaguely references the entity concept and does not add meaningful detail about client_slug or entity_type beyond what the schema already provides.

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

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

The description clearly states the verb 'Busca' (searches/lists), the resource 'tags (etiquetas)', and the scope 'na conta para uma entidade'. This makes the tool's purpose explicit and distinguishes it from sibling tools, none of which are tag-specific.

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

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

The description implies when to use the tool by stating it lists existing tags for an entity, but it does not provide explicit guidance about when to prefer this over alternatives or any prerequisites. Since no sibling tool handles tags, the lack of exclusions is acceptable, but the absence of any 'use this when...' phrasing keeps it at a minimum viable level.

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 provided, the description carries the full burden of behavioral disclosure. It conveys a read-oriented list operation and some filtering behavior, but it does not mention pagination, default limits, response shape, or any other operational traits. The 'etc.' also leaves important behavior unspecified.

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

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

The description is a single concise sentence with the main purpose front-loaded. It is not bloated, though the trailing 'etc.' adds vagueness without substance.

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

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

For a tool with six parameters, no annotations, and no output schema, the description is incomplete. It omits the required client_slug context, pagination behavior, return format, and any guidance on how this relates to task management siblings like complete_task or update_task.

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 67%, so the schema already documents most parameters. The description adds a concrete example (entity_type=leads) and paraphrases is_completed, but it adds no meaning for page, limit, or client_slug, and does not compensate for the undocumented pagination parameters.

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

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

The description clearly states a specific action ('Busca uma lista de tarefas') and a specific resource ('na Kommo CRM'), and it distinguishes this tool from sibling tools like create_task, update_task, and get_leads by focusing on listing tasks. The mention of filtering by lead and completion state adds further clarity about its 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 description implies usage through its verb 'Busca' and filter examples, but it does not explicitly state when to prefer this tool over related alternatives such as get_notes or create_task. It gives context about filtering by lead and completion status, but no exclusions or alternative routing.

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, yet it only states that the tool fetches a list, implying read-only behavior. It does not disclose pagination behavior, the client-scoping implied by the required client_slug, or anything about the response, even though no output schema exists.

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

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

A single front-loaded sentence with no wasted words. The parenthetical example adds meaning by grounding what 'templates' refers to, and every element earns its place.

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

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

With no annotations and no output schema, the description is the only behavioral source, but it stops at purpose. It omits pagination semantics, why client_slug is required, and what the return value looks like — gaps that matter for a list tool an agent must invoke correctly.

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

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

Schema description coverage is only 33% (client_slug), and page/limit have no descriptions in the schema. The tool description mentions none of the three parameters, so it fails to compensate for the coverage gap — an agent is left to infer that results are client-scoped and paginated.

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 ('Busca') and resource ('lista de modelos de chat (templates)'), and clarifies the domain with the example of approved WhatsApp messages (waba). The resource is distinct from siblings like create_template, update_template, and delete_template, though it does not explicitly contrast with other list-getters such as get_catalogs.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites beyond what the schema's required field implies. The tool name and description make the purpose obvious, but an agent gets no help deciding between get_templates and related listing tools like get_catalogs.

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 provided, the description carries the burden of behavior disclosure. It clarifies that the operation is a read/retrieval action and previews the return fields, which is helpful. However, it does not disclose error behavior, missing-ID handling, authentication needs, or whether any filtering is applied via client_slug.

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, clearly front-loaded sentence that states the action, the target, and illustrative return fields. Every part contributes meaning, and there is no redundant or filler 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 a simple two-parameter get-by-ID tool, the description is largely sufficient: it names the lookup key and illustrates the output. The lack of an output schema and absence of error-handling notes are minor gaps given the tool's low 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%, so the baseline is 3. The description only reinforces that user_id is the lookup key and gives return-field examples; it does not explain the role of client_slug 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?

The description uses a specific verb ('Retorna' / returns) and a specific resource ('um usuário específico pelo seu ID'), which clearly distinguishes this tool from the plural get_users sibling. It also gives concrete return-field examples (email, nome, role_id), removing any ambiguity about what the tool does.

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 makes clear that this tool is for fetching one specific user by ID, so an agent can infer the appropriate use case. It does not explicitly mention when to prefer get_users or other alternatives, but the singular-by-ID framing provides clear context without needing an exclusion clause.

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 carry the behavioral disclosure burden. It states that the tool returns a list of users, which implies a read-only operation, and mentions account scope. However, it does not disclose pagination behavior, response structure, or any access-related requirements, leaving some ambiguity for a no-annotation context.

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

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

The description is short and front-loaded: the first clause states exactly what the tool returns, and the second clause gives a practical use case. Every word earns its place, with no redundant or vague filler.

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

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

For a simple list tool with no output schema and no annotations, the description provides the essential purpose and a key use case, while the schema covers parameter details. Still, it lacks explicit return-value details, pagination semantics, and guidance about alternative retrieval methods, so it is adequate but not fully complete.

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

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

All three parameters have schema descriptions, giving 100% schema description coverage, so the baseline is 3. The description adds slight semantic value by linking user IDs to responsible_user_id, but it does not elaborate on client_slug, page, or limit beyond what the schema already provides.

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: 'Retorna a lista de usuários configurados na conta.' It clearly identifies the tool as returning all account users, which distinguishes it from siblings like get_user_by_id, add_users, and get_roles. The added use case for finding responsible_user_id further clarifies its purpose.

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

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

The description gives clear context on when this tool is useful: to find IDs of lead responsible users. It does not explicitly mention when to use alternatives such as get_user_by_id for a single user, but the intended scenario is clear enough for an agent to select this tool appropriately.

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 provided, the description carries the full burden of behavioral disclosure. It conveys that the tool lists webhooks, but does not mention pagination behavior, limit constraints, required client_slug, rate limits, or expected response structure. The read-only nature is implied by 'Lista' but not explicitly disclosed.

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

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

The description is a single clear, front-loaded sentence with no wasted words. It is appropriately concise, though it could have used the available space to add parameter or usage guidance without becoming verbose.

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

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

For a simple listing tool with three parameters, no output schema, and no annotations, the description is too sparse. It identifies the resource and account context but omits pagination behavior, the required client_slug, and what the response will contain. An agent would need to infer too much before calling the tool correctly.

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

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

Schema description coverage is only 33%: only client_slug has a description. The tool description adds slight context by tying the operation to the 'Kommo account', which hints at client_slug's role, but it provides no meaning for the page or limit parameters. The description is insufficient to compensate for the schema's gaps.

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

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

The description uses a specific verb and resource: 'Lista os webhooks configurados na conta Kommo' meaning 'Lists the webhooks configured in the Kommo account.' This clearly identifies the operation as a read-only listing and distinguishes it from sibling mutating tools like create_webhook and delete_webhook.

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 tool versus alternatives. It does not mention create_webhook, delete_webhook, or any condition that would make this tool preferable. The usage context is only implicit from the tool name and description.

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 provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention side effects (e.g., that the bot may start sending messages), prerequisites, reversibility, idempotency, or how to stop the bot afterward. For a mutation-like tool 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?

The description is a single concise sentence with no filler. It front-loads the action and target, and every word adds meaning. It is appropriately sized for the straightforward purpose it serves.

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

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

Despite complete schema coverage, the description omits any behavioral or usage context for a tool that launches an external process. With no annotations and no output schema, the agent is left without information about expected return values, side effects, or post-launch lifecycle. The complexity of a launch action demands more than this one-line description.

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 tool description adds no parameter-specific meaning beyond the schema descriptions, which already explain bot_id, entity_id, entity_type, and client_slug. It neither improves nor degrades parameter clarity.

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 ('Inicia' = launches/starts) and names the resource ('Salesbot') as well as the target scope (a specific Lead or Contact). This clearly distinguishes it from sibling tools like get_salesbots, get_salesbot_by_id, and stop_salesbot, which retrieve or stop bots rather than start 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?

The description clearly implies when to use this tool: when you need to start a Salesbot for a particular Lead or Contact. It does not explicitly mention alternatives or exclusions, but the verb 'Inicia' and sibling names make the context unambiguous. It lacks an explicit 'use when/use instead' statement, so it doesn't reach a 5.

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 for behavioral disclosure. 'Vincula' indicates a mutation, but the description does not disclose side effects, reversibility, duplicate-link behavior, permissions, or return value. This is a significant gap for a mutation tool with no annotation support.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the second sentence provides a concrete, useful example. Every word contributes value.

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

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

For a simple linking operation, the purpose and parameter semantics are sufficiently covered, and the example reduces ambiguity about entity direction. However, there is no output schema or return-value explanation, and no behavioral context such as effects or error conditions, so completeness is only minimum-viable.

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 schema already explains the base vs. attached entity relationship. The example reinforces that meaning but does not add substantive new semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Vincula duas entidades') and gives a concrete example that defines the direction of the link. It is distinct enough from sibling tools like create_lead or update_contact, though it does not explicitly name or differentiate from 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?

Usage is implied: if you need to associate two entities, this is the tool. The classic example suggests one realistic scenario, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. It is adequate but not explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not describe side effects (e.g., whether the bot stops immediately, if it can be restarted, if it affects ongoing processes), permission requirements, or what the response contains. Moreover, the description actively misleads by suggesting execution rather than stopping, making the behavioral expectation incorrect.

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

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

The description is a single short sentence, which is concise in length, but it is under-specified and ambiguous. It lacks essential information about the operation (stop vs. execution) and could be considered more of a fragment than a helpful summary. The brevity does not compensate for the lack of clarity.

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

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

For a tool that performs a potentially destructive action (stopping a Salesbot), with no annotations, no output schema, and a misleading description, the description is completely inadequate. It provides neither operational details nor any context about the entity or bot lifecycle, making it impossible for an agent to use it correctly.

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

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

The input schema provides descriptions for 3 of 4 parameters (bot_id, entity_id, client_slug), with entity_type having an enum and default but no textual description. The tool description adds no additional meaning to parameters, relying entirely on the schema. Since schema coverage is 75% and the schema descriptions are relatively clear, a baseline of 3 is appropriate, though the description does not enhance parameter understanding.

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

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

The description 'Para a execução de um Salesbot para uma entidade específica' translates to 'For the execution of a Salesbot for a specific entity', which directly contradicts the tool name 'stop_salesbot' (a stop operation). It does not state the action of stopping; it implies execution. This is misleading and fails to convey the tool's actual purpose.

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

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

No guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or situations where this tool should be chosen over other Salesbot-related tools like launch_salesbot. The description only vaguely mentions 'for a specific entity' without explaining the context of stopping.

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 provided, the description carries the full burden of behavioral disclosure. It indicates a batch mutation, but it does not disclose partial-failure behavior, merge vs overwrite semantics, idempotency, permissions, or response expectations.

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

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

The description is a single concise sentence with no filler. It front-loads the action, scope, and example while remaining easy to parse.

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

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

The complete schema covers parameter semantics, and the description conveys the core batch-update scope. However, for a mutation tool with no annotations and no output schema, it lacks important context about batch behavior, error handling, and return values, making it only minimally 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%, and every parameter including nested fields has a description. The description only adds the 'em lote' context, which aligns with the elements array, 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 action ('Atualiza elementos... em lote') applied to a specific resource ('dentro de um catálogo específico') and even gives an example ('ex: produtos'). This clearly distinguishes it from sibling tools like get_catalog_elements and create_catalog_elements.

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 about when to use this tool versus create_catalog_elements or get_catalog_elements. It also does not mention prerequisites such as needing existing element IDs, though the schema hints at this.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'updates an existing company' without explaining whether the update is partial or full replacement, which fields are affected, whether it is reversible, or what response the agent should expect.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. However, it is quite sparse given the tool's four parameters and absence of annotations, so it is concise but near the edge of 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?

With no annotations, no output schema, and four parameters, the description does not provide enough context for an agent to call the tool confidently. It omits required identifier semantics, updatable field behavior, and return value expectations.

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

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

Schema description coverage is 50%, covering only id and client_slug. The description adds nothing about the parameters; name and custom_fields_values remain undocumented in both schema and description. The description does not compensate for the missing parameter context.

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

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

The description clearly states the operation ('Atualiza' = updates) and the resource ('uma empresa existente' = an existing company). It distinguishes the tool from create_company by emphasizing 'existing', though it does not name the 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?

No guidance is given about when to use this tool versus alternatives such as create_company or get_companies. The word 'existente' implies the company must already exist, but the description does not state prerequisites, exclusions, or typical use cases.

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 only states that the tool updates an existing contact, without explaining whether it performs a partial update, what happens to unspecified fields, whether custom_fields_values are merged or replaced, or any authentication/permission requirements. The mutation intent is clear, but the behavioral context is minimal.

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

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

The description is a single short sentence with zero filler or redundancy. It communicates the core operation immediately and contains no wasted words.

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

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

Given the tool has 5 parameters, no output schema, no annotations, and low schema coverage, the description is far too sparse. An agent is left without critical information about which fields can be updated, the semantics of custom_fields_values, potential side effects, or what the response contains. It is minimally sufficient to identify the intended action but not to invoke the tool safely or correctly.

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

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

Schema description coverage is only 40%, and the description adds no parameter-level meaning whatsoever. It does not explain what values are expected, how custom_fields_values behaves, or which parameters are optional. With low schema coverage, the description needed to compensate but entirely fails to do so.

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: 'Atualiza um contato existente' (updates an existing contact). It clearly identifies the object as a contact and signals that the operation targets an existing record, distinguishing it from create_contact. However, it does not mention any scope, fields, or distinguishing details beyond the resource type.

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

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

Usage is implied: use this tool when an existing contact needs to be modified, as opposed to creating a new contact. But there is no explicit guidance about when to prefer this tool over alternatives, no exclusions, and no mention of prerequisites or side effects.

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 only says 'updates an existing custom field,' which confirms mutation but does not explain whether updates are partial or full, what side effects occur, whether authorization is required, or what the response looks like. 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?

The description is a single short sentence with no filler or redundant detail. It is efficient and front-loaded, though it sacrifices explanatory content for brevity. Still, conciseness itself is done well.

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 five parameters, no annotations, and no output schema, the description is too minimal to give the agent a complete picture. It does not mention which fields can be changed, that id and client_slug are required, or what happens after a successful update. The schema fills in some gaps, but the overall definition remains incomplete for safe and correct invocation.

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

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

The description adds no parameter-level meaning beyond what the schema already provides. Schema coverage is 60%, so id, name, and client_slug have descriptions, but group_id is undocumented and entity_type only has an enum/default without explanation; the description does not compensate for that gap or clarify which fields are actually updatable.

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

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

The description states a clear action ('Atualiza') and a specific resource ('um campo customizado existente'), making it obvious this tool updates an existing custom field rather than creating, deleting, or fetching one. It does not explicitly name sibling tools to differentiate itself, but the verb and 'existente' already separate it from create_custom_field, get_custom_field, and delete_custom_field.

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 tool versus create_custom_field, get_custom_field_by_id, or delete_custom_field. It also does not mention prerequisites such as the custom field needing to already exist or the need to provide a client_slug. The word 'existente' weakly implies it is for existing fields, but no explicit use-case or alternative routing is 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 disclosure burden. It only says the tool updates an existing group; it does not disclose side effects, permissions, reversibility, impacts on contained fields, or failure behavior.

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

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

The description is a single efficient sentence with no filler. The parenthetical clarifies what a 'grupo de campos' is, and the word 'existente' adds meaningful scope without extra length.

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

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

With five parameters, no annotations, no output schema, and no usage guidance, the description is too sparse to fully support tool selection and invocation. Most context must be inferred from the schema and sibling tool names.

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 80%, and the schema already documents most parameters. The description adds no extra insight into parameter semantics beyond what the schema provides, 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 clearly states a specific action ('Atualiza') and resource ('um grupo de campos (aba/seção) existente'), and the 'existing' qualifier distinguishes it from creation and deletion tools. It also clarifies that the group is a tab/section, which separates it from custom field tools.

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention related tools like update_custom_field or create_custom_field_group, and no conditions or exclusions 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 bears the full burden of explaining behavior. It communicates that this is a mutation (update) and names typical effects, but it does not disclose whether updates are partial or full replacements, whether changes are reversible, what permissions are required, or what happens to fields that are not supplied.

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 the main action front-loaded and the second sentence giving practical context. There is no filler or repetition of schema details.

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

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

For a tool with 8 parameters, no annotations, and no output schema, the description is too thin. It omits how to provide tags inside _embedded, the structure of custom_fields_values items, whether pipeline_id and status_id must be sent together, and what the API returns after an update.

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 8 parameters. The description adds a rough semantic grouping ('mover o lead de funil ou etapa, adicionar tags ou atualizar campos'), but it does not clarify the nested structure of _embedded or custom_fields_values, so it provides no more than a baseline supplement to 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 opens with a specific verb and resource: 'Atualiza um lead existente no Kommo CRM' (updates an existing lead). It also lists concrete use cases (moving pipeline/stage, adding tags, updating fields), which makes the tool distinguishable from create_lead and update_contact.

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

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

The description gives clear context for when to use the tool by stating it is commonly used for funnel/stage moves, tag additions, and field updates. It does not explicitly contrast with create_lead or other update tools, but the phrase 'lead existente' implies the tool is for existing records rather than creation.

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 only states that the tool updates name or properties, but does not mention side effects, idempotency, error behavior, or any constraints. 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?

The description is a single concise sentence that front-loads the verb and object. There is no wasted text, making it efficient for quick comprehension.

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

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

With 5 parameters, no annotations, and no output schema, the description is too sparse. It does not specify which parameters are updatable beyond 'name or properties', does not explain required vs optional fields, or describe expected behavior on success/failure. An agent needs more detail to call the tool correctly and 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 only 40% (only id and client_slug have descriptions). The tool description does not compensate by explaining the other parameters (name, sort, is_main). It mentions 'name or properties' but does not map to specific parameters or clarify their meaning or optionality. This leaves agents guessing about the non-required fields.

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

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

The description clearly states the action (update) and the resource (pipeline), and specifies that it updates the name or properties of an existing pipeline. This distinguishes it from sibling tools like create_pipeline and delete_pipeline, so an agent can easily identify its purpose.

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

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

The description implies when to use the tool (for modifying existing pipelines) by using the word 'existing', and the sibling list makes the update-vs-create distinction evident. However, there is no explicit guidance on when not to use it or mention of alternatives. The context is clear enough for a basic agent, but not explicit.

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