Server Quality Checklist

Tool Scores

• listar_projetosC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it is sparse. It claims to list 'all projects' while the schema has a status filter with a default of 'ativo', which contradicts the 'todos' wording—potentially misleading an agent about the default scope. It also fails to mention any side effects, permissions, pagination, or response format, which are critical for a tool without annotations.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no redundant words or filler. It front-loads the action and resource, making it easy to parse. Every word earns its place, and there is no bloat.

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

  Completeness2/5

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

  For a simple listing tool with an optional parameter and no output schema, the description is minimally functional but leaves gaps. The mismatch between 'todos' and the default 'ativo' filter is a notable incompleteness, and there is no guidance on expected output or pagination. While the simplicity reduces the burden, the description could benefit from clarifying the default behavior and any restrictions.

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

  Parameters3/5

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

  The schema already fully describes the single parameter (status) with 100% coverage, giving the agent sufficient detail on filtering. The description adds no further semantic value, but since the schema covers it, the baseline of 3 is appropriate. However, it does not clarify the interaction between 'todos' and the default filter value.

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

  Purpose4/5

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

  The description clearly states the action (listing projects) and the resource (projects in the Task Management system). It uses a specific verb and resource, making the primary purpose unambiguous. However, it does not explicitly distinguish this tool from sibling tools like 'listar_demandas_ativas' or 'listar_sprints', though the resource type is distinct enough that confusion is unlikely.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions (e.g., when to use 'obter_contexto_projeto' instead). No comparison with sibling tools is made, leaving the agent without direction on selection.

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

• atualizar_subtarefaB
  3.1/5.0
  Behavior2/5

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

  No annotations are supplied, so the description must disclose behavioral traits, but it only states that it updates fields. It does not clarify whether it performs a partial update (only changing provided fields) or a full replacement, nor does it mention effects on unspecified fields, validation rules, or potential side effects like modifying timestamps.

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

  Conciseness4/5

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

  The description is a single, complete sentence that is front-loaded with the action and resource, then lists the updatable fields. It is efficient and free of fluff, though it could be slightly more explicit about usage constraints within the same sentence.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is too minimal. It fails to explain the update semantics (partial vs. full), whether at least one field must be provided, or what the response contains. Given the tool's moderate complexity (5 parameters), it should provide more operational context to avoid ambiguous usage.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all five parameters, each with a clear description of its purpose and format. The tool description lists the same fields without adding new meaning beyond the schema, so it adds minimal value on top of the structured definitions.

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

  Purpose5/5

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

  The description clearly states the verb 'Atualiza' (updates) and the resource 'subtarefa' (subtask), and enumerates the specific fields that can be updated (título, descrição, status, data limite). This distinguishes it from the sibling tool 'criar_subtarefa' which creates a new subtask.

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

  Usage Guidelines2/5

  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 like 'criar_subtarefa'. The description implies it is for updating an existing subtask but does not state any prerequisites, such as requiring the subtask to already exist or the need to specify at least one field to update.

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

• listar_demandas_ativasB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It says 'lista' (lists) but does not explicitly state whether it's read-only, whether it filters by default (only open/in-progress) or returns all statuses when no filter is applied, or any pagination/sorting behavior. The mismatch between the description's 'abertas ou em andamento' and the schema's full status enum adds ambiguity.

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

  Conciseness5/5

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

  The description is a single sentence that conveys the core purpose and a contextual use case without any filler. It is concise and front-loaded with the main action.

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

  Completeness2/5

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

  Given that there is no output schema and no annotations, the description should provide more context about what the tool returns (e.g., list of demand objects, key fields) and any default behavior. The description mentions a use case but does not explain the response format, filtering defaults, or relationship to subtask linking. It is under-specified for a tool with 3 parameters and no structured output.

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

  Parameters3/5

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

  Schema coverage is 100% with all three parameters (projeto_id, status, responsavel_id) having descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.

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

  Purpose4/5

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

  The description clearly states it lists demands (verb+resource) for a project. It distinguishes itself from siblings like listar_projetos and obter_detalhes_demanda by focusing on the collection of demands. However, the phrase 'abertas ou em andamento' is slightly misleading since the schema's status enum includes all statuses (e.g., concluida, cancelada), so the description under-specifies the actual scope.

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

  Usage Guidelines3/5

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

  The description mentions a use case (análise de contexto e vínculo de subtarefas), which implies when to use it, but it does not explicitly state when NOT to use it or compare with alternative tools like obter_detalhes_demanda or obter_contexto_projeto. The guidance is implicit, not explicit.

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

