Projuris ADV

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

Discloses side effects like modifying server config, and explains both modes. However, it doesn't detail error handling or token expiration beyond non-expiring mention.

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 bit verbose with redundant instructions, but organized into two clear methods.

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?

Explains how to obtain a link and token usage, but lacks explicit description of return value for token call.

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

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

Adds meaning to the token parameter by explaining it is a JWT and optional, clarifying its role.

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 is for authentication, providing instructions to log in and obtain a token. Distinguishes itself from other tools by focusing on login.

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

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

Provides explicit guidance on when to use permanent config vs session-only, and how to call with or without arguments.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond the annotations by explaining the two possible response patterns: authenticated with empty pending[], or connection URLs when credentials are missing. This is clear and consistent with the annotations.

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

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

The description is two sentences, front-loaded with the tool's primary purpose, and each sentence adds valuable information about normal and edge-case responses. There is no filler or redundant 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?

For a zero-parameter, read-only status tool, the description covers the main return conditions and introduces the relevant output fields (authenticated, pending, connect_url). Although no output schema is present, the text gives enough context without needing to explain complex parameters.

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 for parameter semantics is 4. The schema fully covers the parameter surface, and the description's focus is appropriately on behavior and output rather than parameter details, which are unnecessary here.

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 the tool returns connection status and URLs, which is a specific verb plus a clear, bounded resource. It also distinguishes this from sibling authentication and query tools by framing it as a read-only status endpoint rather than an action or data query.

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 the appropriate use case: call this to check connection status and discover missing-credential URLs. However, it does not explicitly say when to use this instead of related tools like authenticate or projuris_consulta, nor does it state any exclusions or prerequisites.

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 behaviors: invoke works even when the MCP isn't installed, returns connect/checkout links for auth/payment, and writes require workspace owner/admin. It also flags search/describe's installed_in_toolkit vs workspace distinction. These add context beyond the sparse annotations (no readOnly, no destructive hint), providing a comprehensive behavioral profile. 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 a single dense paragraph block of over 300 words, lacking bullet points or section headers. It front-loads the purpose but then meanders through flows, billing, permissions, and the prompt library without clear structure. While the complexity justifies length, the lack of organization makes it hard to parse, and many sentences could be trimmed or grouped.

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 23 parameters, 14 actions, and no output schema, the description covers the major workflow and edge cases (auth links, payment, permissions, temporary vs permanent install) well. However, the missing parameter documentation is a significant gap that hurts completeness. It would need to at least outline key parameter categories per action to be fully complete, but it does provide substantial behavior 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?

With 23 parameters and 0% schema description coverage, the description must document parameters, but it only indirectly references tool_id and arguments via the flow. It doesn't explain limit, immediate, tier_slug, prompt_* fields, cancel_* fields, or prompt_vars. The description discusses actions at a conceptual level but fails to map parameters to specific actions, leaving agents to guess parameter 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 opens with a clear statement: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It then details the core flow (search→describe→invoke) with specific verbs and scopes. It also distinguishes from siblings by covering actions like search_prompts and request_mcp that are unique to this tool, clearly separating it from the projuris_* and authentication tools.

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

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

The description gives explicit guidance on when to use each action: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', and for request_mcp: 'ask us to build a NEW MCP when nothing fits.' It also contrasts with list_tools ('lists what is callable right now') and explains the prompt library usage. This is clear, actionable direction.

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, so the agent knows this is a safe read operation. The description adds the HTTP method (POST) and the role of 'filtro' as the body, which goes beyond the annotations. However, it does not disclose any additional behaviors like response structure, pagination defaults, or rate limits. It adds some context but not rich detail, so a 3 is appropriate.

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

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

The description is a single, well-structured sentence that conveys the HTTP method, URL pattern, filter body, resource naming convention, and usage rule. Every word earns its place, and it is front-loaded with the core purpose ('Busca genérica'). No fluff.

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 generic nature, the description provides sufficient context: it explains the resource pattern, the filter mechanism, and the condition for use (no named tool). It lacks explicit mention of pagination, but the schema already covers that. Since there is no output schema, the description could have mentioned the response type, but for a generic search tool, this is not critical. The presence of many sibling tools makes the 'use for entities without named tool' instruction crucial, and it is included. Overall, it is fairly complete for its purpose.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'recurso' as a kebab-case resource name with examples, and 'filtro' as the body filter. It does not mention 'pagina' or 'quantidade_registros', but these are common pagination parameters likely understood from their names. The description covers the required parameter and the primary filter, but leaves the optional pagination params undocumented, which is a partial gap. A baseline 3 is fair given the partial compensation.

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's a generic search tool ('Busca genérica') that performs a POST to /<resource>/consulta with a filtro in the body. It explicitly distinguishes itself from siblings by saying 'Use para entidades sem tool de consulta nomeada', making it clear when this tool applies versus the named projuris_consulta_* 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 provides a specific usage guideline: use for entities without a named query tool. It also gives examples of resource names (processo, pessoa, intimacao) and names the HTTP method, which helps the agent understand the invocation pattern. This is explicit and actionable.

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 include readOnlyHint=true, idempotentHint=true, destructiveHint=false, which already communicate safety profile. The description adds the HTTP method (POST) and endpoint, which is useful behavioral context beyond annotations. It implies a read operation despite POST, which aligns with readOnlyHint. No contradictions, no additional behavioral info like filters applicability or response format, but with annotations present, the bar is lower and description credit is reasonable.

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, concise and front-loaded. It states the main action, endpoint, and key parameters without waste. 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?

