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?

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

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

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

The description is long but densely organized: primary buscar behavior first, then alternatives, caveats, and field lists. Every section adds operational value, and important warnings like truncado and default All are placed prominently.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beyond the readOnly/idempotent annotations, it discloses scan-one-time behavior, default status 'All' including closed cases, pagination/cursor semantics, partial-scan truncation with 'tempo'/'teto_de_paginas' reasons, the 'diga isso ao usuário' instruction, and the fact that convictionAmount only appears when filled. No contradiction with annotations.

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

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

The text is well organized with bullets and front-loaded caveats, but it is long and spends most of its space on operations other than the flattened novos_por_mes action. It is dense and useful, yet not appropriately sized for the specific tool it defines.

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

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

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

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

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

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

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

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

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

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

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

It gives explicit internal routing rules: 'Pra achar UM processo específico use buscar, não pagine list', 'count ... use pra "quantos"', and when a varredura is truncated it says to use count for the exact total or list with filters. It lacks a direct comparison with the sibling astrea_processos_* tools, so it stops short of a 5.

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

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

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

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

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

The bullet structure is readable and information is front-loaded, but the text is long and includes full instructions for multiple actions that may be out of scope for this flattened por_cliente tool. The '[Flattened action: por_cliente]' line is cryptic rather than a clear natural-language statement, so not every sentence earns its place.

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

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

Given the absence of an output schema, the description covers return shapes and edge cases well: encontrados/nao_encontrados/varredura for buscar, truncation semantics with motivo for por_cliente/novos_por_mes, and per-process fields for list. It also tells the agent how to recurse to count or list for exact/partial results. Missing are the meaning of limit and an explicit statement of which action this flattened tool actually executes.

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true 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, idempotentHint, and destructiveHint=false. The description adds what the return value includes (installed MCPs, connection status, accounts, catalog tool counts), which gives the agent a concrete picture of behavior beyond the annotations. No contradictions.

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

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

The description is a single sentence with front-loaded verb 'Returns' and a clear list of content. Every word earns its place; no fluff or repetition.

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

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

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

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

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

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

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

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

The description clearly states the tool 'Returns the current toolkit state' with specific detail: installed MCPs, connection status, accounts, and catalog tool counts. This distinguishes it from siblings like show_version (which likely returns just version info) and marketplace/connect (which handle discovery/authentication).

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

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

The description implies use for checking toolkit status but does not explicitly state when to use this tool versus alternatives like show_version or marketplace. No exclusions or alternative guidance is provided, but the purpose is clear enough that the intended use is reasonably inferred.

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