• obter_detalhes_demandaB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions inclusive details (subtarefas e responsáveis) but does not disclose any behavioral traits such as read-only nature, performance, or side effects. For a read-like operation, it lacks explicit safety confirmation.

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

  Conciseness4/5

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

  Single sentence, clear and front-loaded with the purpose. No wasted words, though it could arguably mention alternatives for conciseness's sake.

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

  Completeness3/5

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

  Tool is moderately simple (1 parameter, no output schema). Description covers the purpose and inclusion of subtasks, but without annotations or additional behavioral info, completeness is adequate but not rich. No mention of return format or error conditions, but simple enough.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already explains the 'demanda_id' parameter. The description repeats that it consults a specific demand but adds no extra semantic detail beyond what the schema provides. Baseline of 3 applies.

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

  Purpose4/5

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

  The description clearly states that the tool retrieves full details of a specific demand, including subtasks and those responsible. It uses a specific verb ('consulta') and resource ('demanda específica'), and distinguishes from siblings like 'listar_demandas_ativas' by focusing on a single item.

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

  Usage Guidelines3/5

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

  The description implies usage for viewing details of one demand, but does not explicitly state when to use it versus alternatives like 'listar_demandas_ativas' (for listing) or 'obter_contexto_projeto' (for project context). No exclusions or alternatives are mentioned.

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

• sincronizar_fila_offlineB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility. It discloses that the tool forces sending of all offline items, but omits critical details: what happens to local copies after sync, whether the operation is blocking or asynchronous, failure handling, or if it clears the queue. The impact of this mutation is not clarified.

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

  Conciseness5/5

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

  The description is a single, concise sentence that efficiently communicates the action and scope. It is front-loaded with the verb and resource, has no fluff, and every word contributes meaning.

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

  Completeness3/5

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

  Given the tool's simplicity (no params, no output schema), the description is mostly adequate but has gaps: it does not address edge cases like network failures, duplication of sends, or the effect on local data after successful sync. These are relevant for a mutation tool and would improve completeness.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema covers everything. The description adds no parameter information, but that is unnecessary. According to the baseline for 0-parameter tools, a 4 is appropriate; no compensation is required.

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

  Purpose4/5

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

  The description clearly states the verb ('Força o envio') and resource ('todas as demandas e subtarefas'), specifying their origin (generated locally while offline). It distinguishes this from sibling tools like criar_demanda or listar_demandas_ativas by focusing on the sync action, though it doesn't explicitly name alternatives.

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

  Usage Guidelines3/5

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

  The description implies the intended use case (syncing offline-generated items after reconnection), but does not explicitly state when to use it versus other tools, nor provide exclusions or prerequisites like checking connection status via verificar_status_conexao. Guidance is implicit from the context.

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

