Astrea (Aurum)

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description carries a lower burden. It adds that the tool retrieves activities (HEARING, EVENT, DEADLINE, TASK) in a date window, but does not disclose potential limitations, pagination, or return format. This provides moderate context beyond annotations.

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

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

The description is relatively concise at a few sentences, front-loading the purpose and activity types. The inclusion of both 'global' and 'por_cliente' actions is slightly redundant since the tool only supports global, but it helps differentiate from the sibling. Could be further streamlined, but is not overly verbose.

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

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

The tool has no output schema, so the description should hint at the return structure. It only lists activity categories but not fields like date, type, or ID. Given the simplicity of the tool (a date-filtered list), the description is adequate but incomplete for a full understanding of the response format.

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 0% description coverage, so the description must compensate. It does so by explaining the date_from/date_to parameters require the format 'AAAAMMDD' (YYYYMMDD) and define a date window ('janela de datas'). This adds meaningful context that the raw schema lacks, effectively making the parameters understandable.

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

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

The description clearly identifies the tool as Astrea's office agenda, listing activity types (hearings, events, deadlines, tasks). It specifies the 'global' action retrieves all activities in a date window, distinguishing it from the sibling 'por_cliente' variant. However, mentioning both actions in the same description introduces slight ambiguity, as the actual tool only implements the global action.

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

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

The description implies that for global (all activities) filtering, use this tool, and for grouping by client, use the sibling 'astrea_agenda_por_cliente'. This is implied through naming and the action descriptions, but there is no explicit 'when to use' or 'when not to use' guidance. The guide is adequate but could be more direct.

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

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

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: it retrieves activities in a date range, groups by client, and unlinked activities go under '(sem cliente)'. 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 well-structured with a brief introduction, a bullet-like list of activity types, and an explanation of actions. It front-loads the purpose and is reasonably concise, though slightly verbose.

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 list tool with two required params and no output schema, the description is sufficiently complete. It explains the scope (date range), grouping (by client), and handling of unlinked activities. Could mention what fields are returned, but not essential.

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, but the description specifies the date format (AAAAMMDD) and purpose for date_from and date_to. This compensates partially, though it could provide more detail on expected input formats or bounds.

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 retrieves office agenda (hearings, events, deadlines, tasks) grouped by client. It distinguishes between global and per-client actions, and the flattened action indicates this tool is specifically for per-client grouping, differentiating it from the sibling astrea_agenda_global.

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 and per-client actions, implying when to use each. It mentions the per-client grouping and process linking. However, it does not explicitly state to use astrea_agenda_global for unfiltered date-range view, leaving some inference to the agent.

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 it is a write operation (readOnlyHint=false) and not destructive. Description adds that it accepts HTML in description and supports bulk via case_ids, which goes 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?

Front-loaded with purpose, then parameter details in bullet points. No unnecessary words. Efficient and scannable.

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?

Describes input well but does not mention any return value or confirmation of success. With no output schema, a brief note on what happens after creation (e.g., returns created record ID) 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?

Despite 0% schema coverage, the description explains all three main parameters: case_id, description (HTML accepted), date (ISO format optional), and bulk via case_ids. Adds meaningful semantic context missing from 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?

Describes the tool as manually registering an event/history entry in a process, explicitly distinguishing from automatic tribunal capture. The verb 'lançar' and resource 'andamento (histórico)' are specific and 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?

States it is for manual entries and not automatic capture, providing context for when to use. Does not explicitly exclude sibling tools like listing (astrea_andamentos) but the purpose 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 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?

Discloses that creating is a write operation (consistent with annotations), default duration (30 min), time zone interpretation (UTC), independent repeat occurrences, and bulk execution. 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?

Description is well-structured with bullet points and bolded terms, front-loading the purpose. Each sentence adds value, though it is slightly lengthy. Could be trimmed without losing essential 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 10 parameters, no output schema, and minimal annotations, the description covers all needed context: required fields, defaults, repeat behavior, bulk support, and references to sibling tools (astrea_processos, astrea_responsaveis). Very complete for a creation tool.

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

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

Schema coverage is 0%, so the description must fully explain parameters. It does so comprehensively: case_id, title, start, end, all_day, location, responsible_id, repeat (with count, until, interval, frequency), and bulk arrays. Clarifies implications of omitting responsible_id and repeat structure.

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 'Cria' (creates), the resource 'COMPROMISSO/evento na agenda', and the context 'vinculado a um processo no Astrea'. This distinguishes it from sibling tools like astrea_compromisso_excluir and astrea_tarefa_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?

