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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses the multi-step side-effect behavior: creating the card via POST, optionally registering hours via PUT qtd_horas, and self-assigning via PATCH. It also states the plain-text constraint for descriptions and the Concluído column fallback — real behavioral context that annotations alone would not provide.

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 four sentences, purpose-first with no marketing filler; the flow line earns its place because it explains ordering that the schema can't. It could trim the bits that repeat schema documentation, but overall it is compact and well-structured.

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 12 parameters, no output schema, and light annotations, the description covers purpose, flow, defaults, and input constraints well. But it does not mention the response shape, error behavior, how the agent can confirm success or retrieve the created card's id — a significant gap given the tool has no output schema to fill that in.

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 baseline per the rubric is 3, and the description adds some value by sequencing how parameters are used (qtd_horas landed later via PUT, assign-to-me via PATCH) and by aggregating the name-based lookup rule. However, parts of it (plain-text description, Concluído default, names instead of IDs) duplicate what the schema already says.

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: 'Cria um card no B-Ticket para registrar o que foi feito e as horas trabalhadas' — verb (cria), resource (card), and clear scope (register work + hours). It clearly distinguishes itself from the read-only siblings (bticket_list_* and bticket_whoami), being the only creation tool in the set.

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

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

The description gives concrete usage context: it accepts project/board/column by name ('não precisa do id'), explains the execution flow (POST, optional PUT, PATCH), and specifies the column default when qtd_horas is set. It does not explicitly name alternatives or exclusions (e.g., 'use bticket_list_columns first to find ids'), so it falls short of a full 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the specific GET endpoints, reinforcing the read-only nature, but it doesn't go beyond that to explain any additional behavioral nuances.

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, compact sentence with no filler. It front-loads the action and resource, then lists the exact endpoints, making it easy to scan and understand.

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 dashboard stats tool with one well-documented parameter and strong annotations, the description is largely complete. It names both accessed endpoints and the schema covers the include_team_daily_report parameter, leaving little ambiguity.

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 parameter is already well-documented by its own description. The tool description adds minimal semantic value beyond the schema, 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 clearly states the action ('Lê') and the resource ('estatísticas e o relatório diário da equipe'), making it obvious what the tool does. It also names the two specific endpoints, which disambiguates it from sibling list tools.

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

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

The description implies the tool is for dashboard statistics and daily team reports, which gives context, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. It is adequate but not proactively helpful.

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

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

The annotations already establish read-only and idempotent behavior; the description adds the HTTP GET endpoint and notes that board id fields are UUIDs, which are useful beyond the annotation defaults. It does not cover pagination or response shape, but those are not critical for this simple list 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 compact, front-loaded with the action and object, and only includes two meaningful details: the endpoint and the id type. No filler 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?

Given the tool has no parameters and is a simple authenticated read-only list operation, the description covers the core semantics well. Minor omissions such as response shape or pagination exist, but annotations and endpoint information make the definition sufficiently complete 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?

The tool has no parameters, so the schema already provides complete coverage. The description adds one relevant semantic detail (id is a UUID), which is helpful for downstream usage, though not strictly parameter-related.

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 names the exact resource ('quadros/boards'), adds the scope ('acessíveis ao usuário autenticado') and the endpoint ('GET'), making it unmistakable which operation is performed. It is clearly distinguished from sibling tools that list tickets, projects, or other resources.

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

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

The description provides clear context by specifying that this returns the boards accessible to the authenticated user, so an agent knows it is for fetching available boards. It does not explicitly discuss alternatives or when not to use it, but the resource and scope are sufficiently explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral detail: the default result excludes concluded cards, the endpoint changes with the concluidos flag, and filters combine with AND while array filters combine with OR. No contradiction with annotations.

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

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

