Astrea (Aurum)

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

Annotations already indicate read-only and idempotent. The description adds useful behavioral context: it returns specific activity types (HEARING, EVENT, DEADLINE, TASK), requires date parameters in AAAAMMDD format, and produces a list of all activities in the window. This goes beyond the annotations.

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

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

The description is extremely concise with two main sentences and a bracketed note, no redundancy or unnecessary detail. It front-loads the purpose and actions, making it easy to parse.

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

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

For a tool with only two parameters and no output schema, the description covers the essential scope and parameter format. However, it does not mention return value structure, pagination, ordering, or date boundary inclusivity. Complete enough for a simple list tool but could be more thorough.

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 no descriptions for its two parameters. However, the description adds critical meaning: it defines the date format (AAAAMMDD) and states they define a date window. Since schema coverage is 0%, the description compensates effectively.

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 that this tool retrieves all activities (hearings, events, deadlines, tasks) in a date window. It explicitly mentions the 'global' action for unfiltered listing and distinguishes from the sibling tool 'astrea_agenda_por_cliente' which groups by client.

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 guidance: use this tool for unfiltered agenda items in a date range ('global'), and the sibling tool for client-grouped results. The mention of 'global' vs 'por_cliente' actions directly addresses when to use which.

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 the date format (AAAAMMDD) and grouping behavior but does not mention pagination, limits, or error handling. With annotations covering safety, a score of 3 is appropriate.

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

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

The description is structured with bullet points and a clear note about the flattened action. It is informative but could be slightly more concise without losing context.

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 2 string parameters and no output schema, the description explains the grouping logic and date format. However, it does not describe the return structure or pagination, leaving some gaps for an agent.

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

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

Schema coverage is 0%, so description must compensate. It explains that date_from and date_to define the date window and specifies the format (AAAAMMDD), adding meaning beyond the schema's plain string type.

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 office agenda grouped by client, listing activity types (HEARING, EVENT, DEADLINE, TASK). It distinguishes itself from the global sibling by specifying the 'por_cliente' action and explaining how unlinked activities are handled under '(sem cliente)'.

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 that this tool is for client-grouped results while 'global' returns all activities in a date window. However, it does not explicitly state when to prefer one over the other or provide exclusion criteria.

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

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

The description adds context that it's a manual write operation, but beyond annotations (which already indicate non-read-only), it does not disclose side effects, authorization needs, or other behavioral traits. It mentions date omission and bulk support, which are useful.

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 a clear opening sentence and bullet-like parameter explanations. No fluff, but could be slightly better structured with explicit separators.

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 covers purpose and parameters well but lacks information on return values or confirmation of success. It is mostly adequate for a simple 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?

With 0% schema description coverage, the description provides clear explanations for three parameters (case_id, description, date) and mentions bulk support for case_ids. This adds significant meaning beyond the schema's bare 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 tool creates a manual historical entry (andamento) in a process timeline, using specific verbs ('Lança') and resource ('andamento'), and distinguishes it from automatic court capture.

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 explains it's for manual entries and not automatic, but does not explicitly say when to use this tool over alternatives. The bulk support is mentioned, but no 'when-not' 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 declare readOnlyHint=true and idempotentHint=true, making the tool's safety clear. The description adds value by explaining bulk support via case_ids and the distinction between automatic and manual types, which are behavioral details 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 concise (two sentences) and front-loaded with purpose and output fields. No unnecessary words, though it could be slightly more structured.

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 covers return fields (date, type, description, responsible) and bulk support. However, it lacks explanation for the 'limit' parameter and does not mention pagination or error handling, leaving gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies case_ids for batched execution and implicitly explains only_manual via the automatic/manual distinction, but does not address 'limit' or provide full parameter details.

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 'andamentos' (timeline/history) of a process in Astrea, serving as a basis for client reports. It distinguishes from siblings like astrea_processos_list by focusing on historical entries rather than process lists.

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 client reports and explains output fields, but does not explicitly state when to use this tool versus siblings or provide exclusions. Usage context is implied but not definitive.

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. The description adds behavioral context: it returns a compact page, paginates via cursor, and does not scan the entire account. This exceeds the annotation baseline.

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 two sentences, front-loaded with purpose and output fields, followed by pagination instructions and a constraint. No wasted 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?

For a simple paginated list tool with 2 parameters and no output schema, the description is fairly complete: it specifies output fields, pagination mechanism, and scope. Could explicitly mention that following cursors retrieves all pages but is otherwise 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?

