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

Annotations indicate non-read-only and non-destructive behavior. The description adds that the comment appears as a new message in the timeline visible to all, which aligns with annotations. No contradictions. It provides useful context beyond annotations.

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

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

The description is short and front-loaded with the main action. Headers for parameters improve readability. Minor redundancy with 'Parâmetros obrigatórios:' but overall 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?

The description explains the action and visibility but lacks information about return values or potential errors. Given the simplicity (2 params, no output schema), it is adequate but could be more complete by mentioning what the tool returns.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the effect (added to timeline) and reinforcing the use of ekyte_list_tasks for task_id. This goes beyond schema descriptions.

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

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

The description clearly states the action ('Adiciona um comentário') and the resource ('em uma tarefa existente no Ekyte'). It distinguishes from sibling tools like ekyte_create_task and ekyte_complete_task by focusing on adding comments.

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

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

The description explains that the comment is added to the task timeline and visible to all with access. It also notes mandatory parameters and how to find task_id using ekyte_list_tasks. However, it does not explicitly state when to use this tool versus alternatives, though the context makes it clear.

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

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

The description adds context beyond annotations by specifying the resulting state (CONCLUÍDA) and confirming it is a state change. Annotations include destructiveHint: true, which aligns; no contradiction.

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 with three short paragraphs, each containing essential information. No unnecessary words 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 simple mutation tool with one parameter and no output schema, the description effectively covers purpose, usage guidance, behavioral notes, and parameter reference. It is 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?

There is only one parameter (task_id), and the schema already provides full description. The description repeats the schema's guidance to use ekyte_list_tasks. Schema coverage is 100%, so no additional value beyond 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 clearly states the action (marcar como concluída) and the resource (tarefa no Ekyte), including the internal status (situation=30). It distinguishes from sibling tools like ekyte_get_task and ekyte_toggle_flow_phase.

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 advises to confirm with the user before executing and suggests using ekyte_get_task first to check status. It provides good context for use, though it doesn't explicitly list when not to use.

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

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

Annotations indicate a non-read-only, non-destructive, non-idempotent write operation. The description adds context about a dynamic additional payload, which aids understanding of the tool's behavior. No contradictions 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?

A single, clear sentence that efficiently conveys the tool's purpose. It is front-loaded with the action and avoids unnecessary words, earning its place with no 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?

Given the lack of an output schema, the description should ideally mention return values. It also omits details about error handling, authentication requirements, or the behavior of endpoint_override. While concise, it leaves gaps for a complex tool with 7 parameters and a dynamic payload.

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 well-documented. The description adds value by emphasizing the dynamic nature of additional_payload and hinting that extra fields may be required by Ekyte, going beyond the schema's static descriptions.

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

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

The description clearly states 'Cria um novo projeto' (creates a new project), specifying the verb and resource. However, it does not explicitly distinguish from sibling tools like ekyte_create_task, relying on the tool name for 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?

No guidance is provided on when to use this tool versus alternatives (e.g., ekyte_create_task for tasks). The description lacks contextual recommendations or exclusions, making it less helpful for an AI agent deciding which tool to invoke.

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 indicate destructiveHint=true (creating a task) and readOnlyHint=false. The description adds context on mode usage and prerequisites, but does not disclose other behaviors like auth requirements or rate limits. 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 well-structured with clear sections (modes, recommended flow, important note) and is appropriately sized for the tool's complexity. Minor verbosity could be trimmed.

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 11 parameters, two operating modes, and required prerequisite data, the description comprehensively covers usage context, mode selection, and pre-conditions. No output schema, but the description adequately sets 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 100%, but the description adds value by explaining inter-parameter dependencies (e.g., ignoring executor_id when phases[] is provided) and mode-specific parameter usage beyond individual schema descriptions.

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

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

The description clearly states it creates a new task in Ekyte, supporting two distinct modes (single phase and multi-phase). It uses a specific verb ('cria') and resource ('tarefa'), and differentiates from sibling tools like ekyte_update_task by detailing mode-specific behavior.

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 a recommended 5-step flow before calling and an important note to confirm with user. It distinguishes between single and multi-phase modes, but does not explicitly 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?

Annotations indicate destructiveHint=true, so the description's 'Cria' is consistent. The description adds a behavioral note 'IMPORTANTE: Sempre confirme os dados com o usuário antes de executar', which goes beyond annotations. No other traits like side effects or permissions are mentioned, but the core behavior is clear.

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 with two short paragraphs and a bullet list. Key information is front-loaded (purpose), and every sentence earns its place (usage comparison, required params, user confirmation note). No redundant text.

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

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