The tool has no output schema and low param coverage, but the description covers the core purpose, endpoint, and pagination. Sibling tools exist for related queries, but the description provides enough for a basic query tool. It lacks details on the shape of `filtro` or response examples, but for a filter-query tool with read-only annotations, it is sufficiently complete for an agent to invoke.

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 there are 3 parameters, but the description names two parameters (`filtro`, `pagina`, `quantidade_registros`) and explains their roles: `filtro` = criteria per API, pagination with `pagina`/`quantidade_registros`. This adds meaning beyond the schema (which only gives types), but it does not detail the structure of `filtro` or value constraints. Baseline for low coverage is that description must compensate; here it partially does, but incomplete.

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

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

The description clearly states the tool 'Busca Andamentos/movimentações do processo por filtro' (searches process updates/movements by filter), specifying the HTTP endpoint (POST /andamento/consulta-geral). It distinguishes from siblings by mentioning 'andamento' specifically, but does not explicitly contrast with similar consulta tools (e.g., projuris_consulta_processo). Still, the purpose is 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?

The description provides basic usage context: use filters to query, paginate with `pagina` and `quantidade_registros`. However, it does not mention when to use this tool versus alternatives (e.g., when to use projuris_get or projuris_consulta), nor does it state any exclusions or prerequisites. Adequate but lacks explicit 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 this as a safe read-only, idempotent operation. The description adds minor behavioral context by revealing the POST endpoint and the pagination requirement, but it does not explain the response format, error behavior, or whether a filter is required despite zero required parameters in the schema.

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 compact sentence that front-loads the core purpose and then packs the two most important invocation details: the filter parameter and pagination. There is no wasted or repetitive language.

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 filtered query tool, the description covers the essential invocation details: what it searches, how to filter, and how to paginate. There is no output schema, but this is a common search pattern; the description could be more complete about defaults or response structure, but it is not severely underspecified.

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 directly interprets the parameter semantics: filtro holds API-specific criteria, and pagina/quantidade_registros are for pagination. It does not fully detail the filter structure, but given filtro is a free-form object, pointing users to the API criteria is a helpful and appropriate level of detail.

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 action ('Busca' = search), the resource ('Apontamento de horas (timesheet)'), and the method ('por filtro'). It also includes the API endpoint, which removes ambiguity and distinguishes it from sibling tools like projuris_get_apontamento_horas by indicating this is a filtered search operation.

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 clear usage context: this tool is for fetching timesheet records using filter criteria and supports pagination via pagina/quantidade_registros. It does not explicitly name alternatives or exclude when to use get_ vs consulta_, but the filter-specific wording strongly implies the intended use case.

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 this as read-only, idempotent, and non-destructive. The description adds the detail that it uses POST (unusual for a query but relevant for API calls) and explains pagination behavior, providing context beyond the annotations 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 extremely concise—two short sentences—and immediately front-loads the core purpose. It avoids redundancy, only adding essential parameter clarifications. Every word 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 tool has 3 parameters (including a nested object) and no output schema, the description explains the purpose and parameters sufficiently for basic use, but it does not mention what the response contains (e.g., list of assuntos, structure of returned objects). This is a notable gap, as agents cannot predict the return format without additional assumptions.

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

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

With 0% schema description coverage, the description compensates minimally: it identifies 'filtro' as API-defined criteria and explains the pagination parameters. However, it does not elaborate on the structure of 'filtro' (e.g., possible keys or value formats), leaving significant ambiguity for agents unfamiliar with the Projuris API.

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 searches for 'Assuntos/matérias' using a filter, with a specific HTTP method and endpoint (POST /assunto/consulta). The verb 'Busca' plus the resource 'Assuntos' unambiguously distinguishes this from sibling tools like projuris_consulta_processo or projuris_consulta_tarefa.

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 specifies that 'filtro' follows API criteria and that pagination is done via 'pagina' and 'quantidade_registros', implying when to use this tool (search for assuntos). However, it does not explicitly provide exclusions or alternatives, leaving the agent to infer from the name and sibling context rather than receiving direct 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, so the read-only nature is clear. The description adds the POST method and pagination details, providing some context beyond annotations. However, it does not disclose potential rate limits, default values, or response behavior, which are common gaps for a read endpoint. This is adequate but not exceptional, consistent with a score of 3.

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, fitting the essential info into one sentence with backtick formatting for parameters. It avoids redundancy and is easy to scan. Minor deduction for cramming the endpoint into parentheses within a single long sentence, but it remains 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 straightforward query tool with 3 parameters and no output schema, the description covers the basics: purpose, filter semantics, and pagination. However, it omits default values for pagination and any mention of the response shape, which agents may need. This is a minimum-viable description for the tool's complexity, hence a 3.

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

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

Schema coverage is 0%, so the description must compensate. It explains that 'filtro' holds filter criteria per the API and that 'pagina'/'quantidade_registros' handle pagination. While this provides basic meaning, it leaves out the structure of 'filtro' (a nested object) and any default/constraint details, making the guidance incomplete. A score of 3 reflects this partial but not thorough compensation.

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

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

The description uses a specific verb 'Busca' (searches) and a clear resource ('Atendimentos (CRM/relacionamento)'), which precisely states what the tool does. It distinguishes itself from siblings by naming the domain (Atendimentos) and the underlying endpoint (POST /atendimento/consulta). No ambiguity remains about the tool's 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 implies when to use it: to search for Atendimentos by filters, with pagination instructions. It does not explicitly name alternatives or exclusions, but the scope is clear given the many sibling 'consulta' tools. This matches a score 4: clear context without explicit when-not-to-use 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, idempotentHint, and destructiveHint, confirming a safe read operation. The description adds value by explaining the filter semantics and pagination behavior (pagina/quantidade_registros), which are operational details not implied by the annotations alone. It does not contradict 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, compact sentence that front-loads the purpose and includes essential usage details without any redundant or filler content. Every word contributes to the tool's understanding.

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 core aspects of a search tool: purpose, filter usage, and pagination. Since there is no output schema, it might have mentioned the response format, but the description is adequate for an agent to invoke the tool correctly. It is complete considering the tool's simplicity and the annotations.

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

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

