Astrea (Aurum)

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying the activity types returned and the date format (AAAA-MM-DD), going beyond what annotations alone provide.

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

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

The description is compact and well-organized, with the resource stated upfront and actions laid out in a simple list. Including the por_cliente action adds a little extra length, but it earns its place by helping differentiate the sibling tool.

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

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

For a simple read-only two-parameter tool, the description provides the essential invocation details: date range, date format, and activity scope. It omits response shape and pagination, but without an output schema and with annotations covering safety, this is a minor gap.

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

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

With 0% schema description coverage, the description compensates by explaining that date_from and date_to define a date window in YYYY-MM-DD format. This is the core parameter meaning, though it does not clarify inclusivity or other edge cases.

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 identifies the resource as the office agenda in Astrea and enumerates the activity types included (hearings, events, deadlines, tasks). It explicitly states that the global action returns all activities in a date window, and the '[Flattened action: global]' marker distinguishes this tool from the por_cliente sibling.

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

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

The description contrasts global versus por_cliente, explaining that global returns all activities in a date range while por_cliente groups by client. This gives an agent enough context to decide which variant to use, though it stops short of explicitly stating 'use this when...'.

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 annotations já cobrem readOnlyHint/idempotentHint/destructiveHint; a descrição acrescenta que itens avulsos caem em '(sem cliente)' e que o agrupamento é via processo vinculado, além de especificar o formato de data. Isso enriquece o comportamento esperado sem contradizer as 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 descrição é organizada em definição, lista de ações e marcação flattened, mas repete o conteúdo das duas ações mesmo quando só por_cliente se aplica ao tool atual. Essa redundância é leve, porém poderia ser mais direta: 'Retorna a agenda por cliente (date_from/date_to em AAAA-MM-DD)'.

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?

Em um tool read-only de listagem com 2 params e sem output schema, a descrição cobre tipos de itens, agrupamento, janela de datas e buckets para itens avulsos. Faltam detalhes sobre ordenação, paginação ou estrutura do retorno, mas o essencial para uso correto está presente.

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?

Os params date_from/date_to têm 0% de cobertura no schema, então a descrição precisa compensar; ela informa que são uma janela de datas no formato AAAA-MM-DD. Não detalha se o intervalo é inclusivo nem o comportamento de datas invertidas, mas já dá o essencial para chamadas corretas.

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?

O nome e o final '[Flattened action: por_cliente]' definem o recorte: agenda do Astrea agrupada por cliente. A descrição lista os tipos (HEARING, EVENT, DEADLINE, TASK) e distingue da variante global, embora use 'Agenda' como substantivo e apresente as duas ações, o que exige atenção do agente até o final.

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?

A seção 'Ações' contrasta global (todas as atividades em uma janela de datas) com por_cliente (atividades agrupadas pelo cliente via processo vinculado), deixando claro o contexto de uso. Não recomenda explicitamente 'use astrea_agenda_global quando precisar de lista única', mas a distinção entre as duas listas cumpre a orientação.

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 write operation, but the description adds crucial behavioral detail: omitting responsible_id causes the entry to be attributed to the integration user rather than the lawyer, and bulk execution is explicitly disclosed. This goes well beyond the structured annotations and helps the agent predict side effects.

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 front-loads the core purpose, then uses compact parameter-by-parameter lines with defaults and caveats, and closes with a one-line bulk note. Every sentence adds value and the structure is easy to scan.

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 is highly complete for a create operation, but there is minor ambiguity around bulk usage: the schema lists case_id as required while the description says case_ids is accepted for batched execution, without clarifying whether singular fields should be omitted in bulk mode. Return/error behavior is also not mentioned, though the tool has no output schema.

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 0%, but the description compensates fully by explaining case_id, description, date format and default behavior, responsible_id semantics, and the bulk parameters case_ids and responsible_ids. The agent gets actionable meaning beyond raw schema types.

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 opens with a specific verb-resource pair: 'Lança um andamento (histórico) MANUAL num processo do Astrea — registra um ato/observação na timeline'. It also explicitly contrasts this with automatic court capture, which distinguishes it from other Astrea tools and clarifies what kind of operation this is.

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 clearly frames this as the manual timeline-entry tool and notes it is not automatic tribunal capture, giving the agent a decision criterion. It also points to astrea_processos and astrea_responsaveis for ID lookups. However, it does not explicitly mention when to prefer sibling tools like astrea_andamentos for reading timeline data.

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, idempotentHint=true, destructiveHint=false. The description adds value by explaining the returned fields (date, type, description, responsible) and the distinction between automatic and manual types. 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?

The description is extremely concise: two sentences plus one about bulk support. It is front-loaded with the core purpose, then adds details. 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?

The description provides some context about returned fields and bulk capability, but it does not fully describe all parameters. With no output schema, the description partially compensates by listing fields, but the parameter semantics are lacking. The tool has 4 parameters, only one is somewhat explained.

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 0%. The description only explains the 'case_ids' parameter for bulk execution, but does not mention 'limit', 'only_manual', or the required 'case_id'. The field descriptions (date, type, etc.) are helpful but do not compensate for the lack of parameter documentation.

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 retrieves the timeline/history ('andamentos') of a legal case in Astrea, specifying it as the basis for generating client reports. It distinguishes between automatic and manual entries, and the purpose is unmistakable given the sibling tool 'astrea_andamento_criar' for creating steps.

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

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

The description implies usage for reading the case timeline and mentions bulk support via 'case_ids'. While it does not explicitly contrast with sibling tools, the naming convention and context make it clear this is read-only vs. 'astrea_andamento_criar' for creation. However, explicit when-to-use/when-not-to-use guidance is missing.

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 readOnlyHint=false and destructiveHint=false, consistent with description of creating a case. The description adds context about what a CASO is and that it unlocks automation, but does not disclose potential side effects, rate limits, or authorization needs. No contradictions, but limited additional behavioral transparency 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?

Two concise sentences with front-loaded purpose and contextual details. No wasted words, but the second sentence is somewhat long. Efficient and clear.

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 is insufficient. It explains core concept and required fields but not optional parameters or return value. The tool is moderately complex and missing explanations for many fields, leaving gaps for correct invocation.

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

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