Given 8 parameters and no output schema, the description covers the required parameters and provides usage context. It lacks mention of optional parameters and return value but is adequate for a tool with comprehensive schema descriptions. The 'IMPORTANTE' note adds safety guidance.

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 baseline is 3. The description lists required parameters and their purpose (e.g., 'use ekyte_list_workspaces'), which adds some value but does not significantly extend the detailed schema descriptions already present. Optional parameters like 'comment' and 'non_productive' are omitted from the description.

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

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

The description clearly states 'Cria um apontamento de horas avulso (sem vincular a uma tarefa específica)', which uses a specific verb ('Cria'), identifies the resource ('apontamento de horas'), and distinguishes from the sibling 'ekyte_create_time_entry_with_task' by emphasizing 'without task'.

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 context by comparing to a UI button and lists required parameters. It includes an important instruction to confirm data with the user. However, it does not explicitly state when to use this tool over its sibling or alternatives, though the name and context hint at 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?

The description reveals that end_time must be after start_time and that duration is auto-calculated. Annotations indicate destructiveHint=true (creation is destructive) and readOnlyHint=false, which align with the description. No contradictions. It adds value beyond 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 concise, well-structured with paragraphs and bullet points, and each sentence adds value. No redundant or irrelevant 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?

Given no output schema, the description thoroughly covers input behavior, mandatory parameters, constraints (time order), and includes a user confirmation directive. It is complete for a creation tool with good annotations.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by listing required parameters with format examples (AAAA-MM-DD, HH:MM) and referencing discovery tools for IDs. This exceeds schema documentation but does not fully explain optional parameters like 'manual_time'.

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 it creates a time entry linked to a specific task ('Cria um apontamento de horas vinculado a uma tarefa específica'), with a specific verb and resource. It also distinguishes from the sibling tool 'ekyte_create_time_entry_without_task' by emphasizing the task binding.

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 explicit usage guidelines, including the equivalence to manual entry, required parameter steps, and a warning to confirm data with the user. However, it does not explicitly list when this tool should be avoided or compare to alternatives like the without-task variant.

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?

Discloses behavior beyond annotations: it is a soft delete via status change and is irreversible. Annotations already set destructiveHint=true, idempotentHint=true, and readOnlyHint=false; the description adds valuable context without contradiction.

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 succinct: it states the purpose, lists key parameters, and includes an important irreversible note. Every sentence serves a purpose, with 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?

Fully covers all necessary aspects for a simple delete tool: purpose, required parameters with discovery hints, and an important behavioral warning. No output schema is expected, so completeness is high given the tool's 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?

Input schema has 100% coverage with descriptions for both parameters. The description adds guidance on how to discover the time_entry_id using ekyte_list_time_entries, which goes beyond schema details. Baseline is 3 due to high coverage, but the extra discovery tip earns a 4.

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 'Remove um apontamento de horas no Ekyte (soft delete via mudança de status)', specifying the verb (remove), resource (time entry), and method (soft delete). This distinguishes it from sibling tools like ekyte_list_time_entries or ekyte_create_time_entry.

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 warns that the action cannot be undone, instructs to confirm with the user before executing, and advises using ekyte_list_time_entries to verify the correct entry. This provides clear when-to-use and 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?

Annotations already declare readOnly, idempotent, non-destructive. Description adds return field summary (title, description, status, etc.), which is valuable beyond annotations. No contradiction.

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 paragraphs, front-loaded with key purpose and prerequisite. Every sentence adds value. No redundancies.

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?

No output schema, but description lists key return fields (title, description, status, assignee, workspace, type, dates, times). For a get-details tool, this is sufficient. Sibling tools are distinct.

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 baseline is 3. Description repeats the prerequisite for task_id but adds no new information beyond schema. Response_format is not mentioned, but schema covers 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 title and description clearly state the tool retrieves complete task details by ID. It distinguishes from siblings like ekyte_list_tasks (which lists tasks) and ekyte_update_task (which modifies).

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 instructs to use ekyte_list_tasks first to find the ID. Implicitly suggests this tool is for reading details after listing. Could more directly compare to alternatives, but it's adequate.

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. The description adds context about the usage workflow and the return fields (id, nome, sequencial, ativo), but does not discuss pagination, limits, or other behavioral details. 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 concise (under 10 sentences), well-structured with purpose first, then context, usage instructions, and return info. 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?