Three sentences deliver the essential guidance with no filler: the core action, the default endpoint behavior, the concluidos variant, and the filter combination rule are all front-loaded and compact.

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 operation with 16 parameters, the description covers the most decision-relevant behavior: default scope, the concluded-cards switch, and filter semantics. It does not describe the response shape or pagination behavior, but the schema already documents page/per_page and the annotations cover safety.

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 parameters are already documented, but the description adds meaning beyond the schema by explaining cross-parameter behavior: filters combine with AND and array-valued filters (membro_id, etiqueta_id, coluna_id) combine with OR. It also maps concluidos=true to a different endpoint, which is not inferable from the parameter description alone.

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 cards de um quadro B-Ticket') and further narrows the scope by naming the default endpoint for active columns and the concluded-cards endpoint. This makes it clearly distinguishable from sibling tools like bticket_list_tickets and bticket_list_my_open_cards.

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 states when to use the default active-columns call versus setting concluidos=true to hit the concluded-cards endpoint. It also explains how filters compose, giving clear operational context, though it does not explicitly name sibling alternatives or exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the GET endpoint and sample column names but no further behavioral details such as ordering, empty results, or response structure, which is acceptable given the safety 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 conveys the verb, resource, endpoint, and concrete examples with no filler. 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?

The tool is low-complexity with one documented parameter, strong annotations, and no output schema. The description's examples partly fill the missing return-value gap, though it could state the exact response shape (e.g., array of column names) explicitly.

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% for the single required parameter board_uuid ('UUID do quadro'). The description does not add parameter detail beyond that, so the schema carries the parameter semantics and baseline 3 applies.

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

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

The description states the specific verb ('Lista'), the resource ('colunas de um quadro'), and gives the HTTP endpoint plus representative examples. This clearly distinguishes the tool from sibling board/ticket/card/list tools.

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

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

The description makes the operation unambiguous but does not state when to prefer it over siblings such as bticket_list_boards or bticket_list_cards, nor does it mention exclusions. Usage 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?

Annotations already mark the operation as read-only, idempotent, and non-destructive, so the description needs to add operational behavior. It does by revealing two execution modes, the server-side API calls, and the performance limitation (pesado, limited to 8 boards) — valuable context not available in 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?

Three short sentences front-load the purpose, then provide usage preference, internal flow, and a warning. Every sentence earns its place and there is no 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 read-only listing tool with optional parameters and no output schema, the description covers purpose, preferred invocation, fallback behavior, and limitations. Nothing essential for correct invocation is missing; return shape is implied by 'cards' and the card endpoint.

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 busca, atrasado, and board_uuid (75% coverage). The description adds meaning by explaining why board_uuid matters, including the exact GET /api/user resolution and the aggregation fallback, which goes beyond the schema's single recommendation line.

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 this is a shortcut to the authenticated user's open cards ('cards abertos do usuário autenticado') and explains the server resolves member_id via /api/user, which is a specific scoped resource. That distinguishes it from the generic sibling bticket_list_cards.

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 gives explicit preference: pass board_uuid to avoid aggregation, and warns not to use aggregation if not needed ('Não use agregação se não precisar'). It also discloses the heavy cost and 8-board limit of the fallback, so an agent can decide when this tool/parameter path is appropriate.

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; the description adds value by specifying the exact GET endpoints and the conditional behavior of include_unread_count. It does not cover pagination, rate limits, or authentication, but for a read-only list tool the main behavioral traits are 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 one fua sentence that front-loads the primary action, then adds the optional call condition. Every clause adds information, and there is no filler or duplication of the parameter descriptions.

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 tool with two optional parameters and no output schema, the description manages both endpoints and the default behavior. It does not describe the return payload shape beyond 'notificações' and 'contagem', but that is largely inferable from the endpoints; the simplicity of the tool makes this complete enough.

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

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