Schema coverage is 0%, but the description explains that the cursor is used for pagination ('Pagine com o cursor devolvido') and implies limit controls page size. This adds meaning beyond the schema, though explicit details about limit as number of items would improve clarity.

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 paginated list of clients/contacts with specific fields (id, nome, classificação, tipo, tags). It distinguishes from sibling tools by noting it is a compact page and does not scan the entire account.

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 retrieving a page of clients, but does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling comparisons are made.

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 provide basic hints (readOnlyHint=false, destructiveHint=false). The description adds essential behavioral details: time zone interpretation (UTC), default duration (30 min), behavior of all_day, repeat series with independent events, and the critical note about responsible_id affecting visibility in the lawyer's agenda. This goes well beyond the annotations.

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

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

The description is well-structured: first sentence states the core purpose, then paragraph with parameter details, then a note on bulk support. It is front-loaded and contains no wasted words. However, it could be slightly improved by using bullet lists for parameters to 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?

The tool has 10 parameters (3 required) and no output schema. The description comprehensively covers all parameter behaviors, but it does not mention the return value or response structure (e.g., whether it returns the created appointment ID). For a creation tool without output schema, this omission is a notable 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?

Input schema has 0% description coverage, so the description must carry the burden. It explains every parameter: case_id, title, start, end, all_day, location, responsible_id, repeat (with nested fields frequency, interval, count, until), and bulk variants case_ids/responsible_ids. This adds significant meaning that the schema alone does not provide.

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) and the resource 'COMPROMISSO/evento' (appointment/event) linked to a process in Astrea. It distinguishes from siblings like astrea_tarefa_criar (task) and astrea_compromisso_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?

The description explains parameter usage in detail, including optional behavior (e.g., responsible_id affects visibility, repeat creates independent events). It provides examples and states when to pass specific parameters. However, it does not explicitly contrast with sibling tools like astrea_tarefa_criar for deciding between creating an appointment vs a task.

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 claims deletion (destructive) but annotations have destructiveHint=false, which is a contradiction. No additional behavioral details like irreversibility 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?

Very concise: two sentences plus a bullet. Front-loaded with main action, no fluff. 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?

No output schema, but description does not explain return value or success indication. Missing some context for an agent to know what to expect after execution.

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 bears full burden. It explains appointment_id as ID from astrea_compromisso_criar and clarifies appointment_ids for batch execution, adding significant 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?

Description clearly states it deletes a compromisso/event from Astrea, using verb 'excluir' and specifying resource. It distinguishes from sibling astrea_compromisso_criar by indicating it's for removal and recreation of wrongly created items.

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 gives concrete scenario (wrong hour) and suggests recreating with astrea_compromisso_criar. It also mentions bulk support. Lack explicit when-not-to-use, but 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?

Annotations already declare readOnly, idempotent, non-destructive. Description adds specific returned fields (plan, status, trial days, tenant, profile), providing 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?

Two sentences with no wasted words. Front-loaded with key 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, description fully explains what data the tool returns, making it complete for a simple read-only 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, so schema coverage is 100%. Baseline 4 for zero parameters; description adds no param info but not 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 retrieves office account details including plan, status, trial days, tenant, and profile. It distinguishes from siblings handling agenda, clients, processes, 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?

States 'useful to know which plan the office is on' indicating when to use. No explicit exclusions, but sibling context implies 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 are sparse (all false). The description adds value by stating it's non-destructive, reversible, and async. However, it lacks details on potential side effects, error handling, or authorization requirements, which would be helpful for a batch operation.

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 efficiently structured: a main sentence followed by bullet-point parameter explanations and additional notes on reopening and async behavior. It is not overly verbose but could be slightly more compact.

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 complexity (batch close), no output schema, and minimal annotations, the description covers the main points: purpose, parameters, async behavior, and reversibility. However, it omits the return format, batch size limits, and error scenarios, leaving some gaps for an agent.

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 adds meaning for all three parameters: case_ids (multiple IDs from astrea_processos), conviction_amount (optional value), and unlink_from_court (boolean to detach from court). It explains each parameter's role, though format constraints are not detailed.

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 closes (inactivates) processes in batch, marking them as closed while keeping info available. It distinguishes itself from siblings by emphasizing batch operation and specific use case for portfolio hygiene. However, it could more explicitly contrast with tools like astrea_processo_editar.

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 clear guidance: use for portfolio hygiene to finalize processes. It mentions related tool astrea_processos for obtaining IDs and notes that reopening is done via Astrea screen. It also notes async processing. However, it does not specify scenarios when not to use or 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?