Despite no output schema, the description specifies return fields and explains the tool's role in the workflow creation process. Annotations cover safety, so the description is sufficient for an agent to use 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 clear descriptions for both parameters. The description does not add significant new meaning beyond the schema, though it reinforces the context of workflow_id. 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 it lists phases of a workflow, explains the relationship between task types, workflows, and phases, and distinguishes it from sibling tools by specifying its use case before creating a task. It mentions the return fields.

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 instructs to use this tool BEFORE creating a task, tells to first get workflow_id via ekyte_list_task_types, and then use this tool to find the phase_id. This provides clear when-to-use and how-to-use guidance with sibling tool references.

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

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

Annotations indicate readOnly, destructive false, idempotent, openWorld. Description adds useful behavioral details like filtering with is_planning and endpoint override, without contradicting annotations. No extra info on auth or rate limits needed.

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

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

Two sentences, front-loaded with main purpose, zero fluff. Every sentence adds 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?

Adequately covers the main functionality and key parameters. No output schema, but description hints at return format via response_format param. Lacks default ordering or pagination details, but schema covers page param.

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%, but description adds value beyond schema for key parameters: explains is_planning purpose and endpoint_override use case. Other params are well-described in 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 it lists projects from the company in Ekyte, with specific guidance on using is_planning and endpoint override. It distinguishes from sibling tools like ekyte_create_project by being a read operation.

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 clear context for using is_planning=1 to find projects with planned but inactive tasks, and mentions endpoint override. However, it does not explicitly compare with sibling list tools (e.g., ekyte_list_tasks) to guide when to use this vs others.

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

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

As anotações já indicam readonlyHint=true, destructiveHint=false, idempotentHint=true. A descrição não adiciona detalhes comportamentais além do propósito básico. A paginação (100 registros por página) está no esquema, não na descrição.

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

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

Duas frases diretas, sem redundância. A primeira frase estabelece a função principal, a segunda adiciona valor com um caso de uso específico.

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

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

A descrição é suficiente para uma ferramenta de listagem com esquema completo e anotações ricas. Faltam detalhes sobre o formato de retorno, mas isso é aceitável dado que não há esquema de saída.

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 esquema é 100%, então a linha de base é 3. A descrição não adiciona significado além do que está no esquema; os parâmetros search e status não são elaborados.

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?

Descreve claramente a ação (listar) e o recurso (tarefas de um projeto específico), diferenciando-se de irmãos como ekyte_list_tasks (que lista todas as tarefas). A menção de verificar 'tarefas planejadas mas não ativas' adiciona contexto específico.

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?

Fornece um caso de uso claro (verificar tarefas planejadas mas não ativas), mas não menciona explicitamente quando não usar ou alternativas como ekyte_get_task para tarefas individuais.

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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no extra behavioral context beyond what's in the schema and annotations, such as pagination details or authentication needs.

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 and front-loaded. It avoids unnecessary words, 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?

Given the tool has 4 parameters and no output schema, the description is too minimal. It does not mention pagination, search behavior, or response format options, relying entirely on schema descriptions.

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 baseline is 3. The description adds no additional meaning about parameters beyond what the schema provides (page, response_format, search, endpoint_override).

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 lists project templates for creating new projects, distinguishing it from sibling tools like ekyte_list_projects which lists actual 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?

No guidance on when to use this tool versus alternatives (e.g., ekyte_list_projects, ekyte_create_project). The description lacks context about prerequisites or when to search vs list all.

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, destructiveHint false, and idempotentHint true, so the description adds context about the returned fields (phase_id, executor, dates, etc.) and the factual nature of the data. No contradictions; the description adds moderate value beyond 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 concise: two sentences for purpose, one for usage guidance, and a bulleted differentiation. No unnecessary words, and key information is 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?

The tool is simple (list operation) with robust annotations and schema. The description explains what each returned phase includes (phase_id, sequential, name, executor, effort, dates), compensating for the lack of an output schema. All necessary context is provided.

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 100% coverage with descriptive parameter descriptions. The description additionally mentions that task_id can be discovered via ekyte_list_tasks, adding extra guidance. Since schema coverage is high, this exceeds 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 clearly states it lists all phases of a specific task, showing executor, dates, and estimated time per phase. It explicitly distinguishes itself from the sibling tool ekyte_list_phases by contrasting template vs actual phases.

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 advises using this tool before editing a phase with ekyte_update_phase, providing clear context for when to invoke it. It also differentiates from ekyte_list_phases, offering alternative usage guidance.

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

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