Schema description coverage is 0%, so the description must carry the burden. It clarifies that 'filtro' is the criteria per API and that 'pagina/quantidade_registros' are for pagination. This adds meaningful interpretation to all three parameters, though it doesn't specify the structure of the filter object, relying on API reference.

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 searches for contracts (honorários) using a filter, and specifies the HTTP endpoint (POST /contrato/consulta). It distinguishes from sibling tools by naming the specific resource (contratos) and mentioning the filter and pagination parameters, which is unique among the many consulta 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 implicitly tells when to use this tool (for contract searches) and how to use it (via filter and pagination), but does not explicitly mention alternatives or when not to use it. It provides clear context for the search operation, but lacks explicit exclusions or comparisons to sibling consulta 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 declare readOnlyHint, idempotentHint, and destructiveHint, establishing a safe read operation. The description adds useful behavioral context: the exact HTTP endpoint and an explicit pagination mechanism (pagina/quantidade_registros), 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?

The description is a single, information-dense sentence with no redundant content. It front-loads the core purpose and then explains key parameters in a straightforward manner.

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's main complexity lies in the filtro object, which is left undefined ('conforme a API'), creating ambiguity for agents. There is no output schema, and the description does not describe return values. Pagination is covered, but the filter structure and expected response are significant gaps, making it adequate but not 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 clarifies that filtro specifies criteria according to the API and that pagina/quantidade_registros are for pagination. This gives meaning to all three parameters, though the inner structure of filtro remains opaque.

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: 'Busca Intimações/publicações por filtro' (search notices/publications by filter) and provides the endpoint POST /intimacao/consulta. It is distinct from siblings like projuris_get_intimacao, which likely fetches a single record by ID.

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 a filtered search use case via 'por filtro' and mentions pagination, but it does not explicitly state when to use this tool versus alternatives such as projuris_get_intimacao or other consulta tools. No exclusions or alternative tool names are given.

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, covering safety profile. Description adds that it uses POST and pagination, but does not disclose response format, potential errors, or rate limits. With annotations covering safety, a 3 is appropriate for moderate additional 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?

The description is concise and front-loaded: it states the action and endpoint first, then clarifies the `filtro` parameter and pagination. Three sentences, no fluff.

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?

Description covers purpose, endpoint, and pagination, but lacks details on required fields or format for `filtro`, potential error cases, and does not describe return structure (no output schema). Given the tool is a search with nested objects and no schema coverage, completeness is moderate.

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 that `filtro` contains criteria per the API, and discusses `pagina` and `quantidade_registros` for pagination, but does not provide format or examples. This adds some meaning over bare schema, but is insufficient given all parameters are undocumented.

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: searching for persons (clients, parties, lawyers, contacts) using a POST request to /pessoa/consulta, with pagination. It names specific resource types (clientes, partes, advogados, contatos) and distinguishes from siblings like projuris_consulta_processo and projuris_get_pessoa.

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 context that it is a filtered search with pagination, but does not explicitly contrast with alternative search or retrieval tools (e.g., projuris_get_pessoa for direct lookup vs. this for filtered search). Usage context is implied but no exclusions or alternatives are named.

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, covering the safety profile. The description adds the API endpoint (POST /processo/consulta) and pagination behavior, providing useful context beyond annotations. 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 a single sentence, front-loaded with the purpose, and includes the essential usage details (filter and pagination). It has no wasted words and is easy to scan.

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

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

For a search tool with three optional parameters and no output schema, the description adequately covers what it does and how to use it. It could mention the return format (e.g., list of processes), but it's not essential given the purpose is clear.

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 is the only source. It explains filtro as criteria per the API, and pagina/quantidade_registros as pagination. While it doesn't detail the filter structure, it gives basic meaning and direction for all three 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 searches processes/cases (judicial and extrajudicial) by filter, using a specific verb and resource. It distinguishes itself from siblings like projuris_get_processo (which fetches a specific case) and other consulta tools for different entities.

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 when to use this tool: to search by filter criteria, and mentions pagination with pagina/quantidade_registros. It does not explicitly say 'use get_processo for a single case', but the context of searching by filter is clear. It gives adequate 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 readOnly and idempotent hints, so the description need not repeat them. It adds a pagination behavior note ('pagine com pagina/quantidade_registros'), which is useful. However, it does not disclose any other behavioral traits such as default page size or filtering capabilities.

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 concise sentence that packs the purpose, endpoint, and pagination guidance without superfluous content. It is efficiently written, though it could include more detail without becoming 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?

Given the presence of a nested 'filtro' object and no output schema, the description is insufficient. It does not explain how to construct a valid filter or what results to expect, and lacks enough detail to guide an agent in a complex search. The vague 'critérios conforme a API' placeholder does not offer practical assistance.

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 must compensate. It explains that 'filtro' holds API criteria and that 'pagina' and 'quantidade_registros' are for pagination. While this adds some meaning, it is vague and does not detail the structure of the filter object or parameter constraints.

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 is a financial search for revenues and expenses ('Busca Financeiro: receitas e despesas') with a filter, and indicates the HTTP endpoint. It distinguishes from other consulta tools by its target entity (receita_despesa), but does not explicitly contrast with 'projuris_get_receita_despesa' which likely fetches a single record.

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 this tool is for searching with filters and pagination, but it does not explicitly state when to use this tool versus the 'get_receita_despesa' sibling or other consulta tools. Pagination guidance is given, but no exclusions or alternative recommendations are provided.

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 the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by revealing the HTTP method/endpoint (POST /tarefa/consulta-com-paginacao), explaining that 'filtro' accepts API-defined criteria, and noting pagination via 'pagina' and 'quantidade_registros'. This goes beyond the schema and annotations, though it does not discuss rate limits or authentication 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 two concise sentences. The first sentence states the purpose and endpoint, the second explains the key parameters. It is front-loaded with the action and resource, contains no fluff, and every word 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?