The description discloses asynchronous processing, that removing tags does not delete the tag itself, and that tags must pre-exist. Annotations provide no conflicting signals. This adds value beyond the minimal annotation set.

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 moderately concise with bullet points that improve readability. A small redundancy ('EM LOTE' and 'o lote roda numa só chamada') does not significantly detract.

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 covers essential aspects (batch, async, pre-existing tags) but omits the action parameter, output format, and error handling. Given no output schema, the agent lacks full context for 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 coverage is 0%, so the description provides meaning for 'case_ids' and 'tag_ids' (process and tag IDs). However, it introduces an 'action' parameter not present in the schema, causing inconsistency and incomplete semantics.

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 in batch, but the input schema does not include an 'action' parameter to specify which operation, causing confusion. The existence of sibling tool 'astrea_etiquetar_remover' further blurs the purpose.

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

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

The description provides usage context (batch classification/cleaning) and mentions that tags must exist, but lacks explicit guidance on when to use this tool vs. alternatives like 'astrea_etiquetar_remover', or cases where single operations are preferred.

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. The description adds that removal does not delete the tag itself, only the association, and notes asynchronous processing. This provides valuable behavioral 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 concise with bullet-like formatting, covering purpose, action details, and parameter explanations without unnecessary words. It is well-structured and easy to scan.

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

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

The description covers the action, parameters, async nature, and prerequisite that tags must exist. No output schema exists, but for a batch removal tool, the description is sufficiently complete to guide 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 coverage is 0%, so the description compensates by explaining case_ids and tag_ids: 'ids dos processos (ver astrea_processos)' and 'ids das etiquetas (ver astrea_etiquetas)', plus mentioning batch internal splitting. This adds significant meaning.

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 'aplica ou remove etiquetas' in batch, with a clear verb and resource. The tool name and flattened action indicate it's for removal, but the description still mentions both actions, which might cause slight ambiguity. It differentiates from sibling 'astrea_etiquetar_aplicar' by the 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 says 'use para classificar/higienizar a carteira' and mentions prerequisites (tags must exist). However, it does not explicitly compare with sibling 'astrea_etiquetar_aplicar' or specify when to use this tool versus that one. The guidance is implied but not explicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, so safety profile is clear. The description adds value by specifying the returned fields (id, label, cor, restrictions) and the context of use, which is consistent 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, front-loaded with purpose, no wasted words. Efficiently conveys the tool's function and usage context.

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, zero-parameter tool with annotations, the description fully explains what it returns and how it fits into a workflow with sibling tools. Complete and actionable.

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?

Input schema has zero parameters, so description need not explain parameters. Baseline is 4, and no additional parameter info 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 it lists tags with specific fields (id, label, cor, restrictions) and distinguishes from siblings by indicating its use for discovering tag IDs for filtering 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?

Explicitly states when to use (to discover tag IDs) and suggests follow-up actions with other tools. Does not mention when not to use or alternatives, but the guidance is clear and helpful.

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. The description adds that it provides a 'resumo financeiro' and supports bulk execution, which is consistent and adds context about batching behavior without contradicting 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 concise with three sentences: overarching purpose, action list, and bulk support note. It is front-loaded and avoids unnecessary detail, though the action list could be integrated more smoothly.

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 tools's complexity (2 parameters, no output schema), the description provides adequate input context (case_id or case_ids) and basic output nature (financial summary). However, it lacks details on specific fields returned for despesas, unlike the honorarios action which lists fields. This leaves some 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 coverage is 0%, so the description must compensate. It mentions case_id (implied by 'processo') and case_ids (bulk support) but does not provide detailed semantics like format or restrictions. It adds value beyond the raw schema but could be more specific.

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 ('Resumo financeiro') for a process, specifically for despesas (expenses) as indicated by '[Flattened action: despesas]'. The sibling tool astrea_financeiro_honorarios handles honorarios, so the distinction is clear, though not explicitly stated.

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 mentions bulk support via case_ids, which is a usage guideline, but it does not provide explicit when-to-use versus alternatives. The distinction from honorarios is implied by the actions list but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds behavioral context by specifying the fields returned (totalAmount/totalReceived/totalOpen) and mentions bulk support, which goes 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 moderate length but includes extraneous information: it lists both honorarios and despesas actions, only to clarify that the tool is flattened to honorarios. This could be more concise and front-loaded with the key purpose.

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 an output schema, the description partially covers return values (totalAmount/totalReceived/totalOpen) but does not explain the response structure for bulk queries or the format of the data. The inclusion of an irrelevant sibling action (despesas) detracts from 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 must compensate. It explains that case_ids allows for batched execution, adding meaning to that parameter. However, it does not describe the required case_id parameter beyond its existence in 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 states 'Resumo financeiro de um processo no Astrea' and specifically 'honorarios: honorários do processo' with fields, indicating it provides a financial summary for honorarios. It distinguishes from the sibling 'astrea_financeiro_despesas' by focusing on honorarios, though it also mentions despesas without clarifying that it's flattened to honorarios.

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

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