Provides detailed conditions for parameters like responsible_id, explaining that omitting it may cause the event not to appear in the lawyer's agenda. Also describes repeat behavior and bulk support. However, it does not explicitly state when not to use this tool compared to other agenda 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?

Description says 'Exclui' (deletes), implying destructive action, but destructiveHint: false contradicts this. No details on reversibility, permissions, or side effects beyond deletion. The contradiction reduces trustworthiness.

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?

Short and efficient: single sentence plus bullet list of parameters. No redundant information; 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 essential aspects: purpose, parameter meaning, batch support. No output schema or error handling mentioned, but for a simple delete tool this is acceptable. Missing info on return value 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 coverage, description compensates well: explains appointment_id as the ID from astrea_compromisso_criar and mentions bulk support via appointment_ids. Adds meaning absent from 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?

Clearly states it deletes an appointment/event from Astrea calendar. Provides use case for removing wrong entries and explicitly references sibling tool astrea_compromisso_criar for recreation, distinguishing it from other 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?

Gives specific context: use to remove a wrongly created appointment (e.g., wrong time) and then recreate. Names the alternative tool for recreation. Could be more explicit about when not to use, but adequate for a simple delete tool.

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

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

Annotations already 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that responses are compact to save context and that count is fast, which supplements annotations without contradiction.

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

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

Description is verbose with details about list action and fields that aren't directly relevant for count. The '[Flattened action: count]' marker helps, but extraneous information reduces conciseness.

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

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

No output schema exists, so description should explain return format. It says 'total de processos' but not the exact structure (e.g., integer). Bulk support is mentioned, but missing details on response contents for count.

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 must compensate. It mentions filters (contact_id, tag_id, status) and bulk support (contact_ids, tag_ids), but does not describe limit, top_n, or cursor, which are in schema and may be irrelevant for count. Partial coverage leaves 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?

Description clearly states it's for counting processos, distinguishes from sibling tools like list (pages) and por_cliente (summary). Explicitly says 'count: total de processos... use pra "quantos"'.

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

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

Provides explicit guidance on when to use count ('rápido, use pra "quantos"') and contrasts with list and por_cliente, offering 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 indicate read-only, idempotent, non-destructive. The description adds valuable behavioral context: returns compact responses, only one page (not full scan), lists returned fields. No contradictions.

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

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

The description is overly long due to including actions not belonging to this tool. It could be much more concise by focusing on list functionality. The structure is muddled with mixed actions.

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 list tool with 8 params and no output schema, the description covers pagination, filters, and return fields. However, it fails to distinguish itself from sibling tools and includes irrelevant actions, reducing 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 must explain parameters. It explains filters (contact_id, tag_id, status), pagination (cursor), and bulk support (contact_ids, tag_ids). But it does not explain limit (default 30) or top_n (only mentioned under por_cliente action, not list). Incomplete but partially helpful.

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 the tool lists processos (cases) in Astrea with compact responses. However, it also describes other actions (count, por_cliente, novos_por_mes) that are actually separate sibling tools, creating confusion about the primary purpose.

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 guidance for list (paginate with cursor, one page, filters) but then suggests using the same tool for count, por_cliente, etc., which are distinct sibling tools. This misleads the agent into using this tool for inappropriate actions.

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, so the safety profile is clear. The description adds that responses are 'COMPACTAS pra economizar contexto' and that novos_por_mes respects status. No contradictions, but no significant behavioral disclosure 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 lengthy and includes details about all actions and fields, despite the tool being flattened to 'novos_por_mes'. It is front-loaded with a note about compact responses but then expands extensively. While well-structured with bullets, it includes unnecessary information for the specific tool, reducing conciseness.

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

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

