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?

Describes asynchronous batch processing and that tags are not deleted. However, the description mentions an 'action' parameter not present in the schema, causing confusion about whether the tool can both apply and remove.

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 yet covers key aspects, with structured bullet points for parameters. Every sentence adds value except the opening ambiguity.

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

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

Covers prerequisites, parameter sources, and async behavior. Lacks clarification on the action parameter discrepancy and return value, but given the tool's simplicity, it is mostly adequate.

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 well by explaining each parameter's source (astrea_processos, astrea_etiquetas) and behavior (batch processing, multiple IDs accepted).

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 'Aplica ou remove etiquetas' (applies or removes tags), but the tool name and final line 'Flattened action: aplicar' suggest it is only for applying. This ambiguity misleads the agent about the tool's scope.

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 use for batch classification/hygiene, references related tools for case_ids and tag_ids, and notes that tags must pre-exist. Lacks explicit when-not-to-use or alternatives, but the sibling tool for removal is implied.

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 are minimal (readOnlyHint=false, destructiveHint=false). The description adds useful info: batch processing is asynchronous, tags are not deleted, and tags must exist beforehand. However, it does not cover error handling or reversibility.

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 fairly concise with bullet points. It front-loads the purpose and adds necessary details without excessive verbosity.

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 moderate complexity, the description covers batch processing, async behavior, and prerequisites. But it omits error handling, response format, and the contradiction about 'action' parameter.

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 explain parameters. It explains case_ids and tag_ids well (how to get them, batching). However, it implies a non-existent 'action' parameter, which contradicts the schema and could mislead the agent.

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 applies or removes tags, but the tool name and flattened action indicate only removal. This ambiguity confuses the agent about the tool's actual function. It distinguishes from sibling astrea_etiquetar_aplicar, but the dual-action description is misleading.

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 some context (use for batch classification/hygiene) but does not explicitly direct when to use this tool over the applying sibling. The mention of both actions without clear separation weakens 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 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 provide safety profile (non-readOnly, non-destructive). Description adds behavioral traits: 'altera no lugar, sem duplicar' (in-place update) and bulk support, which enrich understanding beyond annotations. 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?

Three short, front-loaded sentences. First sentence states purpose and key behavior, second lists parameters with hints, third introduces bulk support. No redundancy, 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?

Covers identification, update fields, and bulk support, but no output schema and description does not mention return values or error conditions. For its complexity, a statement on success response would improve completeness.

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

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

Schema coverage is 0%, so description carries full burden. It explains task_id, case_id, description, due_date (with format hint), responsible_id, and bulk variants (task_ids, case_ids, responsible_ids). All parameters are covered except a minor lack of explicit detailed explanation for plural fields, but still highly informative.

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 'Edita uma TAREFA existente no Astrea (altera no lugar, sem duplicar)', specifying the verb (edit), resource (existing task), and key behavior (in-place). This distinguishes it from siblings like 'astrea_tarefa_criar' (create) and 'astrea_tarefa_excluir' (delete).

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?

Description indicates usage for editing an existing task, requires task_id from astrea_tarefa_criar, and responsible_id from astrea_responsaveis. It says 'Informe ao menos um campo para mudar', but lacks explicit when-not-to-use or alternatives. Context is clear but not exhaustive.

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?

Annotations show idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that it handles authentication and token management, explaining different behaviors based on parameters (with token vs without). It does not contradict annotations and provides helpful context beyond the structured fields.

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 informative but slightly verbose (three sentences). It front-loads the purpose and then details usage. Every sentence adds value, though it could be tightened slightly.

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 simple tool (one optional param, no output schema), the description covers all three authentication modes comprehensively. It explains what to expect and how to use it, making it complete for its complexity level.

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 schema has 0% description coverage for the 'token' parameter. The description explicitly explains the token parameter: it is a JWT from browser login, optional, and omitting it returns a login link. This adds full meaning beyond the schema.

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

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

The description clearly states the tool authenticates users for MCP.AI IDE agents. It specifies the verb (log in, authenticate) and resource (token/session). It distinguishes itself from sibling tools by its unique authentication purpose, especially given the diverse sibling names (astrea_*, connect, etc.) which are unrelated.

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

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

The description provides explicit usage scenarios: adding token to config for permanent access, pasting token for session login, or calling with no args to get the login link. It lacks explicit when-not-to-use guidance, but the context is clear and covers the main use cases.

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; description adds specifics about return values in different states.

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 front-loading the purpose and covering key behaviors 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?

Simple tool with no parameters or output schema; description adequately explains return values for both success and missing credentials 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?

No parameters, schema coverage 100%, baseline 4 applies.

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

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