Schema description coverage is 0%, so description must compensate. It explains titulo is required and the customer_id/customer_nome relationship, but leaves 8 of 10 parameters undocumented (polo, objeto, tag_ids, qualificacao, data_abertura, responsavel_id, valor_envolvido). Partial coverage with no enums or additional meaning for most parameters.

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 extrajudicial/consultative case in Astrea, distinguishes it from judicial process by noting no CNJ/tribunal, and lists specific use cases (consultoria, contratos, etc.). This is a specific verb+resource with clear differentiation from sibling astrea_processo_criar.

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 states when to use (extrajudicial/consultative) and when not (for judicial process use astrea_processo_criar). Also specifies required fields (titulo and either customer_id or customer_nome). Provides clear context and alternative.

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 and idempotent behavior. The description adds important behavioral context: it returns a single compact page, uses cursor pagination, and does not scan the entire account. 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?

The description is a single, direct sentence that immediately conveys the tool's purpose and key behavior. 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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the essential aspects: what it returns, pagination, and scope limitation. It could hint at empty result handling but is generally 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?

Schema has 0% description coverage, so the description must compensate. It mentions cursor pagination and page size implicitly via 'compact page' and 'paginate with the returned cursor', but does not explicitly explain limit and cursor parameters. Some value added, but not comprehensive.

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 retrieves a compact paginated list of clients/contacts with specific fields (id, name, classification, type, tags). This distinctively sets it apart from sibling tools like astrea_processos_list, which handle processes.

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?

Describes cursor-based pagination and explicitly notes that it does not scan the entire account, guiding efficient usage. However, it does not explicitly state when to use this tool over alternatives, though the sibling context makes it reasonably 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 meaningful behavioral details beyond the annotations: start is interpreted in server timezone (UTC), end defaults to start+30 minutes, responsible_id omission may hide the event from the attorney's calendar, and repeat creates a recurring series in one call. This is strong context for a mutation tool, though it does not describe the return value or failure modes.

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 front-loaded with a clear purpose sentence followed by a scannable bullet list. Every parameter explanation earns its place by adding format, default, or behavioral nuance, and there is no filler or repetition.

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

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

For a 10-parameter creation tool with no output schema, the description explains core semantics and important defaults, but it does not state what the tool returns (e.g., the created compromisso ID) and omits the plural parameters. The missing output information is a notable gap since no output schema exists to compensate.

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 0%, so the description carries the parameter documentation burden. It explains 8 of the 10 parameters well, including ISO format, defaults, and behavioral caveats. It does not cover the plural variants case_ids and responsible_ids, which are missing from the parameter documentation entirely, so the coverage is strong but incomplete.

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

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

The description states a specific verb ('Cria') and resource ('COMPROMISSO/evento na agenda'), with the additional scope that it must be linked to an Astrea process. It is clear and likely distinguishable from edit/delete siblings by the 'criar' verb, but it does not explicitly contrast with astrea_tarefa_criar or astrea_andamento_criar, so sibling differentiation is only implicit.

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

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

The description implies use for creating calendar appointments/events tied to a process, and gives helpful lookup directions ('ver astrea_processos', 'ver astrea_responsaveis'). However, there is no explicit guidance on when to prefer this tool over alternatives such as astrea_tarefa_criar or astrea_compromisso_editar, and no exclusion criteria.

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?

Reveals non-obvious behavior: partial-update semantics (omitted fields unchanged), duration preservation when only start is provided, and appointment_id retention. With all annotations set to false, these details carry the behavioral burden and are consistent with the annotations.

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

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

Well-structured as a lead paragraph plus bullet list, with each element earning its place: use case, anti-pattern warning, and parameter semantics. Slightly redundant between the generic 'mudar algo' and the enumerated examples, but not padded.

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 mutation tool with 9 parameters and no output schema, the description covers the core single-edit workflow thoroughly. It leaves gaps around the plural array parameters and responsible fields, which could mislead an agent attempting more advanced or bulk edits.

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?

Adds meaning for appointment_id, start (with ISO example and duration-preservation nuance), end, title, location, and all_day. However, responsible_id, responsible_ids, and appointment_ids appear in the schema but are completely undocumented, and with 0% schema coverage the description does not fully compensate.

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?

Describes a specific verb ('Edita'), a specific resource ('COMPROMISSO/evento da agenda do Astrea'), and a defining constraint ('altera no lugar, PRESERVANDO o appointment_id'). This clearly differentiates it from create and exclude siblings even without a title.

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 states when to use it ('sempre que precisar mudar algo de um compromisso já criado'), gives concrete examples, and explicitly warns against the delete-and-recreate anti-pattern because it breaks references. It does not directly name the sibling tools as alternatives, but the when/when-not logic is very 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 clearly states that the tool deletes/cancels an appointment, which is a destructive operation. However, the annotations declare destructiveHint: false, which directly contradicts the described behavior. Per the rubric, this contradiction forces a score of 1.

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

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

The description is compact and front-loads the core purpose before the usage caveat and bulk note. Each part earns its place, though 'Exclui' and 'Use para CANCELAR' are slightly redundant.

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 delete tool, the description covers the operation, the source of the identifier, bulk support, and the key sibling alternative. It does not describe failure/return behavior, but no output schema exists and the core invocation guidance 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?

Schema description coverage is 0%, so the description must compensate. It explains that appointment_id comes from astrea_compromisso_criar and that appointment_ids enables batch execution. This adds useful meaning, but it leaves the relationship between the singular required parameter and the batch parameter somewhat underspecified.

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 and resource: 'Exclui um COMPROMISSO/evento da agenda do Astrea' and explicitly frames it as cancellation. It also differentiates itself from the sibling astrea_compromisso_editar, so an agent can immediately tell which tool to choose.

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 states when to use this tool ('Use para CANCELAR o compromisso') and when not to, directing the agent to astrea_compromisso_editar for corrections and warning that deleting and recreating breaks references. This is strong, actionable 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 indicate readOnlyHint and idempotentHint. The description adds specifics about the return content (plan, status, trial days, tenant, perfil). No contradictions found.

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 and front-loaded: first sentence lists content, second explains usefulness. No redundant 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 parameters and no output schema, the description adequately explains what the tool returns and its purpose. Annotations cover safety aspects.

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 zero parameters, so no description is needed. The baseline for 0 params is 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 specifies that this tool retrieves account information (plan, status, trial days, tenant, profile) and is useful for checking the office's plan. It distinguishes well from sibling tools that handle agendas, cases, finances, etc.

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 states the tool is useful for knowing the office's plan, implying when to use it. However, it does not explicitly mention when not to use it or provide alternatives, but the sibling list shows other tools are for different purposes.

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?

