Server Quality Checklist

Tool Scores

• aprovar_ajusteA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses that it is a WRITE ACTION with audit, and explains that approval corrects the clock-in/out and records in the audit trail, sufficient behavioral context.

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

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the core purpose, and every sentence earns its place (purpose, usage condition, behavioral note).

  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 tool's simplicity (2 parameters, no annotations, output schema exists), the description adequately covers purpose, usage, inputs, and behavior, though output details are left to the schema.

  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 0%, but the description adds meaning by stating that ajuste_id comes from listar_ajustes_pendentes and that justificativa is required. However, it does not elaborate on formats or constraints.

  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 'Approve a pending time adjustment' with a specific verb and resource, distinguishing it from sibling tools like listar_ajustes_pendentes which lists adjustments.

  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 explicitly states 'Use only when the manager explicitly asks to approve an adjustment' and directs the user to listar_ajustes_pendentes to obtain the adjustment ID, providing clear 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.

• consultar_batidasA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description properly discloses important behaviors: accepts partial names ('Aceita nome parcial'), expects date format YYYY-MM-DD, and notes the data range (maio a julho de 2026). This adds value 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?

  Three sentences, each purposeful: purpose, usage scenarios, and technical details. No redundant or unnecessary information. Efficiently structured.

  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 three required parameters, no annotations, and an output schema present, the description adequately covers purpose, usage, parameter details, and data constraints. Lacks explanation of absence handling, but output schema likely covers return structure.

  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?

  Schema coverage is 0%, so description must compensate. It explains that 'nome_colaborador' accepts partial names, and date parameters use format YYYY-MM-DD within a specific period. This gives meaning to the three parameters beyond their schema titles.

  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 it consults time punches ('batidas de ponto') for a team member in a period, using specific verb 'Consulta'. This distinctly separates it from sibling tools like analytics_rh (HR analytics) or aprovar_ajuste (approve adjustments).

  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?

  Explicitly says 'Use para perguntas sobre horários, atrasos, horas extras ou batidas faltantes de uma pessoa específica', providing clear when-to-use context. It doesn't explicitly state when not to use, but the sibling tool names imply alternatives for other tasks.

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

• analytics_rhA
  4.5/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. Discloses constraints: SELECT only, no CTEs/semicolons/comments, and governance validation. Does not mention rate limits or authentication, but adds valuable behavioral context.

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

  Conciseness5/5

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

  Every sentence serves a purpose: action, usage, schema, constraints. No wasted words; front-loaded with the core function.

  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?

  Covers purpose, usage, SQL details, and constraints. Output schema exists, so return values need not be described. Could explicitly state no side effects, but overall complete for a SQL query tool.

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

  Parameters5/5

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

  Schema coverage is 0%, but description fully compensates by detailing the required SQL content, exact table and columns, and formatting constraints. Adds critical meaning beyond the generic schema title.

  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?

  Specific verb 'Executa' and resource 'consulta analítica SELECT no data warehouse (BigQuery)'. Clearly distinguishes from sibling tools like 'aprovar_ajuste' (approvals) and 'consultar_batidas' (time tracking).

  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?

  Explicit use cases for aggregate queries (horas extras, atrasos, batidas incompletas) and specifies the table and columns. Lacks explicit when-not-to-use or alternative pointers, but sibling context helps.

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

• consultar_politicaA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure. It states the tool returns literal excerpts with sources and instructs the agent to respond based on them citing the policy. It does not mention read-only behavior or authentication, but for a RAG search tool, the transparency is adequate.

  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 very concise: two sentences that cover purpose, usage, and return value. It is front-loaded with the main action and every sentence adds value. No redundancy.

  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?

  Given the tool has only one parameter and the output schema exists (though not shown), the description covers what the tool does, when to use it, and what the output contains. It is complete for a simple RAG query tool.

  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 input schema has one parameter 'pergunta' with no description (schema coverage 0%). The description compensates by indicating the parameter should be a question about HR rules and gives examples. While it doesn't detail syntax, it provides enough context for the parameter's purpose.

  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 searches for relevant excerpts from internal HR policies using RAG. It lists specific examples like tolerância de atraso and banco de horas, making the purpose concrete. The sibling tools (analytics_rh, aprovar_ajuste, etc.) are distinct, so there is no confusion.

  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 explicitly says 'Use para dúvidas sobre regras' and provides a list of example use cases. However, it does not explicitly state when not to use this tool or compare it directly to siblings, though the sibling names imply different functions.

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

• listar_ajustes_pendentesA
  4.5/5.0
  Behavior4/5

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

  Sem anotações, mas a descrição informa que retorna uma lista de ajustes pendentes (id, colaborador, data, etc.). Não menciona efeitos colaterais, mas é claramente uma leitura. Poderia ser mais explícito sobre não ser destrutivo.

  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?

  Duas frases, sem redundância. A primeira frase define o propósito, a segunda fornece contexto de uso e conteúdo do retorno. Front-loading perfeito.

  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?

  Para uma ferramenta simples e sem parâmetros, a descrição cobre o suficiente: o que faz, quando usar e o que retorna. A existência de output schema complementa.

  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?

  Nenhum parâmetro. A descrição não precisa adicionar informações sobre parâmetros, pois o schema já cobre 100%. Baseline 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?

  Descrição específica: 'Lista os ajustes de ponto aguardando aprovação da gestora'. Verbo claro ('Lista') e recurso definido. Distingue-se dos irmãos como 'aprovar_ajuste' e 'consultar_batidas'.

  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?

  Explicitamente diz quando usar: 'Use quando a gestora perguntar o que está pendente, o que precisa aprovar, ou pedir a fila de ajustes'. Falta contraste direto com alternativas, mas fica implícito.

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