• criar_demandaA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It adds valuable insights about event suppression for certain project types and offline queue handling, which are not visible elsewhere. However, it lacks details on side effects, required permissions, or error behaviors, leaving some transparency gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is exceptionally concise—two sentences that convey the core function and two key behavioral nuances without extraneous fluff. It is front-loaded with the main action and includes only essential details.

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

  Completeness3/5

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

  Given the tool's complexity (15 parameters, 6 required, no output schema), the description is somewhat sparse. It covers the primary behavior and important edge cases (offline queue, event suppression) but does not explain return values, success/failure states, or how the offline queue integrates with the sibling synchronize tool. While not fatal, it could be more complete.

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

  Parameters3/5

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

  The schema description coverage is 100%, and each parameter already has a descriptive text. The description adds no additional parameter-level context beyond what the schema provides, so the baseline of 3 is appropriate. It does not explain parameter interrelationships or provide extra usage hints.

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

  Purpose5/5

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

  The description clearly states the tool's purpose ('Registra uma nova demanda') with a specific verb and resource, differentiating it from sibling tools like 'criar_subtarefa' by explicitly scoping to demands in the task management system. It also includes behavioral context (event suppression, offline queue) that goes beyond a simple statement.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool versus alternatives such as 'criar_subtarefa' or other creation tools. The description implies its use for creating demands but does not state exclusions, conditions, or when other tools might be more appropriate.

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

• associar_demanda_sprintA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals a critical constraint (rejection if the demand is already in another sprint), which is valuable. However, it does not mention other side effects, permissions, or success/failure response details, leaving gaps for a mutation tool.

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

  Conciseness5/5

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

  Two concise sentences front-load the purpose and key constraint with no filler or redundant phrasing. Every word contributes to the meaning, making it highly efficient.

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

  Completeness4/5

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

  For a simple association tool with two parameters and no output schema, the description covers the essential purpose and a critical rejection rule. It lacks details on return values or error codes, but the functionality is straightforward, and the description is sufficiently complete for an agent to call it correctly.

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

  Parameters3/5

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

  The input schema already provides descriptions for both parameters (sprint_id and demanda_id) with 100% coverage. The description adds no extra semantic detail beyond the schema, so it meets the baseline for high coverage but does not enrich parameter understanding.

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

  Purpose5/5

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

  The description clearly states the tool's function: associating an existing demand to a sprint, using a specific verb (Associa) and a specific resource pair (demanda, sprint). It is distinct from all sibling tools, which operate on creating demands, listing sprints, etc., 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.

  Usage Guidelines3/5

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

  The description implies its usage (associate a demand to a sprint) but does not explicitly compare it to alternatives or state when not to use it. Siblings like criar_demanda or listar_sprints are not referenced, so an agent receives no explicit guidance on selecting this tool over others.

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

• verificar_status_conexaoA
  3.8/5.0
  Behavior3/5

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

  Sem anotações, a descrição carrega o ônus de explicar o comportamento. Ela indica que é uma operação de leitura ('Informa'), mas não declara explicitamente que não modifica dados nem tem efeitos colaterais. Para uma ferramenta de status, é aceitável, mas poderia reforçar a ausência de mutação. Não contradiz o esquema.

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

  Conciseness5/5

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

  Uma única frase, direta e sem excessos, lista os três itens de saída principais. Carga informativa alta com zero desperdício.

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

  Completeness4/5

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

  A descrição cobre os três aspectos do status (conexão, token, fila offline). Sem saída estruturada e sem anotações, essa é uma informação suficiente para um tool de verificação simples. Faltaria apenas uma menção explícita a ser read-only para completar totalmente o contexto.

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

  Parameters4/5

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

  A ferramenta não possui parâmetros, então a cobertura do esquema é 100% trivial. A descrição não precisa explicar parâmetros inexistentes. Pontuação base para 0 parâmetros é 4.

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

  Purpose5/5

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

  A descrição informa claramente a finalidade: reportar estado da conexão, validade do token e quantidade de itens na fila offline. O verbo 'Informa' e o recurso específico (estado da conexão, token, fila) diferenciam de todos os irmãos, que tratam de projetos, demandas, sprints e sincronização.

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

  Usage Guidelines2/5

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

  Não há orientação explícita sobre quando usar esta ferramenta em relação às alternativas. A descrição não menciona, por exemplo, que deve ser chamada antes de sincronizar a fila offline ou para diagnosticar falhas de conexão. Apenas descreve o que faz, sem contexto de uso.

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