For a tool dedicated to 'novos_por_mes', the description does not specify the output format (e.g., list of months with counts) or which parameters apply specifically (e.g., does it use top_n? it doesn't say). No output schema exists. The description covers multiple actions, making it incomplete for the intended use case. More focus on novos_por_mes behavior and results 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?

Schema description coverage is 0%, so the description must compensate. It explains that list uses contact_id, tag_id, status, and cursor; count uses same filters; por_cliente uses top_n; novos_por_mes respects status. It also mentions bulk support for contact_ids and tag_ids. However, not all 8 parameters are individually described (e.g., limit, cursor, tag_id for this action). The description adds partial value beyond the schema.

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

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

The description lists multiple actions (list, count, por_cliente, novos_por_mes), but the tool name and flattened action indicate it is specifically for 'novos_por_mes'. This dilutes clarity and may confuse the agent with sibling tools like astrea_processos_list, astrea_processos_count, and astrea_processos_por_cliente. The purpose is stated but not distinctively scoped.

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 guidance (e.g., 'pra detalhar chame list com contact_id' for por_cliente) but does not explicitly explain when to use this tool over siblings. For novos_por_mes, it only says 'Respeita o status' and 'Bulk support', lacking direct when-to-use recommendations. Usage is implied but 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, destructiveHint=false. The description adds useful behavioral context: responses are compact, actions respect status, bulk support exists, and por_cliente provides summary without details. 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 front-loaded with the compact response theme and structured by actions with bullet points. It is somewhat lengthy but efficiently conveys multiple action behaviors. Minor redundancy in listing actions that may not all belong.

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

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

Given 8 parameters and no output schema, the description covers actions, fields for list, and bulk support. However, the ambiguity about which actions actually apply to this specific tool reduces completeness. It lacks explicit explanation of return values for each action.

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

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

Schema coverage is 0%, so the description must compensate. It explains cursor for pagination, top_n for por_cliente, and bulk support via contact_ids/tag_ids, but does not detail all parameters like limit or tag_id individually. Partially compensates but leaves 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 lists multiple actions (list, count, por_cliente, novos_por_mes) which suggests a multi-action tool, but the name and sibling tools indicate it is specifically the por_cliente action. The 'Flattened action: por_cliente' note adds ambiguity. The purpose is not sharply defined relative to 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 says 'Respostas COMPACTAS pra economizar contexto' implying a use case for compact results, but it does not explicitly state when to choose this tool over the separate astrea_processos_list, count, or novos_por_mes tools. It does provide some guidance within the por_cliente action description (use list for details).

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 and destructiveHint=false. The description adds value by listing the output fields (id, nome, e-mail) and explaining the 'eu' field, providing context beyond what annotations offer. 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?

Two sentences: first defines the tool, second explains usage. Every sentence adds value, no redundancy, and information is front-loaded.

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

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

Given no parameters and no output schema, the description fully covers purpose, output content, and usage context. No missing information for a simple list tool.

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

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

No parameters in the schema; schema coverage is 100%. The description does not need to add parameter details. 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 office users (members) with id, name, and email. It differentiates by specifying the use case: finding the responsible person's ID before creating tasks/appointments, distinguishing it from sibling tools like astrea_clientes.

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 tells when to use: before creating tasks/appointments with astrea_tarefa_criar or astrea_compromisso_criar, and mentions the 'eu' field marks the integration user. No alternative tools are needed for this specific purpose.

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 present (readOnlyHint=false, destructiveHint=false). Description adds value beyond annotations: explains that omitting responsible_id may hide task from attorney's agenda, and repeat creates independent occurrences. No contradictions.

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

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

Description is concise yet comprehensive. Uses bullet points for clarity, no wasted sentences. 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 all 7 parameters with behavioral details and bulk support. No output schema, but description explains enough for a creation tool. Could mention return value or confirmation, but not essential.

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% (no descriptions in schema). Description fully compensates by explaining each parameter's purpose: case_id, description, due_date, responsible_id, repeat (including subfields). Also notes bulk parameters case_ids and responsible_ids. Adds significant meaning beyond schema.

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

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

Description clearly states it creates a task linked to a process, with specific verb 'cria' and resource 'TAREFA'. Distinguishes from sibling tools like astrea_tarefa_editar and astrea_tarefa_excluir by focusing on creation.

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

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

Provides context for optional parameters like responsible_id (explains behavior if omitted and why it might not appear in agenda) and repeat. Mentions bulk support. Lacks explicit when-to-use vs. alternatives, but context is sufficient given 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 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=true, destructiveHint=false, and idempotentHint=true. The description adds context about the returned data (installed MCPs, connection status, catalog tools) but does not disclose additional behavioral traits beyond what annotations 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 a single sentence that is direct and contains no extraneous information. Every word is necessary and contributes to clarity.

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 return value: installed MCPs, connection status, and catalog tool counts. It is complete for a read-only state tool, though it could optionally mention data structure.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). The description does not need to add parameter information. Baseline for 0 parameters 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 states the tool returns the current toolkit state, specifically listing installed MCPs, their connection status, and catalog tool counts. It uses a specific verb 'Returns' and resource 'toolkit state'. This distinguishes it from sibling tools, which are action-oriented (e.g., create, list, authenticate).

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 checking toolkit state but provides no explicit guidance on when to use this tool versus alternatives like 'show_version' or 'marketplace'. No when-not-to-use or alternative tools are mentioned.

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