Although annotations are sparse, the description explains the generative and linking behavior, indicates bulk support via arrays, and clarifies default assignments, but does not detail side effects or permissions.

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 with main purpose front-loaded, parameter details, and bulk note; slightly lengthy but 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?

Good usage guidance but lacks output description and error handling; no output schema provided, so missing return value specification.

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?

No schema descriptions (0% coverage), but the description explains each parameter fully: model can be id or name with partial matching, title defaults to model name, responsible_id defaults to integration user, and bulk support via case_ids and responsible_ids.

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 generates a document from a model and links it to a process, with specific verb 'Gera um documento a partir de um MODELO' and distinguishes from sibling astrea_documento_upload.

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 states when to use (generate from template) and when not (use astrea_documento_upload for ready files), and references sibling tools for model and process IDs.

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 readOnlyHint=false and destructiveHint=false, which are consistent with the description's 'anexa' (attach) action. The description adds behavioral details: file linking to process, bulk support via case_ids/responsible_ids, and default behavior for description and responsible_id. 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 front-loaded with the core purpose and then lists parameters in a clear bullet style. It is slightly redundant (e.g., mentions vincular twice) but overall efficient and well-structured. Could be more concise but still good.

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 covers the tool's purpose, parameters, and bulk capability. It doesn't describe the return value or error conditions, but for a mutation tool with clear annotations (idempotentHint=false), this is sufficient. The agent has enough context to use it correctly.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains each parameter: case_id (process ID), attachments (three methods, file_name required), description (defaults to file names), and responsible_id (defaults to integration user). Also covers case_ids and responsible_ids via bulk support note. This adds meaning beyond the raw 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 verb (anexa) and resource (documento a um processo do Astrea), specifying what types of documents are accepted. It distinguishes from siblings like astrea_documento_gerar by emphasizing that the attachment is always linked to the process, not to a task, which differentiates it from other document-related tools.

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

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

The description explains the tool's function and parameter usage (e.g., one of file_url/file_base64/upload_code for attachments) but does not explicitly mention when to use this tool versus alternatives like astrea_documento_gerar. It provides context on where the document links (process not task) but lacks comparative guidance for sibling tools.

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 only indicate non-readonly and non-destructive. The description adds that info remains available, reopening is external, and processing is asynchronous. It also describes the effect of unlink_from_court. This goes beyond the annotations, though could detail error handling.

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, using a clear opening statement followed by bullet points for parameters and a note on reopening and async processing. Every sentence adds value without 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 no output schema and 3 parameters, the description covers purpose, use case, parameter details, and behavioral notes (async, reopening). It lacks explicit mention of the return value, but overall is complete for 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?

Schema description coverage is 0%, so the description fully explains each parameter: case_ids (IDs from astrea_processos, accepts multiple), conviction_amount (optional condemnation value), and unlink_from_court (optional boolean to unlink from court). This adds critical meaning beyond the bare 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 closes/inactivates processes in Astrea in batch, marking them as closed while keeping info available. It specifies the verb (encerrar), resource (processos), and distinguishes from siblings by focusing on batch inactivation.

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 provides a specific use case ('higienização da carteira para baixar processos finalizados') and notes that reopening is done via the Astrea screen. It does not explicitly exclude alternatives or compare with other tools, but the batch context is 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?

Adds substantial context beyond the annotations: it discloses asynchronous batch processing with a delay of a few seconds, internal batching in a single call, that remover does not delete the tag itself, and the prerequisite that tags must already exist. Annotations declare it is a non-readonly mutation, and the description complements this well. It does not cover partial-failure behavior or permissions, keeping it from a 5.

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?

Front-loaded purpose with a bulleted breakdown of action and parameters; each line carries information. Slightly verbose but every sentence adds a distinct fact (routing, action semantics, batching, prerequisites).

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 2-param mutation tool with no output schema, it covers routing, prerequisites, async behavior, and parameter meaning. Gaps remain around error/partial-failure handling and return values, but the essentials for correct invocation are present.

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 0%, so the description must compensate. It explains that case_ids are process ids (pointing to astrea_processos) and tag_ids are tag ids (pointing to astrea_etiquetas), and that both accept multiple values. This meaningfully clarifies both parameters despite no 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?

States a specific verb (aplicar/remover etiquetas) and resource (PROCESSOS), with the batch scope explicit. It explicitly distinguishes itself from the sibling astrea_tarefa_etiquetar for tasks, so an agent can route correctly without inspecting schemas.

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

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

Gives a concrete when-to-use scenario (classificar/higienizar a carteira, marcar a área de centenas de processos) and names the alternative tool (astrea_tarefa_etiquetar) with the condition that selects it. The action semantics (aplicar adds, remover removes without deleting the tag itself) are also spelled out.

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?

Adds real context beyond annotations: batch runs in a single call but is internally chunked, processing is asynchronous with effects appearing within seconds, and 'remover' removes the tag from the case without deleting the tag itself. The non-destructive removal note is valuable and consistent with destructiveHint=false.

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?

Front-loads purpose and the sibling distinction, then bullets the mechanics. Dense but every line earns its place; minor redundancy between the headline 'Aplica ou remove' and the per-action bullet.

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 2-param mutation with no output schema, it covers prerequisites (tags must pre-exist), async timing, batch semantics, and non-destructive removal — everything an agent needs to invoke it correctly.

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

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

With 0% schema description coverage, the description carries the full burden and delivers: case_ids are process ids (see astrea_processos) and accept multiples; tag_ids are tag ids (see astrea_etiquetas) and accept multiples. Both required params are explained with discovery pointers.

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

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

States a concrete verb+resource ('aplica ou remove etiquetas em PROCESSOS, EM LOTE') and differentiates from astrea_tarefa_etiquetar for tasks. However, the name and flattened action say 'remover' while the description leads with 'Aplica ou remove', creating a slight mismatch about whether this instance applies or removes tags.

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 names the use case (classify/hygiene the portfolio, mass-tagging hundreds of cases), points to the correct sibling for tasks (astrea_tarefa_etiquetar), and states the prerequisite that tags must already exist in Astrea. Nothing is left to inference.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds that it returns specific fields (id, label, color, restrictions) and the types of restrictions (CASES/TASKS/APPOINTMENTS), providing useful 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.

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