For a read-only query tool with good annotations and a simple pagination pattern, the description covers the essential aspects: the task search, the endpoint, the filter concept, and pagination. It does not describe the return format or the structure of 'filtro', but given that no output schema is provided and the tool is a standard search, this is acceptable. It could be more detailed, but it is sufficiently complete for an agent to invoke it correctly.

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

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

The description adds some meaning to parameters: it states that 'filtro' is the filter criteria according to the API, and that 'pagina'/'quantidade_registros' are for pagination. Since the schema has no parameter descriptions (0% coverage), this helps, but the description of 'filtro' is vague ('conforme a API') and does not detail its structure or constraints, so it only partially compensates.

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 function with a specific verb and resource: 'Busca Tarefas' (searches tasks) and specifies the task types (compromissos, prazos, providências). It also names the exact endpoint (POST /tarefa/consulta-com-paginacao), which distinguishes it from sibling tools that target other entities like processos, pessoas, and contratos.

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: it is for searching tasks with filters and pagination. However, it does not explicitly state when to use this tool vs alternatives like projuris_create_tarefa or other consulta tools, nor does it mention any exclusions or prerequisites. The context is clear enough but lacks explicit 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, providing safety context. The description adds operational details (POST method, pagination, filter semantics) that go beyond annotations 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 a single, compact sentence that directly conveys the tool's purpose and key parameters, with no redundancy or 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 search tool with no output schema, the description is sufficient: it identifies the resource type (office users), the filtering mechanism, and pagination, which covers the essential operational context needed by 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 description coverage, the description compensates by explaining each parameter's role: filtro as API-defined criteria, and pagina/quantidade_registros for pagination, offering clear operational meaning despite not detailing the filter object's internal 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 action ('Busca Usuários do escritório por filtro'), specifies the HTTP endpoint (POST /usuario/consulta), and distinguishes from the sibling 'get' tools by emphasizing filter-based search with pagination.

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 mentions pagination parameters and filter criteria, but does not explicitly contrast with alternative tools like projuris_get_usuario, leaving the when-to-use decision partially implied rather than 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?

The description mentions it is a POST (write operation) but adds little beyond the annotations which already indicate readOnlyHint=false. It does not detail side effects, error behavior, or required 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?

The description is very brief and to the point, with no superfluous information. It directly states the action and the key parameter.

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

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

The description is minimal but sufficient for a simple create operation with a single body parameter. However, it lacks details about required data fields or validation criteria, leaving some gaps for the 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?

The schema only exposes a generic 'data' object with no description. The description clarifies that 'data' is the request body per the official API, providing some semantic context but not enumerating expected fields.

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

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

The description clearly states the function: creating an 'andamento' (process movement) via POST /andamento. It distinguishes this tool from sibling create tools for other entities.

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 when creating an andamento, but does not explicitly contrast with other tools or provide when-not-to-use guidance. It is adequate 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=false, destructiveHint=false, and idempotentHint=false, so the write behavior is disclosed without description. The description adds the endpoint and the 'data' body convention, but does not go into auth requirements, error behavior, or return format; with annotation coverage, this is adequate but not rich.

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 short, front-loaded sentences: first the purpose/endpoint, then the key payload instruction. No redundant phrases or filler.

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

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

The tool is a simple passthrough wrapper with one opaque parameter and no output schema; the description covers its purpose and payload pointer. It is not fully self-contained (no official API link, example, or return value details), but it is reasonably complete for a generic create wrapper with annotations.

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 is one parameter, 'data', and although the schema only shows an open object, the description adds semantic meaning by stating that 'data' is the request body 'conforme a API oficial'. This tells the agent to follow the official API contract rather than treating the object as arbitrary, partially compensating for the 0% schema coverage.

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 'Cria' + 'Apontamento de horas (timesheet)' and includes the precise endpoint 'POST /apontamento-horas', so the verb, resource, and operation are specific. The create action is clearly differentiated from siblings like projuris_consulta_apontamento_horas and projuris_update_apontamento_horas.

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

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

The description makes it clear this tool is for creating a timesheet entry and is not a read/update operation; the POST verb and resource provide clear context for when to use it. It does not explicitly name alternatives or set exclusions, 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 adds the HTTP endpoint and clarifies that `data` is the official API body, but it doesn't disclose validation, error/response behavior, or prerequisites. Annotations mark false for read-only and destructive, adding little beyond what the description itself implies.

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 short, front-loaded sentences contain only useful information: what is created, the endpoint, and what `data` represents. No filler or 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?

For a simple one-parameter create wrapper with no output schema, this description is sufficiently complete. Adding more detail about required fields would depend on the external official API, which is reasonably referenced.

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 for the single `data` parameter. Saying `data` is the body per the official API provides essential meaning beyond the bare schema, although it remains open-ended.

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 'Cria um(a) Atendimentos (CRM/relacionamento) (POST /atendimento)', identifying the action and resource. This distinguishes it from sibling consult/get/update tools for the same entity.

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 intended use is clear: create an Atendimento record via POST. It doesn't explicitly name alternative tools, but the create action versus consult/update siblings makes the usage context obvious.

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 mentions the POST method, indicating a mutating operation, which is consistent with the annotations (readOnlyHint=false). However, it provides no information about response structure, error handling, or side effects beyond creation. With annotations present, the description adds minimal behavioral context (the endpoint), but lacks depth.

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, concise sentence that immediately communicates the tool's purpose and the meaning of the parameter. There is no redundant wording, and it is front-loaded with the action verb and resource.

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 create operation with a single complex parameter and no output schema, the description is insufficient. It does not describe the expected return value, authentication requirements, or any behavioral nuances. It relies entirely on the phrase 'corpo conforme a API oficial', which may not be accessible or sufficient for an agent to invoke correctly.

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

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