Annotations indicate safe read-only operation; description adds critical behavioral details: API does not paginate, MCP applies client-side pagination after filters. Also lists return fields. No contradictions.

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?

Description is well-structured with clear sections: purpose, filter types, pagination, tip, return fields. It is front-loaded and concise, though a bit long with repeated sentences about filter types. 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 12 parameters (all documented in schema), no output schema, and clear annotations, the description covers behavioral nuance (pagination, filter scope), cross-references to discover IDs, and return fields. It is comprehensive for an agent to use effectively.

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 baseline is 3. Description adds value by classifying filters as server-side vs client-side, providing example values (e.g., 'playbook' for search), and explaining pagination parameters. This goes beyond schema descriptions.

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

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

Description clearly states it lists tasks with optional filters, and the title 'Listar Tarefas do Ekyte' is specific. It distinguishes from sibling tools like ekyte_list_project_tasks by being company-wide and listing workspace filter. 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?

Explicit guidance on filtering by workspace_id to reduce volume, cross-references to ekyte_list_workspaces, and explains server-side vs client-side filter behavior. Also mentions default status filter. No explicit when-not-to-use but overall very 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?

Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral details: what is returned (id, nome, workflow_id) and the relationship between task-types and workflows. 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 concise with two front-loaded paragraphs. Every sentence adds value: main purpose, return fields, relationship, and tip. 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 no output schema, the description adequately tells what is returned (id, nome, workflow_id) and the workflow relationship. It also provides a hint about next steps, making it complete for a list tool with 4 parameters.

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% (all 4 parameters have descriptions). The description adds value: search filter is case-insensitive with an example, and pagination is client-side with 50 per page. This goes 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 tool lists all task types/templates and is used to discover task_type_id before creating tasks. It distinguishes from sibling tools like ekyte_list_phases by mentioning the relationship and providing a tip for subsequent use.

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 explicitly says to use it to find task_type_id before creating tasks, and provides a tip: after finding the task_type, use ekyte_list_phases with the corresponding workflow_id. This gives clear when-to-use and an alternative next step.

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 indicate read-only, non-destructive, idempotent, open-world. The description adds value by detailing client-side pagination (50 per page, fetches all then filters) and listing return fields, without contradicting 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 concise, well-structured, and front-loaded. It starts with the purpose, then lists required parameters, optional filters, pagination note, and return fields. Every sentence adds value with no 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 read-only list tool with 7 parameters (3 required) and no output schema, the description fully covers parameter semantics, pagination behavior, and return fields. It references sister tools for ID lookups, making it self-contained for an agent to execute 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 coverage is 100% with descriptions, but the description adds practical guidance: referencing ekyte_list_workspaces for workspace_id, ekyte_list_users for user_id, and explaining the date format. This cross-tool context is highly valuable beyond the schema 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 clearly states 'Lista apontamentos de horas no Ekyte para um workspace em um período', specifying the verb (list), resource (time entries), and scope (workspace, date range). It distinguishes from sibling tools that create, update, or delete entries.

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 outlines required parameters (workspace_id, date_from, date_to) and optional filters, plus clarifies client-side pagination. Although no alternative tools are mentioned for comparison, the usage context is clear and sufficient for an agent to understand when to call 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?

Annotations already declare the tool as read-only and idempotent. The description adds behavioral details: IDs are UUIDs, pagination is client-side (50 per page), and search is case-insensitive. This enriches the agent's understanding of behavior beyond 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 very concise (three short sentences) with front-loaded purpose and key usage tips. Every sentence adds value: purpose, search preference, return fields, UUID warning, and pagination. No unnecessary words.

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

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

Without an output schema, the description fully specifies the return fields (id, name, email) and pagination behavior. It covers all three optional parameters with usage guidance. The tool has moderate complexity, and the description leaves no gaps for an agent to understand its usage.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant context: search is case-insensitive with an example, page indicates client-side pagination with 50 per page, and response_format is described. This goes beyond the schema's bare descriptions.

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

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

The description clearly states 'Lista usuários/membros da empresa no Ekyte', specifying the action (list) and resource (users). It is distinct from sibling tools, which focus on tasks, projects, and time entries.

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 recommends preferring the 'search' parameter for quick lookups, providing explicit usage guidance. However, it does not explicitly mention when not to use this tool or compare with alternatives, though no alternative exists for listing users.

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 and idempotentHint. Description adds valuable behavioral context: client-side pagination (50 per page), typical total (600+), and search behavior. 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?