The description says 'use para "valor de êxito"' suggesting a specific use case, but it does not explicitly state when not to use this tool or mention the sibling 'astrea_financeiro_despesas' as the alternative for despesas. The inclusion of despesas in the actions section is misleading given the flattened action.

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 the read-then-write behavior: 'Lê o processo atual e regrava preservando o resto (só muda o que você informar)'. Also mentions bulk support via case_ids. 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?

Three concise sentences: purpose, editable fields, alternative tools, and bulk support. Front-loaded with key 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?

Covers input behavior and alternatives well, but lacks information about return values or error handling. Given no output schema, this is a minor gap.

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

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

With 0% schema coverage, description explains the two main parameters (objeto, conviction_amount) and the bulk parameter case_ids, adding context 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?

Description clearly states it edits fields of a process in Astrea, specifying the editable fields (objeto, conviction_amount) and distinguishing 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 explains when to use: only to edit specific fields, preserving other data. Also directs users to alternative tools for encerrar/reativar or etiquetar.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds 'Respostas COMPACTAS pra economizar contexto' and 'rápido', which are behavioral traits. However, it does not describe the response format (e.g., returns a single number) or whether filtering by status is respected. The extra actions in the description also add irrelevant behavioral details.

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

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

The description is overly long and includes documentation for multiple actions (list, por_cliente, novos_por_mes) that are not relevant to this specific tool. The valuable information for count is a small portion, making it inefficient. A concise description focused only on count would improve clarity and save tokens.

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 complexity (8 params, no output schema, multiple sibling tools), the description lacks completeness. It fails to specify the response structure for count (e.g., a count number), how to handle pagination (cursor, limit) for count (which may be irrelevant), or the exact effect of filters like tag_ids and contact_ids. The inclusion of field descriptions for list adds noise without benefit.

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 8 parameters with 0% description coverage. The description explains filters: contact_id, tag_id, status, and cursor (for pagination, though count may not paginate). It does not explain limit, top_n, contact_ids, tag_ids, or how they apply to count. top_n is mentioned only under the por_cliente action, which is misleading for this tool. With low schema coverage, the description fails to provide sufficient parameter semantics.

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 'count: total de processos (mesmos filtros) rápido, use pra "quantos"' which clearly identifies the tool as a count endpoint. However, the inclusion of other actions (list, por_cliente, novos_por_mes) in the same description creates ambiguity and could mislead the agent into thinking this tool handles multiple operations. The '[Flattened action: count]' note partially resolves this but the extra text is unnecessary.

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 advises 'use pra "quantos"' to indicate when to use the count tool. It also implicitly contrasts with list (for detail) and por_cliente (for per-client summary) by mentioning those actions. However, it does not explicitly direct the agent to sibling tools (astrea_processos_list, etc.) for those operations, nor does it explain when not to use count (e.g., when paginated results are needed).

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. The description adds behavioral traits: responses are compact, list returns one page (not full scan), paginate with cursor, and bulk support via contact_ids/tag_ids. 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 informative but includes extraneous details about other actions (count, por_cliente, novos_por_mes) that are not part of this tool, adding unnecessary length. Could be more focused on only the list action.

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

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

No output schema, so description explains return fields per process. It covers pagination, filters, bulk support, and field notes (e.g., convictionAmount only when filled). Missing orders or error behavior, but sufficient for a 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?