Two sentences, front-loaded with purpose, followed by a concrete usage example. No redundant information; every word 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?

For a zero-parameter, read-only list tool, the description fully covers what the tool does, its return structure, and how to leverage the output in subsequent steps. Complete given the simplicity.

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?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter details, and the baseline score of 4 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 lists tags (etiquetas) with id, label, color, and restrictions. It distinguishes from sibling tools like astrea_etiquetar_aplicar by focusing on reading/listing rather than applying.

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 instructs to use this tool to find tag IDs for filtering processes and summing financial values. It implies a use case but does not specify when not to use or list alternatives.

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 provide readOnlyHint and idempotentHint, so the description's addition of bulk support is helpful but not extensive. It does not disclose other behaviors like return format or error handling, but the annotations cover the core safety profile.

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 only three lines of substantive content, plus a flattened action note. It is front-loaded with the core purpose. The structure could be clearer by separating actions more explicitly, but overall it is 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 and only 2 parameters, the description covers purpose and bulk support but lacks details on return fields, error conditions, or prerequisites. For a simple read tool with good annotations, it is adequate but not comprehensive.

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

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

With 0% schema description coverage, the description partially compensates by mentioning case_id (implicitly) and case_ids for bulk. However, it does not explain parameter formats, constraints, or the expected values, leaving significant gaps.

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 provides a financial summary of expenses (despesas) for a case, using specific verbs ('Resumo financeiro') and resource ('processo'). It implicitly distinguishes from the sibling 'astrea_financeiro_honorarios' by naming both actions and then flattening to despesas.

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

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

The description implies usage for expenses based on the tool name and flattened action, and explicitly mentions bulk support via case_ids. However, it does not explicitly state when to avoid this tool or provide direct alternatives, leaving some ambiguity.

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 readOnly, idempotent, and non-destructive. The description adds that it supports batch execution ('Bulk support: accepts case_ids'). However, it does not disclose other behavioral traits like pagination or data freshness. The annotation coverage is good, so the description adds moderate value.

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 relatively concise but contains redundancy: it lists both actions then specifies a flattened action. The bullet format is clear, but the inclusion of both actions when the tool is for honorarios only is confusing. Could be more to the point.

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 output schema and 0% parameter description coverage, the description is incomplete. It does not explain what 'flattened action' means, nor does it detail the response format beyond a few fields. For a financial tool with batch support, more context on usage (e.g., max batch size, error handling) is needed.

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

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

With 0% schema description coverage, the description must compensate. It mentions that 'case_ids' enables batch execution, which adds meaning beyond the schema. However, it does not explain the format of 'case_id' or 'case_ids' (e.g., if they are process numbers). The description lists response fields ('totalAmount', etc.), but these are not parameter-related. Moderate value.

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

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

The description states it provides a 'financial summary of a process', but it's ambiguous by listing both 'honorarios' and 'despesas' actions while then specifying '[Flattened action: honorarios]'. The tool name and sibling 'astrea_financeiro_despesas' suggest it's for honorarios only, but the description is not clear.

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

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

There is minimal guidance on when to use this tool. It mentions 'use para valor de êxito' for honorarios, providing a specific use case, but it does not compare with siblings like 'astrea_financeiro_despesas' or other alternatives. No when-not-to-use information.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description aligns perfectly by describing a read-only listing operation with no side effects. It adds useful context about the return values (id, nome) beyond what annotations provide, enhancing transparency. 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 extremely concise with two sentences. The first sentence states the core purpose, the second provides usage context and return information. Every sentence is essential, and the structure is front-loaded and efficient.

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

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

For a tool with no parameters and no output schema, the description covers the essential aspects: what it lists, why to use it (as a prerequisite), and what it returns (id + nome). It could mention that it returns all models without filtering, but that is implicit given the lack of parameters. Overall, it is sufficiently complete for a simple listing tool.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to add parameter information, and it correctly omits it. There is no loss of meaning since there are no parameters to describe.

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

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

The description clearly states the verb 'Lista' (lists) and resource 'MODELOS de documento', provides examples (procuração, contrato, petição), and explains its purpose as a prerequisite for astrea_documento_gerar. It also specifies the return fields (id + nome), making the tool's purpose highly specific and distinct from siblings.

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

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

The description explicitly advises using this tool before astrea_documento_gerar, giving a clear when-to-use scenario. However, it does not mention when not to use it or contrast with other sibling tools beyond that one reference. The guidance is helpful but could be more comprehensive.

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 non-read-only and non-destructive, but description adds context about unlocking automation side effects. However, it does not detail error behavior or idempotency. The description 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 dense but clear, front-loading purpose and usage. It could be structured with bullet points for parameters but remains efficient for a single paragraph.

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 16 parameters and no output schema, the description lacks information about return values, such as the created process ID. It also does not cover potential constraints like uniqueness of title. Additional details on expected output 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?

With 0% schema description coverage, the description adds some meaning: explains client identification options (customer_id vs customer_nome) and lists optional judicial fields. But many parameters (polo, objeto, tag_ids, etc.) remain unexplained, leaving gaps.

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 judicial process in Astrea, uses a specific verb ('cria'), and distinguishes from sibling 'astrea_caso_criar' for extrajudicial cases. It also notes it closes parity with edit/end tools.

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

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

Explicitly says when to use (extracted data, unlocking automation) and what is obligatory (title, client info). Provides clear alternative: for extrajudicial cases use 'astrea_caso_criar'.

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?

Description explains that it reads the current process and rewrites preserving other fields (only changes what you inform). It also discloses batch capability. Annotations provide no contradictory hints.

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 sentences and a bullet list, front-loading the core purpose. Slightly more structured formatting would improve readability.

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 explains the editable fields and batch behavior. It could mention the return value, but the tool is simple enough.

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

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

Despite 0% schema description coverage, the description explains the meaning of 'objeto' and 'conviction_amount', and implies the role of case_ids for bulk. This adds significant value beyond the raw 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 edits fields of a single process in Astrea. It lists specific editable fields (objeto, conviction_amount) and distinguishes from sibling tools like astrea_encerrar and astrea_etiquetar.

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 states to edit only one process at a time, and for closing/reactivating or labeling, to use other tools. Also mentions bulk support via case_ids, providing clear usage 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?