The description explains that the single parameter 'data' is the request body 'conforme a API oficial' (per the official API), which adds some meaning. However, since the schema provides no field constraints and description coverage is 0%, the description fully relies on external documentation without detailing any required or optional fields, leaving the agent under-informed.

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 action 'Cria' (creates) and the resource 'Pessoas' with specific examples (clients, parties, lawyers, contacts). It also specifies the HTTP method and endpoint (POST /pessoa), effectively distinguishing this from sibling tools like projuris_get_pessoa and projuris_update_pessoa.

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 its use for creating a new person record, but does not explicitly state when to use it over alternatives (e.g., fetching or updating) or mention any exclusions or prerequisites. The context is inferred from the action verb and resource, but no direct guidance is provided.

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 this is a non-read-only, non-idempotent operation, so the description adds the HTTP endpoint and the role of data. It does not describe the response, error behavior, or side effects beyond creation.

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 one short sentence, front-loads the purpose, includes the endpoint, and adds the key parameter hint without unnecessary words. Each phrase carries meaning.

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 operation, endpoint, and role of the data parameter, which is acceptable for a simple wrapper. However, it depends on external knowledge of the official API and does not explain what a valid payload should contain or what happens after creation.

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 description coverage is 0% and the only parameter is a free-form object. The phrase 'data = corpo conforme a API oficial' gives some context that data should be the request body, but it does not compensate for the lack of required fields or payload 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 that this tool creates a Tarefa (task/commitment/deadline/provision) via POST /tarefa. It uses a specific verb and resource, and the endpoint reinforces the operation, distinguishing it from sibling query and update 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?

Usage is implied by 'Cria' and the Tarefa resource, but the description does not explicitly state when to use this tool versus alternative tools such as projuris_consulta_tarefa or other create tools. There are no exclusions or explicit alternativeness provided.

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 this is a mutating, non-idempotent operation, and the description adds little beyond the endpoint and that `data` is the official API body. It does not disclose side effects, authentication requirements, validation behavior, or response/error characteristics.

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 short, front-loaded, and contains no filler; the first sentence states the core operation and endpoint, and the second clarifies the only parameter. 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?

With no output schema, no usage context, and an opaque parameter, the description is insufficient for a tool that creates webhook integrations. It lacks information about return values, prerequisites, or what the agent should do after creation, so it is only minimally viable.

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 only defines an opaque `data` object with 0% coverage, so the description's statement that `data` is the body per the official API provides some meaning. However, it does not enumerate expected webhook fields or give concrete structure, leaving substantial ambiguity for invocation.

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 action ('Cria') and the resource ('Webhooks de integração'), and includes the HTTP endpoint POST /webhook. This distinguishes it from sibling create tools for other entities and from projuris_list_webhook, though the phrasing 'um(a) Webhooks' is awkward.

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 no guidance on when to use this tool versus alternatives such as other projuris_create_* tools or projuris_list_webhook. It does not mention prerequisites, exclusions, or context for webhook creation.

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 description adds little beyond that. It does not mention authentication, error handling, or that the response shape is arbitrary, which would add context beyond annotations. Given the annotations cover 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 two sentences, front-loaded with the tool's purpose, and contains only essential information. No filler words or redundant details.

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 generic REST GET fallback, the description covers the core behavior, usage, and scope. It has no output schema, but the generic nature means the return is variable. It would be slightly improved by noting that the response is untransformed raw data, but the current description is sufficient for the tool's role.

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

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

Schema coverage is 0%, so the description must compensate. It explains that `path` is a resource path (with example) and `query` is optional. However, it does not detail how `query` keys map to URL query parameters, leaving some ambiguity. Still, it adds meaningful context 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 is a generic GET for any REST resource, distinguishing it from the many named sibling tools. It specifies the action (GET), the target (REST resource of Projuris ADV), and the exact use case (resources without a dedicated tool).

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

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

It explicitly says 'Use para recursos sem tool nomeada' (use for resources without a named tool), giving clear when-to-use guidance. It does not explicitly say 'do not use when a named tool exists', but the instruction implies this fallback role. This is clear enough but could be more explicit about preferring specific 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 declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds the HTTP GET path and single-resource-by-code behavior. It does not explain auth needs, response shape, or query behavior, but the safety profile is covered by 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, front-loaded sentence states the action, resource, and endpoint with no filler. Every part contributes meaningful information.

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

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