Clearly states it returns connection status and URLs. Distinguishes from siblings like 'authenticate' and 'toolkit_info' by focusing on status check.

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?

Implied usage: check connection status. No explicit when-not-to-use or alternatives, but context makes it clear.

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

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

Beyond the annotations (readOnlyHint=false), the description discloses key behavioral traits: invoke works even when the MCP is not installed, runs one-off without bloating the toolkit, returns a connect link if credentials are needed, and returns a checkout/top-up link if payment is required. It also explains installed flags, write permission requirements, and the one-off install behind invoke. 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 dense but well-structured, starting with the core definition, then flowing through the core search→describe→invoke path, key invoke behaviors, install vs. invoke trade-off, list_tools, billing, permissions, and the prompt library. Every sentence adds meaningful information without fluff, and the logical progression aids comprehension.

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 high complexity (23 params, 14 actions, no output schema), the description covers the core workflows, permissions, pricing/link behaviors, and the prompt library fairly completely. It omits minor details like the 'resume' action or specific use of 'conversation', but the main scenarios an agent would encounter are addressed, making this a genuinely complete description for a multiplexed 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?

With schema description coverage at 0%, the description carries the burden for parameter meaning. It explains the central action-driven params (action=search/describe/invoke/install, mcp_id, tool_id, arguments) and prompt-related params (prompt_slug, prompt_vars, prompt_body). However, several params like 'immediate', 'cancel_reason', 'report_context', 'conversation', and 'tier_slug' are not explicitly described, leaving some 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 opens with a clear definition: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It specifies concrete capability requests ('find an MCP that does X', 'consulta um CPF', 'is there a tool for Y') and walks through the core flow, making it unmistakably distinct from the astrea_* 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 provides explicit when-to-use guidance: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', and 'list_tools lists what is callable right now.' It also names alternatives (search→describe→invoke) and notes permission requirements for writes, giving the agent clear decision rules.

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 idempotentHint=true and destructiveHint=false, so the description adds context about what to include (conversation array) and the types of feedback accepted. 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?

Two sentences: first states purpose, second provides critical usage hint. Every word is informative and no waste. Perfectly concise and 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?

For a simple bug report tool with annotations, the description covers purpose and key usage hint. It could mention the expected outcome (e.g., ticket created) since no output schema exists, but this is a minor omission.

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 clarifies that 'conversation' should contain recent messages for reproduction, and 'message' is the bug report text. However, the 'context' parameter is left unexplained, leaving a gap.

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 reports bugs, missing features, or feedback. 'Report a bug' is a specific action on a specific resource type, distinguishing it from all sibling tools which are about legal case management.

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 tells the agent to 'Include the conversation array with recent messages for reproduction,' which guides proper usage. However, it does not provide when-not-to-use guidance or alternative tools, but given no similar sibling, this is sufficient.

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, so the safety profile is covered. The description adds the specific items shown (platform and adapter versions), which is useful context beyond annotations. A score of 4 reflects this added 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 a single sentence with no extraneous information. It is concise and front-loaded with the action and result.

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 simplicity of the tool (no parameters, no output schema, low complexity), the description is complete. It clearly conveys what the tool does without needing additional context.

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

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

There are zero parameters, and schema description coverage is 100%, so the schema fully defines the input. The description adds no parameter details, which is appropriate since none exist. Baseline 4 for no 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 the tool shows current MCP platform and adapter versions. It uses a specific verb ('Show') and specifies the resources ('MCP platform and adapter versions'), making it unambiguous and distinct from sibling tools like 'toolkit_info'.

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 implicitly indicates usage for checking version information, but does not explicitly state when to use it versus alternatives. However, given the tool's simplicity and lack of parameters, the implied usage is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds what the return value includes (installed MCPs, connection status, accounts, catalog tool counts), which gives the agent a concrete picture of behavior beyond the annotations. 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 a single sentence with front-loaded verb 'Returns' and a clear list of content. Every word earns its place; no fluff 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?

This is a simple read-only tool with no parameters and rich annotations. The description covers the main return categories (MCPs, connection status, accounts, catalog tool counts) in enough detail for an agent to invoke it appropriately. It does not specify the exact data structure (e.g., JSON vs. text), but for this tool that is not a critical gap.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly focuses on what the tool returns rather than parameter handling, and no parameter information is needed.

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 'Returns the current toolkit state' with specific detail: installed MCPs, connection status, accounts, and catalog tool counts. This distinguishes it from siblings like show_version (which likely returns just version info) and marketplace/connect (which handle discovery/authentication).

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 checking toolkit status but does not explicitly state when to use this tool versus alternatives like show_version or marketplace. No exclusions or alternative guidance is provided, but the purpose is clear enough that the intended use is reasonably inferred.

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