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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value beyond them by revealing the evo-core proxy backing and the downstream constraint on the returned IDs. Return shape and pagination behavior are still undisclosed.

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

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

Two short sentences with no filler; the resource scope comes first and the exclusion follows immediately. Every clause carries information an agent would otherwise have to guess.

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-param, read-only list tool with full schema coverage and annotations, the definition covers what is needed to select it. The remaining gap is what an agent record contains and whether pagination continues until an empty page, but neither blocks 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 page and limit are already fully documented in the schema, including the note about keeping the same limit across pages. The description adds nothing about parameters, which is acceptable at full coverage but not a contribution.

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

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

States a specific verb and resource ("Lista agentes de IA") plus the backing endpoint, and immediately bounds scope by declaring what it does NOT list (human users). That negative statement is what separates it from contacts_list and the other contact-oriented siblings.

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

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

Explicitly rules out a use case — the returned IDs cannot be used to assign attendants — which steers the agent away from a plausible mistake. It stops short of naming the sibling tool the agent should use instead for human users, so the routing 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds a small operational hint about re-checking notes when a prior result was uncertain, but says nothing about error handling or what an uncertain result actually looks like.

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, purpose first and the optional-parameter tip second; nothing is wasted. The brevity borders on under-specification rather than verbosity, which is the lesser flaw here.

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 getter with a fully described schema and rich annotations, the essentials are present. Gaps remain around the paginated notes behavior (page/limit interaction with include_notes) and the failure modes behind "resultado incerto", which an agent would want when deciding to retry.

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

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

Schema coverage is 100%, with page, limit, contact_id and include_notes all documented in the schema itself. The description only touches include_notes and largely restates the schema's "para conferência" wording, adding no syntax or constraint detail 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?

"Consulta um contato" states a specific verb (fetch) and resource (contact), clearly a single-record retrieval as opposed to contacts_list or contacts_search. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the plural 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 second sentence gives one concrete usage rule: set include_notes=true to verify notes after an uncertain result. There is no guidance on when to pick contact_get over contacts_search or contacts_list, so routing between siblings is only implied by the singular resource.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description's only extra claim, "com paginação", merely restates the schema parameters and adds nothing about result ordering, consistency across pages, or rate limits — which matters for an openWorld listing 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 short sentence with no waste, and the resource is front-loaded. It is however terse to the point of under-specification rather than genuinely 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 simple two-parameter list tool with rich annotations and full schema coverage, the essentials are present. But the description never indicates what a contact record looks like, whether ordering is stable across pages, or how this relates to contacts_search, leaving the agent without guidance on a tool that is openWorld.

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 both page and limit have detailed constraints and defaults, so the schema carries the burden. The description only says pagination exists and adds no format or strategy detail beyond that, making baseline 3 appropriate.

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

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

States a specific verb and resource ("Lista contatos do CRM") plus the pagination behavior, so the agent knows exactly what the tool returns. It does not distinguish itself from the sibling contacts_search, which is the main ambiguity here.

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 and no mention of the obvious alternative contacts_search, which is present in the sibling list. The agent must infer whether to enumerate with this tool or filter with search.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds that matching spans multiple fields (name, email, phone, identifier), which is useful retrieval context, but says nothing about match semantics (partial/case-insensitive) or result ordering.

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. It is appropriately sized for the amount of information conveyed, though it stops short of anything beyond the bare 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 simple three-parameter search with full schema coverage and rich annotations, the essentials are present. Missing are the matching semantics and whether results are paginated in a way that requires iterating with page/limit, which would help an agent call it correctly.

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

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

Schema description coverage is 100%, with q, page and limit all documented including defaults and ranges, so the baseline is 3. The description's field list loosely maps to q but adds no syntax or format detail beyond the schema.

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

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

States a specific verb ("Busca") and resource ("contatos") plus the fields searched, so the agent knows exactly what the tool does. It does not explicitly distinguish itself from the sibling contacts_list, leaving the differentiation to inference.

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 mention of "por nome, e-mail, telefone ou identificador" implies this is the tool for keyword lookup, but there is no explicit when-to-use guidance or statement of when contacts_list would be preferable. Usage is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds nothing beyond 'get details' — no statement of what fields are returned, what happens when the conversation_id is unknown, or whether external CRM calls are made — so it contributes almost no behavioral value over the annotations.

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

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

A single front-loaded sentence with no filler. It is efficient, though it borders on under-specification rather than true concision given the tool's retrieval semantics.

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 (one required param, full schema coverage, rich annotations, no output schema), so the minimal description is close to adequate. However, it never clarifies what 'detalhes' comprise or the error behavior for an invalid ID, leaving a modest completeness gap.

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

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