For a simple classified read, the endpoint and code parameter are provided, but because there is no output schema, return-value expectations are absent, and the 'query' object is undocumented. Adequate but with clear 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 should compensate; it only clarifies that 'codigo' is the lookup key, leaving the optional 'query' object completely unexplained. The schema gives names/types but not 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 uses a specific verb ('Busca') and resource ('Apontamento de horas') with 'por código' as a clear lookup scope, plus the explicit GET endpoint. It differentiates from create/update siblings, but does not explicitly contrast with projuris_consulta_apontamento_horas.

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 context is implied: use this when you have a code to fetch one timesheet. However, there is no explicit when-not-to-use or mention of alternatives like projuris_consulta_apontamento_horas for searching/listing.

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 convey readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is a safe read operation. The description adds the specific endpoint paths and that it is a GED search, but does not disclose details like authentication requirements, rate limits, or what exactly the download endpoint returns (e.g., binary vs metadata). It does not contradict annotations, but adds limited extra context beyond 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 a single sentence that conveys the main purpose and the endpoint. It is concise and front-loaded with the key action, but the inclusion of an endpoint path may be redundant given the resource is already clear. However, no unnecessary fluff.

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 has no output schema, no parameter descriptions in the schema, and the description provides minimal parameter semantics, it is incomplete for an agent to know how to invoke it correctly. The 'query' parameter is completely unexplained, and the download endpoint is mentioned but not detailed (e.g., response format). The description does not cover edge cases like what happens if the code is invalid.

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 burden for parameter semantics. Despite that, the description does not explain the 'codigo' parameter beyond implying it is the code for download, and the 'query' parameter remains completely undocumented. The schema provides property types, but no semantic meaning is added by the description.

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 searches for files/documents (GED) and provides a download endpoint with the code, which distinguishes it from other projuris_get_* tools that target different resources. The verb 'Busca' (searches) and resource 'Arquivos/documentos (GED)' 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?

The description implies usage by providing the endpoint pattern, but it does not explicitly state when to use this tool vs alternatives. It mentions a download endpoint, which suggests usage for retrieving files, but no explicit 'when not to use' or alternative guidance. Since siblings all are projuris_get_* for different resources, the resource specificity is implicit.

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 clear. The description adds the specific GET endpoint and the keyed-lookup behavior, which is mildly useful but does not go beyond annotations with extra context such as auth needs, rate limits, or error behavior. 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 a single sentence, front-loads the purpose, and contains no redundant filler. Every word contributes to the minimal but functional definition.

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

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

For a simple get-by-code tool, the description is adequate, but it has clear gaps: it does not describe the return value (no output schema exists), and it omits the purpose or behavior of the 'query' parameter. With only one of two parameters addressed and no no-output-schema explanation, this is a minimum viable description.

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 that 'codigo' is the primary lookup key and appears in the URL path, but it says nothing about the 'query' parameter, which has a nested object structure and remains entirely unexplained. The compensation is partial at best.

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 a specific action ('Busca'), resource ('Assuntos/matérias'), and lookup key ('por código'), and even provides the endpoint path (GET /assunto/{codigo}). It is distinguishable from broader consulta tools because it targets a single code, though it does not explicitly contrast with sibling tools.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as projuris_consulta_assunto. The phrase 'por código' implies you should use it when you already have the code, but no when/when-not boundaries, prerequisites, or alternative recommendations are provided.

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, so the description's mention of a GET request reinforces but adds little beyond what behaviors are disclosed. It doesn't describe error handling or side effects, but the annotations already cover 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 a single concise sentence that front-loads the purpose and method, with no filler words. It achieves maximum information density.

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?

While it's a simple read-only GET, the description doesn't cover the return format or the query parameter. With two parameters and no output schema, the minimal description leaves gaps, particularly around the query object, making it incomplete for an agent to use without further schema inspection.

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 explain parameters. It mentions 'por código' explaining the 'codigo' parameter but completely ignores the 'query' object parameter. The explanation is partial and insufficient given the low coverage.

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 searches for an 'Atendimentos' (CRM/relationship) by code, specifying the exact HTTP endpoint GET /atendimento/{codigo}. This distinguishes it from other projuris_get_* tools which target different resources.

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 when you have the code but doesn't explicitly compare to siblings like projuris_consulta_atendimento or mention when not to use it. It lacks explicit guidance on selecting between similar lookup 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 declare the tool as read-only, idempotent, and non-destructive. The description adds the HTTP GET method and resource path, which is mildly useful, but it does not disclose additional behaviors such as return format, pagination, or error conditions.

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, compact sentence that communicates the core action, target resource, identifier, and HTTP endpoint with no wasted words or redundant 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 description is sufficient for a basic single-record GET operation, but it leaves gaps: no guidance on the 'query' parameter, no differentiation from the consulta tool, and no indication of what the response contains. It is minimally viable but not richly complete.

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

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

Schema description coverage is 0%, so the description must compensate. It gives meaning to the required 'codigo' parameter ('por código'), but the optional 'query' parameter is completely unexplained in both the schema and the description.

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 action ('Busca'), the resource ('Intimações/publicações'), and the lookup mechanism ('por código'), with the endpoint explicitly shown. It does not explicitly differentiate from sibling tools like projuris_consulta_intimacao, so it misses the top score.

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 phrase 'por código' implies this tool is for retrieving a specific intimação/publicação by its code, providing basic usage guidance. However, it does not state when to prefer this over the consulta siblings or mention any exclusions/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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the HTTP method and endpoint, and clarifies the types of entities covered. It does not disclose rate limits, permissions, or return format, but the annotations cover the safety profile adequately.

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, concise sentence that is front-loaded with the primary action and resource. It includes parenthetical examples and an endpoint without waste.

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

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

The description is reasonably complete for a simple get-by-code operation, with the HTTP endpoint and entity types clarified. However, it omits any mention of the 'query' parameter, which is part of the schema, and does not state what the response contains. For a simple read, it is adequate but not 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?