The description is otherwise rich, disclosing compact responses, one-pass scanning, default status All, and truncation semantics. However, it repeatedly states results may be partial ('truncado=true ... pode haver outros processos', 'resultado é PARCIAL') while the annotations declare openWorldHint=false, which indicates closed/complete results. This is a direct annotation contradiction, so per rubric the score is 1.

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 long but densely organized: primary buscar behavior first, then alternatives, caveats, and field lists. Every section adds operational value, and important warnings like truncado and default All are placed prominently.

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

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

There is no output schema, so the description provides the response envelope (encontrados/nao_encontrados/varredura), field names, the meaning of truncado, and the reasons for partial results. It covers batching, status filtering, pagination, and alternative tools, leaving the agent with enough detail to call and interpret the tool correctly.

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

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

With 0% schema coverage, the description compensates for nearly all parameters: numeros, texto, status, contact_id/tag_id, top_n, cursor, contact_ids/tag_ids, and bulk support. Only `limit` is left somewhat implicit; the '30 números = 1 chamada' hints at batch sizing but does not clearly explain the limit parameter itself.

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

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

The description states a specific action and resource: 'buscar: ACHA o processo pelo NÚMERO CNJ' and explains it returns the internal case_id needed by other tools. It clearly separates buscar from the list, count, por_cliente, and novos_por_mes actions, and the flattened-action marker ties it to the tool name.

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

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

The description gives explicit routing guidance: use buscar to find a specific process and 'não pagine list'; use count for totals; use list with filters when truncation makes aggregates unreliable; send all numbers at once to scan once. It also explains when results should not be presented as complete totals.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that responses are compact, that count is fast, and that bulk contact_ids/tag_ids are accepted. However, it does not disclose count-specific behavior such as default status handling or exact response format, so the added context is modest.

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 long and most of it documents actions that are not specific to a count-only tool. The '[Flattened action: count]' line is a signal that stale boilerplate was reused. Although the bullet structure helps readability, most sentences do not earn their place when the agent only needs to invoke astrea_processos_count.

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 core idea of count ('total de processos (mesmos filtros) rápido') is present, but there is no output schema and the response format is never specified. Defaults, which filters apply, and which schema parameters should be ignored are left unclear. The description is further diluted by irrelevant action-level details, so it is not fully reliable for autonomous invocation.

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

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

Schema description coverage is 0%, so the description carries the parameter-semantics burden. It does explain contact_id, tag_id, and status via the list action and 'mesmos filtros', and it mentions bulk contact_ids/tag_ids. But the schema exposes 10 parameters, many of which (numeros, texto, cursor, top_n, limit) belong to other actions; the description never clarifies which parameters are actually valid or ignored for count, creating real ambiguity.

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 opens generically with 'Processos (casos) no Astrea' and enumerates five actions (buscar, list, count, por_cliente, novos_por_mes), so the actual scope of a tool named astrea_processos_count is ambiguous. The 'count' bullet is clear enough ('total de processos... rápido, use pra quantos'), but the appended '[Flattened action: count]' suggests the description is a leftover from a multi-action tool, making the true resource/operation less obvious.

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

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

The description gives explicit guidance: use count for 'quantos', use buscar to find a specific processo, and use list for pagination or detailed filtering. The truncation note also routes users to count for the exact total, which is strong when-to-use guidance even though it is embedded in a broader multi-action description.

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?

It discloses non-obvious behavior: compact responses, pagination via cursor, one-page-only scope, truncation semantics, and the full process field list including conditional fields like convictionAmount. Annotations already mark the tool readOnly and idempotent, and the description adds meaningful runtime behavior without contradicting them.

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 long and includes entire sections for sibling actions (buscar, count, por_cliente, novos_por_mes) that are not the list action. While it is structured with bullets, a substantial portion is redundant or irrelevant for this specific flattened tool. The 'Flattened action: list' marker is buried at the bottom of a verbose block.

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 the list action, the description covers pagination, filters, response fields, and truncation behavior, which is especially important because there is no output schema. It is nearly complete, but the inclusion of unrelated action documentation creates ambiguity that prevents a perfect score.

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

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

With 0% schema description coverage, the description carries the full burden and does explain most parameters: contact_id, tag_id, status, cursor, numeros, texto, top_n, contact_ids, and tag_ids. The main gap is 'limit', whose behavior is only implied by the default value, and the mapping of parameters to each action is not always clear for a flattened list tool.

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

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

The description clearly defines the 'list' action: one page of processes, not a full account scan, with filters and cursor pagination. However, it opens with a generic 'Ações' list covering buscar, count, por_cliente, and novos_por_mes, which makes the tool look like a multi-action endpoint rather than a single list tool. The explicit 'list' bullet and 'Flattened action: list' note allow an agent to recover the intended purpose, but the framing is muddier than it should be.

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 is explicit about when to use list versus alternatives: 'Pra achar UM processo específico use buscar, não pagine list' and 'count: ... use pra quantos'. It also says bulk contact_ids/tag_ids are accepted. This gives an agent clear decision rules for selecting list over siblings.

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

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

Beyond the readOnly/idempotent annotations, it discloses scan-one-time behavior, default status 'All' including closed cases, pagination/cursor semantics, partial-scan truncation with 'tempo'/'teto_de_paginas' reasons, the 'diga isso ao usuário' instruction, and the fact that convictionAmount only appears when filled. 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 text is well organized with bullets and front-loaded caveats, but it is long and spends most of its space on operations other than the flattened novos_por_mes action. It is dense and useful, yet not appropriately sized for the specific tool it defines.

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

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

For a tool with no output schema and no parameter docs, it covers return shapes, truncation, default filters, list fields, and bulk execution thoroughly. It would be a 5 if it stated the exact novos_por_mes response shape and clarified limit semantics without the multi-action ambiguity.

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

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

Schema description coverage is 0%, and the text compensates well by giving meaning to numeros (batch CNJ search), texto, cursor, status, top_n, contact_id, and bulk contact_ids/tag_ids. The main gap is limit, which is present in the schema but never explained.

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

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