Schema has 0% description coverage, so description must explain parameters. It explains limit, cursor, status, tag_id, contact_id, and mentions contact_ids/tag_ids for bulk. top_n is mentioned but context is unclear (belongs to sibling). Overall covers most parameters adequately.

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 lists processes (cases) with pagination and filters, and clarifies 'Flattened action: list'. However, it also lists other actions (count, por_cliente, novos_por_mes) that belong to sibling tools, creating potential confusion.

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 guidance for using list with pagination and filters, and suggests using contact_id for detailed lookup. It mentions alternatives like por_cliente for summaries, but these are not actions of this tool, muddling the 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the agent already knows. The description adds minor behavioral context: 'Respostas COMPACTAS pra economizar contexto' and 'Bulk support'. No contradictions. However, it does not explain pagination behavior or response format beyond that.

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

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

The description is overly verbose, listing actions and fields irrelevant to the novos_por_mes tool. It is not front-loaded with the specific action's details. The '[Flattened action: novos_por_mes]' helps but does not compensate for the extraneous content. Every sentence does not earn 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 8 parameters, 0 required, and no output schema, the description should explain return values and parameter usage. It only states that novos_por_mes returns 'nº de processos novos por mês' without format details. It lacks completeness for an agent to correctly invoke the tool and interpret results.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions that novos_por_mes respects status and that bulk support accepts contact_ids and tag_ids, but it fails to explain other parameters like limit, top_n, cursor, or how they affect the novos_por_mes action. The parameter semantics are severely incomplete.

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

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

The description does specify the action 'novos_por_mes' and states it returns the number of new processes per month. However, it also lists multiple other actions (list, count, por_cliente) which dilutes focus and could confuse the agent about which action this tool performs. The tool name and flattened action label help, but the purpose is not sharply defined.

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 mentions 'Bulk support' and 'Respeita o status' but does not explicitly state when to use this tool versus siblings like astrea_processos_list or astrea_processos_count. It lacks guidance on prerequisites, alternatives, or exclusion criteria. The agent is left to infer usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context like 'Respostas COMPACTAS pra economizar contexto' and field definitions for list, but conflates actions without a clear action parameter, reducing clarity. 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?

Long description mixing multiple actions and field details, with a redundant 'Flattened action' note. Not front-loaded for quick parsing; contains unnecessary detail for a single-purpose tool.

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

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

No output schema; description partially covers list return fields but leaves por_cliente response vague ('qtd + soma do valor da causa'). Missing action selection and pagination details for the primary action. Incomplete for effective agent use.

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; description mentions some parameters (contact_id, tag_id, status, top_n, cursor) but omits critical ones like an action selector. The bulk support mention (contact_ids, tag_ids) helps but does not map to the defined actions.

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

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

The description lists multiple actions (list, count, por_cliente, novos_por_mes) but claims 'Flattened action: por_cliente', creating ambiguity about the tool's primary function. It does not clearly distinguish itself from sibling tools like astrea_processos_list or 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?

Implies usage via action descriptions but provides no explicit when-to-use or when-not-to-use guidance. Mentions calling 'list with contact_id' for details, but does not clarify which action this tool itself performs or how to select an action.

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?

Anotações já indicam readOnlyHint=true e destructiveHint=false. A descrição adiciona que o campo 'eu' marca o usuário da integração, o que é útil. Não há contradições, mas não detalha outros comportamentos além do já coberto por anotações.

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?

Duas frases diretas, sem redundância. A primeira estabelece o que a ferramenta faz, a segunda o contexto de uso. Frente-carregada e eficiente.

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?

Para uma ferramenta sem parâmetros e com anotações abrangentes, a descrição cobre completamente o propósito, uso e informações de saída. Nenhuma lacuna significativa.

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?

Nenhum parâmetro no schema (cobertura 100%), baseline 4. A descrição explica os campos retornados (id, nome, e-mail, 'eu'), adicionando valor além do schema vazio.

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?

Especifica que lista membros do escritório com id, nome, e-mail, e indica o propósito de obter o id do responsável antes de criar tarefa/compromisso. Distingue-se bem dos irmãos pela finalidade clara.

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?

Explica explicitamente quando usar (antes de criar tarefa/compromisso) e como usar (para definir responsible_id). Menciona ferramentas irmãs relevantes (astrea_tarefa_criar, astrea_compromisso_criar) e o significado do campo 'eu'.

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 key behaviors beyond annotations: task is linked to process, repeat creates independent tasks, responsible_id omission may hide from agenda, and bulk support. 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?