Schema coverage is 100% and both parameters already have descriptions. The description enriches include_unread_count by explaining the live trigger: it is included when include_unread_count is not false, i.e. by default or true, making the parameter's effective behavior clearer than the schema's simple 'true (default)' note.

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 the action, resource, endpoint, and optional second call: 'Lista as últimas notificações (GET /api/notificacoes)' and 'inclui a contagem de não lidas (GET /api/notificacoes/contagem)'. It clearly distinguishes this list tool from siblings that target other resources (boards, tickets, cards, projects).

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 vs. alternatives, no prerequisites, and no exclusions. The purpose is self-evident, but the description does not say e.g. 'use this to check notifications or unread counts' or point to a sibling alternative if a different level of detail is needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe read operation. Beyond that, the description adds two important behavioral details: the optional 'busca' filter is applied locally (not via server-side query), and pagination parameters are available. This additional context is valuable and not redundant with annotations.

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

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

The description is two sentences, front-loading the main verb and use case. It wastes no words, and the inline endpoint reference is efficient. It could arguably gain a point by being even more compact, but the structure is clean and readable.

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, the description covers the purpose, filters, and use case. It does not mention pagination behavior or any result ordering, but given the readOnlyHint and the simplicity of the tool, this is sufficient for an agent to call it correctly. The absence of output schema is acceptable for a list endpoint.

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%, with 'busca' and 'cliente_id' already described in the schema. The description repeats the 'busca' filter's meaning but adds that it's applied locally, which is useful. However, 'page' and 'per_page' are undocumented in both schema and description, relying on their obvious semantics. Since coverage is above the low threshold, a 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 starts with a clear action-verb phrase 'Lista projetos' and ties it to the underlying endpoint (GET /api/projetos). It also states the primary use case (resolving project name before creating a card), which distinguishes it from sibling list tools like bticket_list_cards or bticket_list_boards.

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 advises to use this tool before creating a card, giving a clear context. While it doesn't mention when not to use it or name alternatives directly, the stated pre-card creation use case implicitly guides the agent away from other list tools. This is adequate guidance, not explicit exclusions.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile. The description adds meaningful behavioral context: the result set is limited to tickets visible to the authenticated user and includes both own and shared-board tickets. No contradiction with annotations.

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

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

The description is compact and front-loaded with the verb and resource. The phrase 'conforme a API' adds little actionable value, but overall the text is efficient and well-structured.

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, parameterless, read-only list operation, the description covers the endpoint, scope, and inclusion criteria sufficiently. There is no output schema, so return-shape or pagination details could be added, but the tool's simplicity and strong annotations make this 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?

The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The relevant semantic content is the scope of the returned ticket set, which the description does cover.

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 ('Lista' tickets), the resource ('tickets'), and the scope ('visíveis ao usuário autenticado', including own and shared board tickets). It is broadly distinguishable from sibling list tools by resource, though it does not explicitly contrast with potentially overlapping tools like bticket_list_my_open_cards.

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 this tool over the sibling list tools, nor any exclusions or conditions. The description only restates what the tool does; usage context is left entirely to the agent's inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is covered. The description adds value beyond annotations by specifying exactly which user attributes are returned (id, nome, e-mail, papéis, flags de notificações) and the endpoint, giving the agent a clear picture of the response content without needing to inspect output schemas.

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, dense sentence delivers all necessary information: the action, the endpoint, and the returned fields. No wasted words, and the core purpose is front-loaded. Excellent structure for quick consumption.

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 tool with no output schema, the description is complete: it identifies the operation, the resource, and the response contents. Annotations cover safety aspects, and there are no missing details an agent would need to call this 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?

With zero parameters, the baseline is 4. The description doesn't need to explain parameters; it correctly focuses on what the tool does and returns. It adds meaningful context about the response fields, which is sufficient for a no-input 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 'Retorna' (returns) and the resource 'usuário autenticado' (authenticated user), including the specific endpoint GET /api/user. It also lists the fields returned (id, name, email, roles, notification flags), which is precise and distinguishes it from sibling list/create tools that target other entities.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. However, the purpose is self-evident (fetching current user identity) and there is no sibling that performs a similar function, so usage is implied. Lacks explicit exclusions or context, which keeps it at an average score.

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