The description states 'Processos (casos) no Astrea' and lists five actions, so it does say what the broader tool does. However, for a tool named astrea_processos_novos_por_mes, the intended operation is just one bullet among buscar/list/count/por_cliente, and it overlaps with sibling tool names, making the primary purpose ambiguous rather than specific.

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

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

It gives explicit internal routing rules: 'Pra achar UM processo específico use buscar, não pagine list', 'count ... use pra "quantos"', and when a varredura is truncated it says to use count for the exact total or list with filters. It lacks a direct comparison with the sibling astrea_processos_* tools, 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.

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

The description goes far beyond the readOnly/idempotent annotations by disclosing concrete behavior: numeros[] enables a single account scan for a batch, status 'All' includes closed cases by default, list pages instead of scanning the whole account, and por_cliente/novos_por_mes return varredura with truncado/motivo to signal partial results. It even instructs the agent to tell the user when a total is partial rather than presenting it as complete. No contradiction with annotations exists.

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 bullet structure is readable and information is front-loaded, but the text is long and includes full instructions for multiple actions that may be out of scope for this flattened por_cliente tool. The '[Flattened action: por_cliente]' line is cryptic rather than a clear natural-language statement, so not every 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 the absence of an output schema, the description covers return shapes and edge cases well: encontrados/nao_encontrados/varredura for buscar, truncation semantics with motivo for por_cliente/novos_por_mes, and per-process fields for list. It also tells the agent how to recurse to count or list for exact/partial results. Missing are the meaning of limit and an explicit statement of which action this flattened tool actually executes.

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

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

With 0% schema description coverage, the description does substantial work: it explains numeros[] batching, the status default and meaning, cursor pagination, top_n limiting, contact_id/tag_id filters, and bulk contact_ids/tag_ids. The main gap is the 'limit' parameter, which is never explicitly described, and some parameters like numeros/texto belong to other actions, leaving parameter-to-action mapping ambiguous.

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 does contain a valid por_cliente definition ('resumo por cliente (qtd + soma do valor da causa), ordenado') and names the Astrea process resource, so it is not a tautology. However, it presents a broad multi-action 'Ações' list for buscar/list/count/novos_por_mes and only reveals the actual tool purpose via a single bullet plus the cryptic '[Flattened action: por_cliente]' footer. This muddles the tool's scope and does not clearly distinguish it from sibling tools like astrea_processos_list and astrea_processos_count.

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

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

There is useful internal guidance, such as 'Pra achar UM processo específico use buscar, não pagine list' and 'use count pro total exato', which tells the agent when to choose one operation over another. But the guidance treats alternatives as sub-actions instead of naming the sibling MCP tools, and if this tool is truly flattened to por_cliente only, much of the guidance points to operations handled by other tools. The conditions to use this tool versus siblings are implied, not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful output context ('eu' field marks the integration user) but does not disclose other behavioral traits such as sorting, pagination, or empty results. 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 three sentences with no fluff: the first states purpose and output fields, the second explains the primary use case, and the third adds essential output semantics. Every sentence earns its place and the key action 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?

Despite having no output schema, the description covers the return values (id, nome, e-mail) and the special 'eu' field. Combined with rich annotations and a simple zero-parameter signature, the description is complete enough for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. With 0 parameters, the baseline is 4; nothing is needed from the description to disambiguate inputs.

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

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

The description states a specific verb ('Lista'), a clear resource ('usuários (membros) do escritório no Astrea'), and the returned fields ('id, nome, e-mail'). It clearly differentiates from siblings by focusing on users/responsibles rather than clients, cases, or tasks.

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

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

It gives explicit context: use this tool to discover the responsible's id before creating/editing tasks, appointments, or progress updates, naming the sibling tools that require responsible_id. It lacks explicit exclusion criteria (when-not-to-use), but the use case is clearly scoped.

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

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

The annotations are minimal generic false hints, so the description carries the full behavioral burden. It discloses the returned task_id, the consequence of omitting responsible_id, the recurrence behavior (due_date becomes the first occurrence, and each occurrence is an independent task), and bulk execution support. There is no contradiction with the annotations.

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

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

The description is dense but well-structured, with the main purpose first and each parameter bullet adding non-obvious value. The recurrence warning, calendar-visibility caveat, and bulk note all earn their place. There is no filler or redundant restating of the schema.

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 creation tool with no output schema, the description covers inputs, optional behavior, return value, and post-creation lifecycle well. The only notable gap is the bulk path: it says case_ids and responsible_ids are accepted, but does not describe the response shape for batched execution, such as whether an array of task_ids is returned.

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 0%, but the description compensates thoroughly. Every parameter is given real meaning: case_id and responsible_id are cross-referenced to lookup tools, due_date has an ISO example, repeat explains its requirements and effects, and the array variants are explained as bulk execution. This is far beyond the bare 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 opens with a specific verb and resource: 'Cria uma TAREFA vinculada a um processo no Astrea.' This clearly identifies the operation and distinguishes it from other creation tools like astrea_processo_criar or astrea_compromisso_criar. It also names related reference tools and the edit/delete siblings, so an agent can tell this tool apart from nearby alternatives.

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 strong practical guidance: it explains how responsible_id affects calendar visibility, warns that omitting it may hide the task, and notes that repeat creates independent tasks that can later be edited/deleted via astrea_tarefa_editar/_excluir. It does not explicitly contrast this tool with sibling creation tools like astrea_compromisso_criar, 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.

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

Annotations already declare a non-readOnly, non-destructive, non-idempotent mutation, and the description usefully adds partial-update semantics ('o que você omitir fica como está') and the no-duplication guarantee, which is exactly the context an agent needs before editing in place. It stops short of covering auth/permission requirements or failure behavior on a bad id.

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 purpose and the key 'omit = unchanged' rule are front-loaded, and per-field notes are cleanly bulleted. The bulk behavior is stated twice (once in Portuguese, once as a trailing English 'Bulk support' sentence), which is one redundant line in an otherwise tight definition.

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 mutation tool with no output schema, the description covers the essentials: partial-update semantics, label handling, parameter provenance, and batch rules. It leaves only edge behavior (invalid task_id, permissions, whether case_id must match the task) unaddressed.

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 0%, so the description must carry the load. It documents task_id (with its provenance), case_id, description, due_date with the AAAA-MM-DD format, and responsible_id with a lookup reference — good value. However, the three array parameters (task_ids, case_ids, responsible_ids) are only alluded to in one vague 'bulk support' sentence with no explanation of how they interact with the singular required fields.

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

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