• obter_contexto_projetoA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden for transparency. It discloses the detection mechanism (.gestaotarefas.json or Git) and the conditional disabled behavior, but does not specify what happens when disabled (e.g., returns an error, null, or a flag) or whether any side effects occur. It appears read-only but this is not explicit.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the purpose and key details. Every word contributes no fluff or redundancy, making it an excellent example of efficient specification.

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

  Completeness4/5

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

  For a simple tool with one optional parameter and no output schema, the description covers the essential behavior. However, it omits explicit information about the return value or what occurs when the MCP is disabled, which would be helpful for an agent to act on the result.

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

  Parameters3/5

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

  The schema already provides 100% coverage for the only parameter (diretorio_path) with a clear description. The tool description does not add any additional semantics beyond what the schema states, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: it identifies the active project based on the working directory and checks whether the MCP should operate. This specific verb+resource combination (identifies project, checks operation) distinguishes it from sibling tools like listar_projetos or criar_demanda, which handle project/task management.

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

  Usage Guidelines4/5

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

  The description implies usage context: use it to determine the active project and whether MCP is enabled (e.g., Prefeitura projects are disabled). It doesn't explicitly compare to alternatives, but the context is clear enough for an agent to infer when this tool is appropriate.

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

• criar_subtarefaA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses two non-obvious behaviors: the tool is disabled for Prefeitura/external projects and, when offline, it stores the operation in a local queue. It does not detail return values or error behavior, but it offers meaningful transparency beyond the schema.

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

  Conciseness5/5

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

  The description is two compact sentences, front-loaded with the main purpose and followed only by high-value behavioral constraints. There is no redundant or filler content.

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

  Completeness4/5

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

  Given the full schema coverage, the description provides enough context to select and invoke the tool: purpose, project exclusion, and offline queuing behavior. The main gap is the lack of detail about return output, errors, or queue synchronization semantics, but those are not required for a basic correct invocation.

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

  Parameters3/5

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

  The input schema has 100% description coverage for its 6 parameters. The prose adds no significant parameter-level meaning beyond the schema; the offline/client_id behavior is already present in the demanda_id schema description.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: "Cria uma subtarefa técnica vinculada a uma demanda existente." This clearly distinguishes it from criar_demanda and from atualizar_subtarefa, making the tool's purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides a clear when-not-to-use context: "Desativado para projetos da Prefeitura/externos." It also explains the offline workflow, but it does not explicitly name an alternative sibling tool, so it stops short of a 5.

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

• listar_sprintsA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses the visibility filter and sorting order, which are non-obvious behavioral details. It does not explicitly state that this is a read-only operation, but the verb 'Lista' strongly implies it.

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

  Conciseness5/5

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

  A single, front-loaded sentence that conveys the action, resource, scope, and order without any filler. Every word earns its place.

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

  Completeness5/5

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

  For a zero-parameter, read-only listing tool with no output schema, this description is complete: it states what is listed, which items are included, and how they are ordered. No additional context is necessary for selection or invocation.

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

  Parameters4/5

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

  The tool has 0 parameters, so the schema provides complete coverage and there is nothing for the description to add. The baseline of 4 applies because the description does not need to explain parameter semantics.

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

  Purpose5/5

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

  The description uses a specific verb ('Lista') and resource ('sprints'), adds a meaningful scope ('visíveis'), and specifies ordering ('da mais recente para a mais antiga'). This clearly distinguishes it from sibling tools like listar_projetos and listar_demandas_ativas.

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

  Usage Guidelines3/5

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

  The purpose implies use when listing sprints, and the ordering/visibility details add context, but the description does not explicitly state when to prefer this tool over alternatives or provide any exclusions. It relies on the tool's name and obvious purpose.

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