With 100% schema description coverage, the single conversation_id parameter is already documented in the schema including format (UUID or numeric ID as text) and pattern/length constraints. The description adds no additional meaning to the parameter, so baseline 3 applies.

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

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

States a specific verb ('Consulta') plus resource ('detalhes de uma conversa'), which makes it clearly a single-conversation fetch as opposed to siblings like conversations_list or messages_list. It does not name those siblings explicitly, so the differentiation is inferred rather than stated.

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

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

The description offers no when-to-use guidance, no prerequisites, and no mention of the alternative tools (conversations_list, messages_list, contact_get) that an agent would need to choose between. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds only the fact that filtering and pagination apply, without disclosing notable behavior such as the default status of 'open' or ordering of results.

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

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

A single short, front-loaded sentence with no filler. It is efficient, though efficiency here comes at the cost of detail rather than being paired with it.

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

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

For a read-only list tool with full schema coverage and no output schema, the description is minimally adequate. It omits one behavior an agent would benefit from knowing: that results default to status 'open' and are paginated at 20 per page unless overridden.

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 carries its own description, enum and bounds, so the description's generic 'filtros e paginação' adds no meaning 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?

States a specific verb and resource ('Lista conversas') plus the axes of control ('filtros e paginação'), which clearly distinguishes it from conversation_get or messages_list at a glance. It stops short of explicitly naming when to prefer a 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?

Mentioning 'filtros e paginação' implies the tool is for browsing/enumerating conversations, but there is no explicit when-to-use or when-not (e.g. use conversation_get for a single thread, or contacts_search when starting from a contact). Guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds two useful behavioral facts beyond them: results are permission-scoped ('acessíveis') and the response is paginated. It stops short of describing ordering, total counts, or page-exhaustion behavior, so a 3 is right.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification given the tool has room for one more clarifying clause.

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

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

The tool is simple: zero required params, full schema coverage, rich annotations, no output schema. Against that low bar the description is adequate, but it never indicates what an inbox record contains or how results are ordered, leaving the agent to discover the shape of the response by 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 description coverage is 100% and both parameters (page, limit) are fully documented with defaults and bounds in the schema. The description's 'com paginação' merely echoes that, adding no syntax or interaction detail (e.g., what happens when page exceeds the last page). Baseline 3 applies.

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

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

States a specific verb and resource ('Lista caixas de entrada') plus the scope qualifier 'acessíveis' and the pagination behavior. The resource is distinct from every sibling (contacts, agents, conversations, messages), so an agent can route on the noun alone, though no sibling is named explicitly.

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

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

There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. 'Acessíveis' hints at permission scoping but the agent must infer what makes an inbox accessible and what to do when the list is empty or truncated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: chronological ordering, cursor-based paging, and the default behavior when no cursor is supplied. It does not say where the cursor tokens come from, which is the one behavioral 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?

Three short sentences, front-loaded with the resource and ordering, then the paging constraint, then the default. No filler. Slightly undercut by the mismatched cursor token names, which cost a point 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?

There is no output schema, so the description must carry return-shape weight. It implies cursors exist in the response but never states what the response contains (message objects, cursor fields, has-more indicator), leaving an agent to discover that empirically.

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 baseline is 3; the description earns an extra point by explaining the cursor progression model that ties before/after/page together. However, it refers to 'next_before' and 'next_after', names that do not match any schema parameter ('before'/'after'), which introduces avoidable ambiguity about what to pass.

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

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

States a specific verb and resource ('Lista mensagens') plus the ordering guarantee ('ordem cronológica'), which is genuinely useful information. It does not name or differentiate against siblings (conversations_list, conversation_get), though the resource name makes the distinction largely self-evident.

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?

Gives clear operational context: the upstream is cursor-based, not page-based, and without a cursor it returns the most recent messages. What is missing is guidance on when to reach for this versus conversation_get or conversations_list, but the when-to-use for listing messages is implied well 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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the return is a 'quadro completo' including stages and items, which is useful since there's no output schema, but it does not elaborate on payload structure, size, or pagination.

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 that leads with the verb and resource. The trailing 'o upstream devolve o quadro completo' slightly echoes 'com suas etapas e itens' but still adds return-shape context, so waste is minimal.

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

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

For a simple single-parameter read tool with annotations covering safety and 100% schema coverage, the description is adequate: it conveys purpose, scope, and that the return is a complete board. No output schema exists, and the description gives enough to call it correctly.

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

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