States a specific verb+resource ('Edita uma TAREFA existente') and immediately qualifies the mode of mutation ('altera no lugar, sem duplicar'), which separates it from astrea_tarefa_criar. It also names the sibling to use for the one adjacent operation (labels → astrea_tarefa_etiquetar), so an agent can route without opening schemas.

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

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

Gives explicit conditions: supply at least one field to change, omitted fields are preserved, and label changes must go to astrea_tarefa_etiquetar. It also explains the batch constraint (call once per task unless all tasks share a case_id). The closing English 'Bulk support' line slightly muddies that rule rather than clarifying it, keeping this just short of 5.

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

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

Beyond the annotations, the description discloses that tags already present are preserved, that removing a tag does not delete the tag itself, that tagging runs task by task, that large batches may be truncated and return a pending list, and that one task's failure does not stop the others. These are exactly the behavioral traits an agent needs for safe invocation.

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 structure is front-loaded and bulleted, so it is easy to scan. It is slightly bloated by covering both aplicar and remover and by including the flattened-action metadata, which adds ambiguity rather than 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?

For a batch mutation tool with no output schema, the description supplies strong context about sources, batching, truncation, and partial failure. It is weakened by the mismatch between the described action parameter and the actual schema, which only contains task_ids and tag_ids.

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 0%, so the description must carry parameter meaning, and it does: task_ids are task IDs obtained from agenda/task creation tools and do not require case_id; tag_ids are tag IDs from astrea_etiquetas and the tag must allow TASKS in restrictions. Both parameters are therefore fully explained.

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

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

The description states a specific resource (TAREFAS) and operation (apply/remove tags), and distinguishes task tagging from process tagging by naming astrea_etiquetar. However, it also covers removal despite the tool name being _aplicar, mentions an action parameter that is absent from the schema, and does not clearly distinguish itself from the sibling astrea_tarefa_etiquetar_remover.

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

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

It gives clear usage examples (classify/prioritize overdue tasks, restore tags) and an explicit alternative for processes (astrea_etiquetar). It also points to where task_ids and tag_ids come from. The main gap is that it does not clearly route removal calls to the sibling removal tool or reconcile the missing action parameter.

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?

Goes well beyond the annotations: states that removing does not delete the tag itself, that existing tags are preserved, that it runs task-by-task, that large batches may return truncated with a 'pendentes' list, and that one failure does not block others. These are exactly the operational details annotations cannot convey.

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?

Front-loaded with purpose, then bulleted parameter and behavior notes — dense but well organized. Slightly heavy for a two-parameter tool, though every point 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?

Complete for this complexity: prerequisites (tag restrictions), parameter sourcing, batch/partial-failure behavior, and the return shape (tarefas[].ok, 'pendentes') are all covered despite no output schema.

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

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

With 0% schema coverage, the description carries the full load: task_ids are task ids (with pointers to discovery tools) and no case_id is needed; tag_ids are tag ids (see astrea_etiquetas) and the tag must permit TASKS in restrictions. This compensates fully for the empty schema.

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

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

States a specific verb and resource (apply/remove tags on TASKS), including batch scope, and explicitly names the sibling to use for PROCESSOS (astrea_etiquetar). An agent can distinguish it from astrea_tarefa_etiquetar_aplicar/remover without opening schemas.

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

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

Gives concrete use cases (classificar/priorizar, ex.: marcar URGÊNCIA nas atrasadas) plus an explicit alternative for a different resource type. The action semantics (aplicar adds, remover takes away) are spelled out.

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 honestly states it deletes tasks, but the annotations indicate destructiveHint: false, which contradicts the inherent destructive nature of deletion. This mismatch misleads the agent about safety.

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 at two sentences plus a bulk note. It front-loads the purpose and provides parameter explanations without 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 complexity (4 parameters, bulk, performative operation) and no output schema, the description is too sparse. It omits error behavior, idempotency, and consequences of deletion. The annotation contradiction further reduces 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?

For 0% schema coverage, the description adds meaning by explaining that task_id comes from astrea_tarefa_criar and case_id locates the task. It also mentions bulk arrays. However, it lacks detail on array usage constraints or expected values.

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 excludes a task ('Exclui uma TAREFA'), distinguishing it from sibling tools like astrea_tarefa_criar (create) and astrea_tarefa_editar (edit). The verb and resource are specific.

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?

While it doesn't explicitly state when to use or when not, the description clearly implies its usage for deleting tasks and provides context for parameters, including bulk support. However, no alternatives or exclusions are mentioned.

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 useful behavior beyond the annotations: config header yields a permanent connection, while passing a token yields a session-only login, and no args returns a link. It does not fully spell out side effects or success/failure return values, but annotations already cover idempotency and non-destructiveness.

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 dense and front-loaded, with no fluff, but the long single sentence with parenthetical clauses and multiple alternatives could be structured into clearer separate instructions. Still, every part adds necessary information.

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

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

For a one-parameter auth tool with no output schema, it covers the no-arg return (the link), the token-paste path, and the persistent-config alternative. It doesn't state the response on a token success/failure, but the invocation guidance is sufficient 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.

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

With 0% schema coverage, the description carries the full burden for the optional `token` parameter. It explains that token is a JWT/access token pasted by the user and how to pass it, compensating well for the bare 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 identifies the tool as MCP.AI authentication for IDE agents, with a concrete browser-login + access-token flow and two invocation paths (no args for a link, token for login). This specific verb+resource is unambiguous and easily distinguished from the unrelated calculo_* sibling tools.

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

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

It explicitly differentiates the persistent config-header approach ('best... permanent, non-expiring') from the session-only paste/login path, and states exactly when to call with no args versus with { token }. This gives the agent clear selection criteria for both setup and invocation.

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 establish this is read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that by specifying the two main response states: authenticated:true with empty pending[] when all providers are connected, and connect_url plus per-install URLs when credentials are missing. This helps an agent predict what to expect.

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

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

The description is compact, front-loads the core purpose, and then adds only the essential conditional details. Every sentence contributes meaningful information, and there is no waste.

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

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