Well-structured with bullet points and clear, concise sentences. No wasted words; every sentence adds value. Examples and ISO format are briefly mentioned without clutter.

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 necessary aspects: purpose, parameters, special behaviors, bulk support, and dependencies on other tools (astrea_processos, astrea_responsaveis). Appropriate for a creation tool with no output schema.

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

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

The description adds rich meaning for all 7 parameters, including examples (ISO date, frequency enum) and critical context (agenda visibility for responsible_id). This far exceeds the schema's minimal type information.

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 task linked to a process. It differentiates from siblings like astrea_compromisso_criar and astrea_andamento_criar by focusing on tasks and providing specific parameter guidance.

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 on when to use (creating tasks) and notes about responsible_id affecting agenda visibility. However, it does not explicitly list alternatives or when not to use this tool compared to 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?

The description discloses key behavioral traits: it modifies in place ('altera no lugar, sem duplicar') and supports batch execution ('Bulk support'). This adds value beyond annotations (which show false for all hints) without contradiction.

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

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

The description is relatively concise, front-loaded with the main purpose, and uses a list structure for parameter guidance. It could be slightly more structured (e.g., bullet points) but is efficient overall.

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 complexity (8 parameters, no output schema), the description covers core functionality and bulk usage. However, it lacks information on error handling, prerequisites (e.g., task must exist), or idempotency implications, leaving some gaps for an agent.

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 compensates by explaining the roles of task_id, case_id, description, due_date (with format hint), responsible_id, and the plural forms for bulk. Not all parameters are detailed, but the most important ones are clarified.

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 an existing task ('Edita uma TAREFA existente') and distinguishes from sibling tools like astrea_tarefa_criar and astrea_tarefa_excluir by specifying 'altera no lugar, sem duplicar'.

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 that at least one field must be provided and lists the parameters for locating and updating. It mentions bulk support but does not explicitly state when to use this tool versus alternatives or when not to use it.

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 states the tool deletes (destructive action), but annotations set destructiveHint=false, creating a direct contradiction. Additionally, no side effects, irreversibility, or error conditions are disclosed. The contradiction severely undermines trust.

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 the main purpose, followed by concise parameter details and batch support note. No unnecessary words; every sentence serves a purpose. The structure is efficient and easy to parse.

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

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

The tool has no output schema and the description does not explain return values, success/failure indicators, or error handling. Given the contradiction in annotations, the description is incomplete for a delete operation that should clarify consequences. It covers basic usage but lacks surrounding 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?

Schema coverage is 0%, so the description provides all parameter meaning. It explains that task_id comes from astrea_tarefa_criar, case_id locates the task, and that task_ids/case_ids enable batch execution. While the batch behavior is underspecified, the explanation adds substantial value beyond the schema.

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

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

The description clearly states the tool deletes a task ('Exclui uma TAREFA do Astrea'), specifying the resource and action. It distinguishes from sibling tools like 'astrea_tarefa_criar' and 'astrea_tarefa_editar', making the purpose unambiguous.

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

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

The description explains parameter usage (task_id from create, case_id for locating) and mentions bulk support. It provides clear context for when to use the tool, though it does not explicitly state when not to use it or list alternatives. This is acceptable given the tool's specific delete function.

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 behavioral traits beyond annotations: token can be non-expiring if added to config, or session-only if passed as argument. Annotations already indicate idempotent and non-destructive; description adds context about persistence.

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 somewhat verbose, containing multiple instructions in a single block. Front-loaded with target audience, but could be more concise. However, all information is relevant.

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 one optional parameter, no output schema, and annotations covering safety, the description provides a complete picture of the authentication flow, covering both setup and invocation. Leaves no major gaps.

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 fully compensates by explaining the 'token' parameter is a JWT, how to obtain it, and the effect of passing vs not passing it. This adds crucial meaning missing from 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's purpose: authentication via browser login with token, specifying it's for IDE agents. It distinguishes itself from sibling tools that are unrelated to 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?

Provides explicit guidance on two usage modes: adding token to config for permanent access, or pasting token for session-only. Explains when to call with token argument vs no arguments. No alternatives needed as this is the sole auth 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 read-only, idempotent, non-destructive. Description adds valuable context about return values in different states (authenticated vs. pending/connect_url).

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, no unnecessary words, clearly structured with conditional behavior.

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, parameterless status tool with no output schema, the description covers the essential return information based on connection state.

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, so schema coverage is 100%. Description does not need to explain parameters; baseline 4 for zero 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 returns connection status and URLs, and distinguishes behavior based on whether all providers are connected versus missing credentials.

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?