Schema coverage is 0%, so the description must compensate. It clarifies that 'codigo' is the lookup key via 'por código' and the endpoint, but provides no information about the 'query' parameter (which is optional and not mentioned at all). The description fails to explain a required aspect of 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 operation: 'Busca' (searches) a 'Pessoa' (person) by 'código' (code), with the HTTP endpoint '/pessoa/{codigo}'. It specifies the resource and examples (clientes, partes, advogados, contatos), distinguishing it from sibling tools like projuris_get_processo.

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 phrase 'por código' implies the usage context (when you have a person's code), but there is no explicit guidance on when to use this tool versus alternatives like projuris_consulta_pessoa or projuris_create_pessoa. No exclusions or alternative tools are mentioned.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's 'Busca' and GET method align without contradiction. It adds minimal extra context (e.g., coverage of both judicial and extrajudicial cases) but does not elaborate on side effects, permissions, or response behavior beyond what annotations imply.

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, front-loaded with the core action and endpoint, containing no extraneous words. It is appropriately concise and readable.

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 there is no output schema, the description should at least hint at the return format or included data, but it is silent on that. It also fails to explain the 'query' parameter, leaving the tool's full behavior under-specified 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 description coverage is 0%, so the description must explain parameters. It clarifies that 'codigo' is the search key, but it does not mention the 'query' object parameter at all, leaving a required portion of the schema undocumented and 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 clearly states the tool searches for a Process/case (judicial and extrajudicial) by code, with the specific endpoint 'GET /processo/{codigo}' provided. This gives a specific verb, resource, and scope, distinguishing it from generic search 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 does not provide guidance on when to use this tool versus alternatives such as projuris_consulta_processo or other consulta tools. It only states the action but lacks contextual or exclusionary instructions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the endpoint and the concept of fetching by code, which is consistent with the annotations. However, it does not disclose what is returned (e.g., fields, structure) or any additional behavior like error handling. With annotations covering the safety profile, this is acceptable and 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 a single sentence that conveys the resource, verb, parameter, and endpoint. It is front-loaded and contains no redundant information. Ideal conciseness.

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

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

For a simple read-only fetch-by-code tool, the description is mostly adequate: it names the resource and how to identify it. However, it does not explain the 'query' parameter, and the term 'Financeiro' may be ambiguous without more detail. The presence of a sibling consulta tool and the extra query param would benefit from additional guidance, but the tool is still functional at a basic 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?

Schema description coverage is 0%, so the description must compensate. It does clarify that 'codigo' is the key identifier via 'por código' and the endpoint path. But the 'query' parameter is completely unexplained and remains an opaque object. The description provides partial semantics but leaves one of two parameters undocumented.

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: 'Busca um(a) Financeiro: receitas e despesas por código' with the endpoint 'GET /receita-despesa/{codigo}'. It identifies a specific verb (Busca), resource (Financeiro: receitas e despesas), and parameter (código). However, it does not explicitly contrast with the sibling projuris_consulta_receita_despesa, so it lacks explicit sibling differentiation.

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 guidance is provided on when to use this tool versus alternatives. The description only states what it does, not when to prefer it over consulta_receita_despesa or other list/search tools. There is no mention of 'use when you have a code' or exclusions.

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 the GET method, but does not disclose error behavior, authentication, or return format. It does not contradict 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 a single, front-loaded sentence that states the action, the resource, the parameter, and the endpoint. There is no filler, repetition, or irrelevant detail.

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

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

For a simple read-only get-by-code tool, the description is nearly complete: it identifies purpose, parameter, endpoint, and relies on annotations for safety. The gap is the unexplained 'query' parameter and the absence of return/error details, but the basic call can be made confidently.

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 no field descriptions (0% coverage). The description clarifies that 'codigo' is the lookup value via 'por código' and the endpoint path, but the optional 'query' parameter is not explained anywhere, leaving its meaning and format unclear.

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

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

The description uses a specific verb ('Busca') and a specific resource ('Usuários do escritório') with a precise lookup criterion ('por código'). It also documents the exact HTTP endpoint (GET /usuario/{codigo}), making the purpose unambiguous and distinguishable from consultation/search 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 phrase 'por código' implies that the tool should be used when the caller already knows the user's codigo. However, it does not explicitly contrast this tool with projuris_consulta_usuario or state when not to use it, so the guidance is implicit rather than 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?

The description adds the non-destructive GET endpoint and pagination behavior on top of annotations that already declare readOnlyHint and idempotentHint. However, it does not add richer behavior such as authentication requirements, rate limits, or response shape, so it is adequate but not exceptional.

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 tight sentences with the action and endpoint front-loaded, followed by one short pagination instruction. No filler or redundant restating of structured data.

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 operation with strong annotations, the description is nearly sufficient, but the optional nested 'query' parameter is completely uncharacterized and there is no output schema to clarify the return shape. This leaves meaningful 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 description coverage, the description must compensate. It tells the agent that pagina and quantidade_registros control pagination, but it never explains the 'query' object parameter, leaving one of the three schema properties semantically opaque.

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

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

The description uses the specific verb 'Lista' and the resource 'Webhooks de integração', and states the HTTP endpoint GET /webhook. This clearly distinguishes the tool from siblings such as projuris_create_webhook.

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 pagination guidance with 'Pagine com pagina/quantidade_registros', but it does not explicitly state when to choose this tool over generic siblings like projuris_request or projuris_consulta, nor does it mention exclusions. Usage context is implied rather than 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?

The description says this tool performs a raw REST call to the external Projuris ADV API, but the annotations declare openWorldHint=false, which directly contradicts the implication that no outside-world interaction occurs. Additionally, the tool supports DELETE/POST/PUT/PATCH without any warning about side effects or destructive potential.

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 key concept ('Escape hatch'), then gives the essential parameter pattern and scope. Every clause adds value: the API target, method/path/query/body combination, examples, and full resource coverage, with no filler.

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

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

For a generic raw REST escape hatch, the description is reasonably complete: it covers method, path, optional query/body, examples, and the full API surface. It omits response/error/auth specifics, but no output schema exists and the raw-call semantics make those details less critical for initial selection and 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?

With 0% schema description coverage, the description carries the burden and does compensate: it names all four parameters, marks query and body as optional, and gives concrete path examples such as '/processo/123' and '/v2/processo/consulta'. It does not deeply explain body/query formats, but for a raw pass-through REST tool this is acceptable.

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 an escape hatch for raw REST calls to the Projuris ADV API, with explicit method and path examples. It also distinguishes itself from the many specialized projuris_* sibling tools by noting it covers all 757 resources, including v2 and configs.

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 phrase 'Escape hatch' strongly implies use when dedicated wrappers are insufficient, and the description explicitly notes full API coverage, including v2 and configs. However, it does not name specific sibling alternatives or state a formal 'use this only when no specialized tool exists' rule.

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 signal a non-read-only operation, but the description adds that the request must be the full body per the official API and must include the record code. This is useful though it does not disclose response behavior, error cases, or side effects beyond full replacement.

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 entire description is one compact sentence that conveys the operation, HTTP method, and the key parameter constraint. No filler or repetition.

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

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

For a single-parameter API wrapper the description captures the essential update semantics and data requirement, but with no output schema and sparse annotations it lacks detail on return values, errors, or alternative tools. 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?

The input schema only declares 'data' as a generic object with zero property descriptions. The description compensates partially by explaining that 'data' must be the complete API body including the record code, but it does not enumerate actual fields or 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 uses a specific verb 'Atualiza' and resource 'Apontamento de horas', and includes the HTTP method PUT. It clearly distinguishes the update operation from sibling create/consulta/get tools for the same resource.

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 semantics of 'Atualiza' imply use for updating an existing timesheet record, and the instruction to include the record's code field gives a usage condition. However, it does not explicitly state when to prefer this over create/get/consulta siblings or provide exclusions.

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 supply readOnly=false, destructive=false, and idempotent=false; the description adds that this is a PUT operation requiring a complete body that includes the record code, giving useful behavioral context about payload expectations. It does not contradict the annotations, though it stops short of describing auth, error, or response behavior.

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 well-structured sentence that front-loads the core action and resource, then adds the critical payload constraint without filler or 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?

For a mutation tool with no output schema, no detailed input schema, and a pointer to the 'official API' rather than an embedded definition, the description leaves important invocation details unspecified: exact required fields, response/return behavior, error conditions, and relationship to create/get counterparts. It is enough for basic selection but not for confident invocation in complex cases.

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

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

With schema_description_coverage at 0% and a generic 'data' object that has no specific properties, the description partially compensates by explaining that data must be the full official API body and must include the code field. It still omits a concrete field list or format, so it only partially replaces the missing schema detail.

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 starts with the specific action 'Atualiza' (updates) and the resource 'Pessoas' with clarifying types (clientes, partes, advogados, contatos), plus the HTTP endpoint PUT /pessoa. This clearly distinguishes it from sibling tools like projuris_create_pessoa and projuris_get_pessoa.

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 the tool is for updating an existing person and reinforces that the full body must include the record code, but it does not explicitly state when to prefer this over create or get/consulta tools, nor does it mention alternatives or exclusions.

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 convey a non-read-only, non-destructive, idempotent profile. The description adds the reproduction-context guidance but does not explain side effects such as ticket creation, external submission, or response behavior. The idempotentHint is not contradicted, but its implications are unstated.

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 short sentences, front-loaded with the core purpose, and contains no filler or repetition. 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?

For a simple tool with no output schema, the description is partially complete: it covers purpose and one parameter, but it omits expected behavior, response/return values, and clarifications for the required message and context fields. The conversation format ambiguity further limits 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 description coverage is 0%, so the description must compensate. It explains the conversation parameter's purpose but not the required 'message' parameter or the optional 'context' parameter. It also refers to a 'conversation array' while the schema types 'conversation' as a string, leaving 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 clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb and resource, and it is clearly distinct from the sibling Projuris operations and utilities.

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 context for when to use the tool and also gives a practical usage instruction: 'Include the conversation array with recent messages for reproduction.' It does not explicitly discuss exclusions, but no alternatives exist among 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description adds little beyond the 'current' qualifier implying live values. No additional behavioral details are provided, but there is no contradiction with the annotations.

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

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

The description is a single, front-loaded sentence that states exactly what the tool does without any filler or redundancy. Every word 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 tool's zero parameters, strong annotations, and simple purpose, the description is complete. It clearly indicates what information will be returned (platform and adapter versions), and no further context is necessary for an agent to select and invoke it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies because the description fully covers the trivial input surface and no additional parameter guidance 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 uses the specific verb 'Show' and clearly identifies the resource as 'current MCP platform and adapter versions.' This is unambiguous and distinct from the many projuris data tools and even the similarly named toolkit_info sibling, making the tool's purpose immediately 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?

The description provides clear context for when to use this tool: whenever platform or adapter version information is needed. It does not explicitly name alternatives or exclusions, but for a zero-parameter informational tool, the intended usage is self-evident and no alternative is 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds value by specifying exactly what state is returned and the level of detail, without contradicting 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 a single, well-structured sentence that front-loads the verb and immediately specifies the output details. Every element adds meaningful information with 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 zero-parameter info tool with strong annotations, the description adequately covers what the tool returns and the extent of its scope. It omits no critical detail needed for selection or invocation.

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

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

The tool has zero parameters and 100% schema coverage by definition. The description correctly provides no parameter details, and the baseline of 4 applies since there are no parameters requiring explanation.

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, enumerating specific content: installed MCPs, connection status, connected accounts, and catalog tool counts. This makes its purpose distinct from the sibling data-specific consulta/get/create 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 makes clear that this tool is for inspecting overall toolkit state, which serves as good usage context. It does not explicitly mention when not to use it or name alternatives, but given its unique informational role among siblings, the implied usage is clear.

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