For a zero-parameter read-only status tool with no output schema, the description is complete enough. It tells the agent what information will be returned, what the success condition looks like, and what happens when credentials are missing. The low complexity means no additional guidance is required.

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

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

The tool has zero parameters, so the description does not need to explain any input semantics. The baseline of 4 applies because there is no parameter burden at all.

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: returning connection status and URLs. It distinguishes connect from its sibling authenticate by framing it as a status/read operation rather than an action, and the conditional output descriptions reinforce this.

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

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

The description makes clear that this is the tool to call when checking connection state or getting URLs. It does not explicitly mention alternatives like authenticate, but the context strongly implies connect is for status checking rather than initiating authentication, so usage is clear without being fully explicit.

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

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

Beyond the annotations, the description discloses important behaviors: invoke runs an MCP even when it is not installed, does a one-off run without adding the MCP to the toolkit, returns a connect link when credentials are needed, returns a checkout/top-up link when payment is needed, and requires workspace owner/admin for write operations. The description enriches the annotations and does not contradict them.

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 front-loaded with identity and the core flow, and nearly every sentence carries useful guidance. However, it is one dense, wall-of-text paragraph with mixed language ("pontualmente") and heavy inline emphasis, which makes the many action alternatives hard to scan and parse.

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 complex 23-parameter, 14-action facade with no output schema, the description is remarkably complete: it covers the core flow, one-off invoke semantics, auth/credential/payment behavior, permission requirements, installed flags, the prompt library, and most action outcomes. The main gaps are the resume action and return-shape details for a few actions, but the overall guidance is sufficient for correct invocation in most cases.

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

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

With 0% schema description coverage, the description does a lot of compensating work: it maps action values such as search, describe, invoke, install, list_tools, publish_prompt, and explains tool_id, arguments, and prompt-related intent. However, several parameters and enum actions remain unexplained, including resume, limit, immediate, tier_slug, cancel_reason, report_context, conversation, request_name, and request_details, leaving agents under-specified for those paths.

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 identifies the tool as the official mcp.ai marketplace: the in-platform catalog of MCPs/tools and the way to run them. It states the core discovery→describe→invoke flow, distinguishes the prompt-library subdomain from the MCP flow, and makes it clear this is a marketplace orchestrator rather than one of the sibling calculator/authenticate tools.

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

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

The description gives explicit when-to-use guidance: use install only to make an MCP permanent, prefer invoke for one-off use, use list_tools to see what is callable now, use subscribe/cancel for billing, and use request_mcp when nothing fits. It also explains what to do when invoke returns a connect link or checkout link, including retry behavior.

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 carry the safety profile with idempotentHint=true and destructiveHint=false. The description adds that conversation data is needed for reproduction, which is useful context. However, it does not disclose what happens after submission, such as whether a ticket is created or whether the report is asynchronous, though the annotations lower the burden.

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 consists of two tight sentences: the first states the purpose, the second gives the key usage instruction. There is no filler, repetition, or irrelevant detail.

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

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

For a simple three-parameter reporting tool with annotations already covering idempotency and destructiveness, the description is mostly sufficient. The main gaps are the unexplained `context` parameter and the absence of any indication of what the response or outcome will be, though no output schema is expected.

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 0%, so the description must compensate for undocumented parameters. It only clarifies the `conversation` parameter via 'conversation array with recent messages,' leaving the required `message` and optional `context` undefined. The agent must guess at their intended content.

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 opens with the verb 'Report' and explicitly enumerates three targets: 'bug, missing feature, or send feedback'. This makes the tool's purpose unmistakable and easily distinguishable from the sibling calculo_* and authentication tools, which serve entirely different functions.

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 establishes a clear context: use when a user reports a problem or wants to provide feedback. It also adds practical guidance to 'Include the conversation array with recent messages for reproduction.' It does not name alternatives, but none of the sibling tools overlap with bug reporting, so exclusions are unnecessary.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-mutating call. The description adds little beyond that—it names the output as versions but doesn't specify the format (e.g., semver strings, JSON object) or whether the output is human-readable. Since the annotations carry the safety profile, a 3 is appropriate.

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 sentence of 9 words, front-loading the action ('Show') and the object ('version'). There is zero waste, and it fully conveys the tool's purpose within its scope. This is a model of 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?

For a zero-parameter, read-only, idempotent tool with no output schema, the description is nearly complete. An agent can confidently invoke it without additional context. The only minor gap is that the return format is unspecified, but since there is no output schema, a brief note on the output structure (e.g., 'returns a plain-text summary') would elevate completeness. Still, the description is sufficient for correct invocation.

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

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

The tool has zero parameters, and the schema coverage is 100% (no properties). The description doesn't need to explain parameters. The baseline for zero-parameter tools is 4, and the description is consistent with that—it correctly implies that no input is required.

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: 'Show the current MCP platform and adapter versions.' This is a specific verb-resource pair that distinguishes it from sibling tools, which are all calculation or authentication tools. It could be slightly more explicit about what 'show' returns (e.g., a text summary vs. structured data), but the resource is unambiguous.

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

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

The description implies that this tool is for checking version information, which makes sense in contexts where an agent needs to confirm platform/adapter versions before proceeding. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention whether version information is needed for authentication or compatibility checks. Given the sibling tools are all calculations, the usage context is reasonably clear, but not explicitly delineated.

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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds value by detailing what kind of state is returned, including connection status and account bindings, which helps the agent understand the tool's informational scope.

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 tightly packed sentence with the main action front-loaded, followed by a colon-delimited list of return contents. Every phrase earns its place with no repetition or filler.

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

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

For a zero-parameter, read-only introspection tool, the description fully covers what the agent needs to know before calling: what information it will receive. No output schema exists, but the description essentially provides a light output contract by enumerating the returned components.

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 is empty with zero parameters, and schema description coverage is 100%, so the description has no parameter burden. Per calibration, zero-parameter tools receive a baseline of 4; the description's output-focused content is more than sufficient.

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

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

The description states a specific verb ('Returns') and resource ('current toolkit state'), then enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This is specific enough to distinguish it from computational siblings like calculo_* and action tools like authenticate or connect.

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 clearly conveys that this is the tool to call when an agent needs an overview or snapshot of the toolkit's current state. It does not explicitly list exclusion criteria or name alternatives such as show_version, but the context is clear enough for routine selection.

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