No explicit guidance on when to use this tool versus alternatives like 'authenticate' or 'toolkit_info'. The context is implied but not stated.

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 provide minimal behavioral info (non-read-only, open world, non-idempotent, non-destructive). The description adds critical context: write operations require owner/admin, invoke works even if MCP not installed, returns connect/checkout links for credentials/wallet issues. 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 well-structured with clear sections (core flow, key points) and front-loaded with purpose. While detailed (multiple paragraphs), every sentence adds value. Slightly verbose but appropriate for the tool's complexity.

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 core flow, permissions, edge cases (connect, checkout), and contrasts invoke vs install. However, lacks parameter-level detail and does not explain output (no output schema). For a complex 13-parameter tool, it is reasonably complete but has notable gaps.

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 parameter descriptions). The description explains the high-level flow and action enum but does not elaborate on individual parameters like query, limit, mcp_id, tool_id, arguments, etc., leaving many parameters undocumented. Given the 13 parameters, this is a significant 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 identifies the tool as the official MCP marketplace and catalog, with a specific verb 'marketplace' and resource 'MCPs/tools'. It distinguishes from sibling tools (e.g., astrea_*, authenticate) by stating it is the first tool to use for discovering and running capabilities.

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 this tool (first, before external registries) and provides detailed guidance on actions (search, describe, invoke vs install, subscribe/cancel, etc.). Includes when-not-to-use (e.g., prefer invoke over install for one-off use) and 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 indicate idempotentHint=true, but the description implies each call creates a new report (non-idempotent). No additional behavioral context is provided (e.g., whether duplicates are checked, or side effects). The description does not clarify the idempotency 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?

Two concise sentences: first defines the purpose, second gives a critical instruction. No unnecessary words, front-loaded with key action.

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 no output schema, the description provides basic functionality but lacks details on return value, error handling, and exact parameter formats, leaving some gaps.

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

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

Schema coverage is 0%, so the description must compensate. It mentions the 'conversation' parameter but does not specify its format (JSON array?) or explain the 'context' parameter. The required 'message' is implied but not detailed.

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 sends feedback, and instructs to include the conversation array for reproduction. It is distinct from sibling tools which focus on legal/finance/agenda operations.

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 does not explicitly state when to use this tool versus alternatives. While sibling tools are in different domains, no direct guidance is given about when not to use or preferred contexts.

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, which fully cover the safety and idempotency profile. The description adds that it shows versions, which is consistent and provides minimal additional behavioral context. 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 of 11 words, front-loaded with the action and result. Every word earns its place; no verbose or repetitive content.

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 is simple with no parameters and good annotations. The description (showing versions) sufficiently explains what the tool returns. No output schema exists, but the expected output is clear enough for an agent to interpret. Complete for its 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?

There are zero parameters, and schema description coverage is 100%. The description does not need to add parameter information. A baseline of 4 is appropriate for a parameterless 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 states the tool's purpose: 'Show the current MCP platform and adapter versions.' It uses a specific verb ('show') and resource ('versions'), and distinguishes itself from sibling tools like 'toolkit_info' or 'astrea_' by focusing on the MCP platform.

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 no explicit when-to-use or alternatives are mentioned, the tool's purpose is straightforward—displaying version information. The context implies it should be used when version details are needed, and no exclusions are necessary. The simplicity and uniqueness of the tool make the intention 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, making the safety profile clear. The description adds value by specifying exactly what state information is returned (installed MCPs, connection status, catalog tool counts), going beyond the annotations.

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

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

A single, well-structured sentence that front-loads the core action and resource. Every part of the description is meaningful and concise.

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 read-only tool with no parameters and no output schema, the description adequately explains what it returns (installed MCPs, connection status, catalog tool counts). It is complete and leaves no obvious gaps.

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 per the guidelines baseline is 4. The description does not need to add parameter semantics, and the schema is properly empty.

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 'current toolkit state: installed MCPs, their connection status, and how many catalog tools each exposes.' It uses a specific verb ('Returns') and resource, distinguishing it from sibling tools which are domain-specific or authentication-related.

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 suggests use when an overview of the toolkit state is needed. No explicit when-not or alternatives are provided, but the context is clear given no similar info tools among siblings.

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