Schema description coverage is 100% and the single pipeline_id parameter is well documented with pattern and format notes. The description adds nothing about the parameter beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (consulta) and resource (pipeline) and clarifies scope by noting it includes 'etapas e itens', which implicitly distinguishes it from pipelines_list and pipeline_items_list. It does not explicitly name those siblings, so differentiation is inferred rather than stated.

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

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

Usage is only implied through 'o upstream devolve o quadro completo', suggesting this is for fetching one pipeline's full board rather than listing. There is no explicit when-to-use/when-not or named alternative, leaving the agent to infer selection logic against siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely non-obvious context: pagination is applied locally because the upstream returns the entire collection, which explains why paging is consistent and why large pipelines may be costly. It does not describe the shape or size of returned items.

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 zero filler; the purpose comes first and the non-obvious pagination caveat follows. Every sentence carries information the agent would otherwise have to discover empirically.

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 five-parameter list tool with full schema coverage, annotations and no output schema, the definition is adequate. It still leaves open how items are ordered, what fields each item carries, and how this differs from sibling tools like pipeline_get, which an agent selecting among eleven siblings would benefit from knowing.

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 page, limit, status, stage_id and pipeline_id are all documented in the schema. The description only adds that the pagination parameters operate locally rather than upstream, which is a marginal but real addition. Baseline 3 applies.

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

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

States a specific verb and resource ("Lista itens de um pipeline"), which tells an agent exactly what is returned. It does not differentiate from pipeline_get or pipelines_list, so the agent must infer that this is the collection-level tool for pipeline items.

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

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

Usage is only implied: the required pipeline_id and the pagination note make it evident this is the way to enumerate items of a given pipeline. There is no explicit statement of when to prefer pipeline_get or pipelines_list instead, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two useful constraints: results are limited to accessible pipelines (permission scoping) and exclude items in the current upstream. It says nothing about result size, ordering, or pagination behavior beyond what the schema already documents.

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

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

Two short sentences with no filler, and the core purpose is front-loaded before the scope caveat. Every sentence carries information.

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

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

For a three-optional-parameter read-only list with full schema coverage and rich annotations, the description covers what is returned (pipelines plus their stages) and what is omitted. Only result ordering and the effect of include_inactive are left undescribed, which is a minor gap.

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

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

Schema description coverage is 100%, with page, limit and include_inactive all documented in the schema itself, so the baseline is 3. The description adds no semantics about include_inactive or pagination strategy, but the 'accessible pipelines' phrasing does imply the visibility scope the list obeys.

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

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

The description names a specific verb and resource ('Lista pipelines acessíveis e suas etapas'), and the second sentence scopes the content by excluding items in the current upstream. It implicitly separates itself from pipeline_items_list, but never names pipeline_get or other siblings to sharpen the distinction.

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

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

Usage is only implied: an agent can infer this is the enumeration entry point before drilling into pipeline_get or pipeline_items_list. There is no explicit guidance on when to pick this over those siblings, nor on prerequisites or when to set include_inactive.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered by structured data. The description adds one genuinely useful behavioral fact, that pagination is local (client-side), which explains the schema's instruction to keep the same limit across pages; the note about subtasks overlaps the hierarchy parameter description. It does not describe ordering, total counts, or cost of fetching large hierarchies.

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 resource and pagination scope front-loaded and no filler. Brevity is appropriate, though the second sentence is largely redundant with the schema's hierarchy description.

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 six parameters, the description should carry more weight than two sentences: it says nothing about ordering, what a task record contains, or how local pagination interacts with filtering. Annotations cover the read-only safety profile and the schema covers every parameter, so it is minimally viable, but thin for a hierarchy-aware listing 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%, with page, limit, status and hierarchy all documented in the schema, so the baseline is 3. The description's only parameter-relevant content, that subtasks appear in the hierarchy, restates what the hierarchy enum already says rather than adding new 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?

States a specific verb and resource in Portuguese: lists the tasks of a pipeline item, with pagination, and notes that subtasks are included in the hierarchy. An agent can tell this apart from siblings like pipeline_items_list or pipeline_get. It stops short of an explicit contrast with those siblings, but the resource 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?

Usage is only implied by the description: it is a read-only listing of tasks for a given pipeline item. There is no explicit when-to-use/when-not, no guidance on choosing hierarchy='root' vs 'all' (the schema supplies the mechanics but not the intent), and no note about when to prefer another sibling tool.

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