Very concise, uses bullet points and emoji for readability. Front-loads purpose and usage tips, every sentence adds value. 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?

Covers purpose, usage scenario, search optimization, pagination details, and return fields. No output schema but mentions what returns. Completeness is adequate for a read-only list 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 covers all parameters (100% coverage). Description enhances semantics with search example, case-insensitivity note, and pagination context beyond schema. Adds meaning beyond structured data.

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

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

Description clearly states it lists workspaces (clientes/projetos) and specifies return fields (id, nome, status). It also distinguishes from sibling list tools by focusing on workspaces.

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

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

Explicitly advises to prefer using the search parameter for efficiency and recommends using this tool before creating tasks or logging hours. Lacks explicit when-not-to-use but provides strong when-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?

Annotations include destructiveHint=true and idempotentHint=true, which are consistent with the tool's write behavior. The description adds valuable insights by explaining that the tool fetches the current state, modifies the 'active' field, and sends the full array via PUT. This goes beyond the annotations, but no output format is mentioned.

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 well-structured with a clear main action, bullet points for parameters, and a functional note. It is concise and front-loaded, but the bullet list could be slightly more compact without losing clarity. Overall 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?

Given no output schema, the description does not explain return values, but it adequately covers the input parameters and the internal behavior (PUT operation). Annotations provide safety hints. For a 5-param tool, this is sufficient, though a brief note on the response 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 schema already documents all parameters. The description adds some additional context, such as explaining the meaning of active and the optional nature of executor_id, but this does not significantly exceed the schema's own descriptions. Baseline 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 tool's purpose: to activate or deactivate a phase in a project task flow. The title 'Ativar ou Desativar Fase' and description use specific verbs and resources. It distinguishes from sibling tools like ekyte_list_task_flow_phases (which only lists) and ekyte_update_phase (which might update phase properties, not toggle).

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 using ekyte_list_task_flow_phases first to see available phases, and explains the active parameter (1=activate, 0=deactivate). However, it does not explicitly state when not to use this tool or mention alternatives for similar operations, such as updating a phase directly.

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

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

Annotations indicate destructiveHint=true and idempotentHint=true. The description confirms it modifies data, adds a warning to confirm with user, and specifies that it can change executor, dates, effort for any phase. 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 well-structured: a clear one-sentence summary, a use-case example, a numbered recommended flow, and a bullet list of optional fields. Every sentence adds value with no 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?

Given the tool has 7 parameters (2 required) and no output schema, the description covers purpose, preconditions (list phases first), and parameter roles. It does not explain the return value or error handling, but the annotations adequately convey mutability and safety considerations.

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%, but the description adds extra context: clarifies that project_id is needed only for project tasks, groups fields as optional, and reinforces the need to use ekyte_list_task_flow_phases to get phase_id. This adds 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 uses a specific verb ('Atualiza') and resource ('fase específica dentro de uma tarefa'), and distinguishes from siblings like ekyte_toggle_flow_phase by clarifying it can update ANY phase, not just the current 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?

Provides a recommended two-step flow: first list phases to get phase_id, then update. Also notes that at least one optional field is required. Explicitly says to confirm changes with user. Does not explicitly state when not to use this tool versus alternatives, but the flow provides clear 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?

Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that the tool uses JSON Patch, converts description to HTML, and emphasizes user confirmation. 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?

Well-structured: purpose first, then parameter list, then important note. Efficiently covers all necessary information for 10 parameters without redundancy. Slightly longer due to parameter explanations, but each sentence earns its place.

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

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

Given 10 parameters and no output schema, the description covers behavior, parameter details, usage guidelines, and a confirmation requirement. Complete enough for an agent to use correctly. Lacks return value description, but utility 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?

Schema coverage is 100% (baseline 3), but description adds value: maps priority_group to labels (35=Baixa, etc.), advises preference for priority_group over priority, and explains description conversion. Adds meaning beyond 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 tool updates top-level fields of an existing task (title, description, executor, dates, priority). It distinguishes from the sibling tool ekyte_update_phase for editing specific phases, making the purpose 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?

Explicitly provides when-to-use vs alternatives: 'Para editar executor/datas/esforço de uma FASE ESPECÍFICA não-atual, use ekyte_update_phase em vez deste.' Also instructs to confirm changes with the user before executing.

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