LegalOne

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

Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds context about permanent vs. session token storage and the browser-based login flow, but does not disclose potential side effects like token overwriting or revocation.

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 paragraph that front-loads the purpose and then presents clear alternatives (Best: vs Or). It is informative without excessive verbosity, though multiple clauses make it slightly dense.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the login flow, token handling, and the two invocation patterns. It does not describe return values, but that is not critical for an authentication tool.

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

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

With 0% schema description coverage, the description compensates by explaining the 'token' parameter and how to use it (or omit it). It clarifies that the token is a JWT and that calling without arguments generates an authentication link, adding meaning beyond the raw schema.

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

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

The description clearly states the tool's purpose: to authenticate to the MCP.AI service for IDE agents. It specifies the resource (MCP.AI) and the action (log in, obtain token), and differentiates from siblings by focusing on the authentication flow.

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

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

The description provides explicit guidance on two usage modes: permanent config via Authorization header and session-only via token parameter. It explains when to call with no arguments (to get the link) and when to provide a token, but does not explicitly mention when not to use it or compare with the sibling 'connect' tool.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about conditional return states (authenticated with pending[] versus credentials-missing with connect_url), helping the agent predict output without contradicting annotations.

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

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

Two focused sentences, front-loaded with the core purpose: 'Returns connection status and URLs.' Every sentence contributes state-specific details; 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?

Given the tool has no parameters, no output schema, and low complexity, the description is fully adequate. It explains both major states (all connected vs. missing credentials) and the relevant response fields (authenticated, pending, connect_url).

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 zero parameters and 100% schema description coverage, parameter semantics are essentially not applicable. The baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior rather than input details.

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

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

The description opens with a specific verb and resource: 'Returns connection status and URLs.' It clearly defines the tool's purpose and distinguishes 'connect' as a status-check operation from sibling tools like 'authenticate,' which performs an action.

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

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

The description gives clear conditional context: if all providers are connected, the response is authenticated:true and empty pending[]; if credentials are missing, response includes connect_urls. This implies when an agent should call the tool, though it does not explicitly contrast it with authenticate or list excluded scenarios.

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

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

The annotations already indicate readOnlyHint=false, so the mutation behavior is consistent, and the description adds the POST endpoint. However, it does not disclose the response format, authentication requirements, or the duplicate-creation risk implied by idempotentHint=false.

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 front-loads the action and endpoint, then defines the parameter. Every clause earns its place with no redundant or filler 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 one-parameter create operation, the description covers the core action and payload meaning, but with no output schema and no return/error/prerequisite details, there are still notable gaps that an agent must resolve externally.

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 exposes one generic object with 0% description coverage, so the description must compensate. It usefully states that `data` is the entity body per the official API, but it does not enumerate or exemplify which fields are required or optional, leaving a clear gap.

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

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

The description uses a specific verb ('Cria') and resource ('Compromissos/agenda') and explicitly identifies the OData POST /Appointments endpoint. This clearly distinguishes it from sibling create tools such as legalone_create_contacts or legalone_create_lawsuits.

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 the create action and resource name, but the description provides no explicit guidance on when to use this tool versus alternatives, such as legalone_update_appointments for existing appointments or legalone_list_appointments for reading appointments.

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 non-read-only, non-destructive behavior. The description adds the OData endpoint and entity types but doesn't disclose side effects, auth requirements, or response details, being consistent but minimal.

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?

It's a single, concise sentence that front-loads the essential action and resource, but lacks any structured breakdown. It's not verbose, though it could be more informative without sacrificing 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 create tool with a free-form data object and no output schema, the description is insufficient. It doesn't explain required fields, validation, or response expectations, leaving critical 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 has one free-form 'data' parameter with 0% description coverage. The description merely says 'entity body according to the official API,' which doesn't compensate for the lack of field specifics 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 clearly states the tool creates contacts, listing specific entity types (clients, parties, lawyers) and the OData endpoint. It uniquely distinguishes itself from sibling create tools for other 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?

No explicit guidance on when to use this tool versus alternatives, no prerequisites, or exclusions. The description only states the action without contextual usage conditions.

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 creates a new lawsuit but does not disclose side effects, required authentication, non-idempotency, return values, or error behavior. Annotations provide only default false hints, leaving the description to carry the behavioral burden, and it does not go beyond the simple 'Cria' wording.

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

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

The description is compact with exactly two sentences: the first states the main action and relevant fields, and the second defines the `data` parameter. There is no filler, and the most important information is front-loaded.

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

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

The tool is a simple POST wrapper with one object parameter, and the description covers purpose and parameter semantics. However, it omits return behavior, required field guidance, and error or permission context. The absence of an output schema makes some of those omissions more significant, but the description is adequate 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?

The input schema only defines `data` as an open-ended object, but the description adds meaningful context by explaining that `data` is the entity body of the Lawsuits API and points to the official API for the exact format. It also gives concrete example fields, which helps the agent understand what to pass.

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 verb 'Cria' and specifies the resource 'Processos judiciais' (lawsuits), plus module-specific fields like valor da causa, partes, pedidos. It also identifies the underlying endpoint via OData POST /Lawsuits, clearly distinguishing it from other create 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?

No explicit guidance about when to use this tool versus alternatives such as legalone_create_litigations or legalone_update_lawsuits. The only hint is the verb and resource, which is insufficient for navigating the large sibling set, and there are no prerequisites 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 indicate this is not read-only, and the description confirms a create operation but adds no additional behavioral context such as required permissions, idempotency implications, or what happens on success/failure. With no output schema, the description does not disclose return 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 a single focused sentence that includes the action, resource, endpoint, and parameter meaning. Every part earns its place and nothing is redundant.

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

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

Given there is no output schema, no detailed parameter schema, and no guidance on entity structure, the description is too sparse for an agent to invoke the tool correctly without further research. It does not explain required fields, response format, or how to construct the data object beyond 'per official API'.

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 'data' as an object with additionalProperties, providing no property-level detail. The description adds that 'data' is the entity body per the official API, which is minimal but meaningful context; however, it does not compensate fully for the 0% schema coverage since it points to external documentation rather than explaining the structure.

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

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

The description clearly states the tool creates litigations/processes with a consolidated view, and it includes the explicit endpoint (OData POST /Litigations). It is specific enough about the resource, though it does not directly distinguish itself from the sibling legalone_create_lawsuits beyond the name.

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

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

No guidance is provided about when to use this tool versus alternatives such as legalone_create_lawsuits or legalone_update_litigations. The description only states what it does, not when or why it should be chosen.

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 the HTTP method (POST) and the endpoint, as well as noting that the deadline is in the 'deadLine' field. However, it does not elaborate on side effects, permissions, 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 concise, one sentence, and directly to the point without unnecessary 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?

The description lacks information about return values, error handling, or any other context that would help a caller understand the full behavior. Given the minimal schema, it leaves many questions unanswered.

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 'data' parameter is the entity body according to the official API, but it does not detail the structure or required fields of that object. The schema itself is vague, and the description does not compensate.

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

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

The description clearly states that the tool creates a 'Tarefas' (task) via a POST /Tasks OData endpoint, making its purpose unambiguous. It is specific to tasks, distinguishing it from other create 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?

The description does not provide any explicit guidance on when to use this tool versus alternatives, such as scenarios or prerequisites. It only states the action without contextual usage 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 flag readOnlyHint=false and destructiveHint=false, so the mutation nature is covered. The description adds almost zero behavioral context beyond the action itself: no mention of required auth, side effects, duplication semantics, response behavior, or constraints; 'conforme a API oficial' deflects rather than explains.

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?

One concise sentence conveys purpose, endpoint, and the main parameter. No fluff or redundancy; the description is easy to parse and front-loaded around the key information.

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

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

A free-form object parameter and no output schema place a huge burden on the description to explain what data should look like, but it only references the official API vaguely. The tool does not explain expected fields, response shape, potential errors, or how to build valid requests, leaving the agent without sufficient context for safe 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 schema provides only a raw 'data' object with additionalProperties and 0% description coverage. The description merely says 'data = corpo de entidade conforme o API oficial', which gives no concrete field names, required properties, or structural guidance. It barely compensates for the schema coverage gap.

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

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

The description clearly states the tool creates a process update ('Cria um(a) Andamentos/publicações/atualizações do processo') and identifies the underlying endpoint as OData POST /Updates. This definitively distinguishes the resource type from sibling create_* tools (appointments, contacts, lawsuits, etc.) and uses a specific, actionable verb.

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 implied by the verb 'Cria' and the resource name, but the description does not explicitly state when to prefer this over list/update variants or mention alternatives. There is no direct guidance on context, prerequisites, or decision logic beyond 'create an update'.

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 'Bulk support' context and mentions the endpoint path. It does not disclose return format, pagination, or error behaviors, but given the annotations cover the key behavioral traits, this is acceptable.

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 short and front-loaded, starting with the main purpose and endpoint. The bulk support note is useful and relevant. It is not overly verbose, but could be more structured (e.g., separate 'usage' sentence) for readability.

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

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

Given the tool is a read-only lookup with simple parameters and no output schema, the description is complete enough for an agent to select and invoke it. It explains the endpoint, the value proposition (resolving listItemId), and mentions bulk support. No major gaps that would prevent correct use.

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

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

Schema description coverage is 0%, so the description carries the burden for explaining parameters. The description clarifies that 'id' is the CustomFieldsDefinitions id, and implies that 'ids' is used for batched execution. However, it does not explain the format of ids, whether both id and ids can be used together, or the relationship between them beyond 'bulk support'.

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: it resolves the text behind listItemId values in customFields by accessing /CustomFieldsDefinitions/{id}/options. It names the specific endpoint and resource, which distinguishes it from generic list/get tools. However, it does not explicitly contrast with sibling tools like legalone_get_customfielddefinitions, so it loses a point.

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 this tool: when you need to translate listItemId values to human-readable text for custom fields. It does not explicitly state when not to use it or name alternative tools. The bulk support note gives a hint about usage with multiple ids but no detailed guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds meaningful behavioral context: the OData endpoint and batch/ids execution behavior. It does not cover limits or error cases, but the annotation coverage is strong enough for a simple read operation. No contradiction detected.

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 conveying the endpoint, the id lookup, $expand usage, and bulk support. Every sentence earns its place without unnecessary 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 description is adequate for a basic get-by-id tool but the gap around 'query', '$select', return shape, and any batch-size limitations leaves the agent without enough detail to confidently use more advanced OData behavior. Given the absences of output schema and schema descriptions, more detail would help.

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 needs to compensate. It explains 'id' implicitly and explicitly explains 'ids' and '$expand', but the 'query' and '$select' parameters are not described. The nested query object especially deserves more 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 tool retrieves an appointment by id: 'Busca um(a) Compromissos/agenda por id (OData /Appointments/{id})'. It also distinguishes itself from list/create siblings by being id-based and from the list appointments endpoint by mentioning bulk support.

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

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

It gives direct usage guidance: 'Use $expand para sub-recursos' and 'Bulk support: accepts ids for batched execution.' It does not explicitly name alternatives such as legalone_list_appointments or state when not to use it, so it misses a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds that it is an OData endpoint, supports $expand, and accepts batched ids, providing extra behavioral context.

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

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

The description is compact, with two short paragraphs that lead with the core purpose and then add bulk support. Every sentence contributes information without redundancy.

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

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

Given the tool's simplicity and strong annotations, the description adequately covers the resource type and key OData capabilities. It does not detail return fields or query parameters, but it is sufficient for selecting and invoking the tool.

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

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

The input schema has 0% description coverage, so the description must clarify parameter meaning. It explains 'id' (by id), 'ids' (batched execution), and '$expand' (sub-resources), but does not describe 'query' or '$select', leaving some parameters under-specified.

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

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

The description clearly states the tool retrieves a unified agenda of appointments and tasks by id, using an OData endpoint. It distinguishes from siblings like get_appointments and get_tasks by combining both resource types into one list.

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

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

The description provides usage hints like using $expand for sub-resources and bulk support via ids, but it does not explicitly state when to choose this tool over legalone_get_appointments or legalone_get_tasks. The context is implied but not stated with 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already known. The description adds bulk execution capability, which is extra context but does not contradict annotations. No mention of additional behavioral traits like rate limits or side effects, but given the annotation coverage, this is acceptable.

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 with no fluff. It front-loads the primary action and then adds the important OData and bulk notes. 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 get-by-ID tool with OData options, the description is adequate. It covers the main use case and mentions bulk support. It lacks details on return format, but no output schema is provided, and for a GET this is often predictable. Given the schema has 5 parameters, a bit more parameter explanation would improve completeness, but it's still sufficient for a competent 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 compensate. It explains 'id' and 'ids' for bulk, and mentions $expand for sub-records, but does not describe 'query' or '$select'. These are common OData parameters and likely self-explanatory, but the description misses the opportunity to clarify their role in this specific tool.

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

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

The description clearly states the function: 'Busca um(a) Áreas de atuação por id' (searches an area of practice by ID) and gives the OData path /Areas/{id}. This distinguishes it from list and other get tools, and the verb+resource is specific.

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

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

It provides usage context by mentioning $expand for sub-resources and bulk support for batched execution via ids. It does not explicitly contrast with list tools, but the purpose is clear enough that an agent can infer when to use it. Lacks 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 cover readOnly and idempotent behavior, so description adds value by mentioning bulk support and $expand for sub-resources. No contradiction with annotations.

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

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

Two succinct sentences, front-loaded with purpose, no wasteful wording. Efficient and to the point.

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

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

Provides enough for basic id fetches but lacks details on optional parameters (query, $select) and response shape. Given no output schema, more context would be beneficial, though annotations cover safety aspects.

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

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

With 0% schema description coverage, description must explain parameters. It covers id, ids (bulk), and $expand, but leaves query and $select unexplained. Insufficient compensation for majority of 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?

Description clearly states it fetches contacts (physical/legal persons) by id using OData endpoint, with bulk support via ids. Distinct resource and verb, differentiating from siblings like legalone_list_contacts.

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

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

Implies usage for single contact retrieval by id, and bulk execution via ids. Does not explicitly contrast with list_contacts or other get_* tools, but the context is clear enough.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds useful context about bulk execution and $expand, which are not in annotations. It does not contradict annotations and provides extra operational detail, justifying a score above baseline.

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

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

The description is two concise sentences, front-loaded with the core purpose, and includes only essential extra info (bulk support). 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?

Given the tool has no output schema and multiple optional parameters, the description does not sufficiently explain the query and $select parameters, nor the response format (single vs. multiple objects). While annotations cover safety, the description lacks enrichment for complete invocation, especially for bulk use.

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

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

Schema coverage is 0%, so the description must explain parameters. It clarifies id (implicitly), ids for bulk, and $expand, but leaves query and $select unexplained. This is only partial coverage of the 5 parameters, and the description does not fully compensate for the missing schema descriptions.

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

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

The description clearly states the tool retrieves custom field definitions by ID, matching the OData endpoint pattern. It distinguishes from the sibling list tool by indicating it fetches by specific id, and mentions bulk support for multiple ids.

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 usage hints like using $expand for sub-resources and bulk execution for multiple ids, but does not explicitly contrast with alternative tools (e.g., list_customfielddefinitions). It implies usage when a specific id is known but lacks 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds OData endpoint context, bulk execution support, and the $expand capability—information beyond the annotations that clarifies the tool's behavior without contradiction.

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

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

The description is two concise sentences with no redundancy. It front-loads the core purpose, then adds expand and bulk notes efficiently, avoiding unnecessary 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?

Given 5 parameters and no output schema, the description covers the essential retrieval behavior (by id, bulk, expand) but omits $select and query usage. For a get-by-id tool, it is fairly complete, though the missing query semantics slightly reduce completeness.

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

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

With schema description coverage at 0%, the description must explain parameters. It clarifies 'id' and 'ids' (bulk) and $expand, but leaves '$select' and 'query' undefined. The schema shows required id and types, but the description doesn't fully compensate for the missing coverage, earning a mid-range score.

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 'Busca um(a) Documentos (GED) por id' (search a document by id) with the OData endpoint, and explicitly distinguishes it from the sibling list_documents by focusing on id-based retrieval. It also mentions bulk support, making the tool's single/batch retrieve purpose unambiguous.

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

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

It guides the use of $expand for sub-resources and notes bulk support via 'ids', which informs the agent when and how to pass multiple ids. However, it does not explicitly contrast with sibling list_documents or state when not to use it, leaving some implicit inference from the name and context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds bulk support and $expand usage, but does not disclose response format or pagination behavior. With annotations covering the core traits, 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 concise, with two sentences covering the main purpose and bulk support. It is front-loaded with the primary action and endpoint. Slight lack of structure for parameter details, but overall efficient.

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

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

Given the tool has 5 parameters, no output schema, and 0% schema coverage, the description is incomplete. It does not explain the 'query' object, $select, or how bulk ids work in detail. However, the core purpose and $expand usage are covered, making it 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?

Schema description coverage is 0%, so the description must compensate. It mentions id and $expand, but does not explain the 'query' object, $select, or the difference between id and ids. The description adds minimal value beyond the schema for most parameters.

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

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

The description clearly states the tool fetches a lawsuit by id with module-specific fields (valor da causa, partes, pedidos) via OData endpoint /Lawsuits/{id}. It distinguishes from siblings like legalone_list_lawsuits by specifying the by-id retrieval and $expand usage.

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

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

The description mentions using $expand for sub-resources and bulk support for batched execution, but does not explicitly contrast with list tools or provide when-to-use vs alternatives. It implies usage for single-record retrieval but lacks explicit 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the OData endpoint, consolidated view, and bulk id support, but does not explain response behavior, error cases, authentication needs, or batch size limits. This is acceptable 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 compact and front-loaded: the core purpose and endpoint appear first, followed by expand usage and bulk support. Every sentence contributes useful information with no redundant filler. The minor grammar issue in 'um(a) Processos/litígios' does not detract from the structural efficiency.

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 five parameters, no output schema, and zero parameter descriptions in the schema, the description provides enough to make a reasonable call: endpoint, id, ids, and $expand. However, it omits semantics for query and $select, and does not mention pagination or response shape. It is minimally viable but has 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 carries the full burden of explaining parameters. It explains id, ids via bulk support, and $expand, but leaves query and $select completely unexplained. This is only partial compensation for an otherwise undocumented schema.

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

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

The description states a specific action: get a process/litigation by id via the OData endpoint /Litigations/{id}, with a consolidated view. It also mentions $expand and bulk support for ids, which helps distinguish it from list-style siblings like legalone_list_litigations. It is clear but slightly vague about the difference between 'Processos/litígios' and the sibling 'lawsuits' 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 id' and 'OData /Litigations/{id}' clearly indicates this tool is for fetching specific litigations, and 'Bulk support: accepts ids' explains when to use the ids parameter. 'Use $expand para sub-recursos' gives concrete usage guidance. It does not explicitly say when not to use it or mention list_litigations as an alternative, so it stops short of a 5.

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

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

Annotations already disclose readOnly, idempotent, and non-destructive behavior. The description adds value by revealing bulk id support and $expand usage, which are behavioral traits beneficial for an agent to know.

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

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

Two sentences with no filler. Purpose is front-loaded, and the bulk support note is concise. Every word adds value.

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

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

For a tool with an OData query parameter and nested objects, the description omits explanation of 'query' and '$select', and no output schema is provided. It covers the core use case but is incomplete for advanced query scenarios.

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 explains 'id', 'ids', and '$expand', but leaves 'query' and '$select' undocumented. It partially compensates but not fully, given the nested query object.

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

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

The description clearly states the tool retrieves service/process types by ID via OData endpoint /ServiceTypes/{id}, distinguishing it from sibling list tools and specifying the resource. It also mentions bulk support, further clarifying scope.

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

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

It provides guidance on using $expand for sub-resources and indicates bulk execution with ids. However, it does not explicitly contrast with legalone_list_servicetypes or legalone_odata_get for alternative usage, leaving some implied 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 signal a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond annotations: the deadline field is named `deadLine`, the endpoint uses OData, and bulk execution via `ids` is supported. 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 remarkably efficient, using two short sentences to convey core behavior, OData context, deadline field, and bulk support. Every clause contributes meaning and there is no filler or redundant restating of the tool name.

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 primary get-by-id scenario and bulk support, but it does not describe what `query` does, how `$select` works, or anything about the response shape. Since there is no output schema and no additional parameter descriptions, these missing details prevent the description from being fully contextualized 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 needs to explain parameters. It successfully explains `id` (fetch by primary key), `ids` (dependency support), and `$expand` (sub-resources). However, it leaves `$select` and `query` unexplained, which leaves a material gap for an agent trying to construct advanced calls.

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 this tool fetches a single Tarefas/providências by id via the explicit OData path `/Tasks/{id}`. It distinguishes itself from siblings like `legalone_list_tasks` by emphasizing id-based retrieval, and the phrase `por id` eliminates ambiguity about the resource and scope.

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

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

The description gives clear context: use this when you have an id, and use `$expand` for sub-recursos. It does not explicitly name alternatives or list when-not-to-use scenarios, but the id-focused language strongly differentiates it from the sibling list tool without further elaboration.

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 known. The description adds valuable context beyond annotations: the OData endpoint, support for $expand and bulk execution. It doesn't contradict annotations and provides useful operational detail.

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 primary purpose. Every sentence adds information: the endpoint and the bulk capability. No fluff or repetition.

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

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

For a read-only fetch by id tool with no output schema, the description covers the core operation and bulk behavior. However, it omits details on the 'query' object and '$select' semantics, which might be necessary for advanced usage. Given the annotations and simplicity, it's largely complete but could be more explicit about remaining 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?

Schema description coverage is 0%, so the description must compensate. It explains 'id' (the primary key), 'ids' for bulk, and '$expand' for sub-resources, but does not address 'query' or '$select' parameters. Given all 5 parameters are present, the coverage is partial, and the description adds some value over the schema but leaves gaps.

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

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

The description clearly states the tool fetches an update by id, explicitly mentioning the OData endpoint ($/Updates/{id}). It distinguishes this from list_updates (which lists) and create_updates (which writes), making the purpose unambiguous.

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

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

The description implies when to use this tool (fetch by id, with bulk support for multiple ids) and mentions using $expand for sub-resources. While it doesn't explicitly contrast with list_updates, the phrase 'por id' and the bulk mechanism make the intended usage clear. It lacks explicit 'when not to use' guidance but is adequate.

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 description isn't required to restate that. It adds value by mentioning the OData endpoint and $expand, but does not disclose behaviors like error handling, default fields, or pagination. With annotations covering safety, the description adds minor context, hence a 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 short (two sentences) and front-loaded with the core purpose. It includes useful hints about OData and bulk execution without extra fluff. Slightly less structured than ideal, but effective.

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 clarify return shape, but it doesn't. It covers id/ids and $expand, but omits $select, query, and behavior for missing IDs or error cases. For a get-by-id tool, this 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 description coverage is 0%, so description should explain parameters. It only mentions 'id' and 'ids' for bulk, plus $expand for sub-resources. It does not explain 'query' or '$select' despite the schema having 5 parameters. The description partially compensates but leaves key parameters unexplained.

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

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

The description states a specific verb ('Busca' = search/get) and resource ('Users/responsáveis do escritório') with the OData endpoint (/Users/{id}), clearly distinguishing it from sibling list_users. It also notes the bulk variant via 'ids', so the purpose is unambiguous.

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

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

It explicitly mentions using $expand for sub-resources and notes bulk execution via ids, giving context for parameter usage. However, it does not explicitly contrast with the sibling 'list_users' tool or state when to prefer one over the other, though the id-based retrieval is implied. This is clear context without 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 and idempotentHint=true, so the description doesn't need to repeat safety. It adds the OData endpoint context and mentions common OData query options, but doesn't disclose default pagination behavior, result limits, or authentication expectations.

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 action and resource, then efficiently lists the relevant OData options. Every word earns its place, with 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 has 8 parameters, a nested query object, no output schema, and many similarly named siblings, but the description gives only a minimal summary. It doesn't explain the query object, clarify differences from get_appointments, or describe pagination/return behavior, leaving significant gaps for correct invocation.

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

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

With 0% schema description coverage, the description must compensate for parameters. It lists five of eight parameters ($filter, $top, $skip, $orderby, $expand) with standard OData meaning, but omits $select, $count, and the query object, leaving those parameters unexplained.

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 clear verb 'Lista' with the resource 'Compromissos/agenda' and identifies the OData endpoint /Appointments, making the operation unambiguous. It doesn't explicitly contrast with sibling legalone_get_appointments, but the list/get distinction is reasonably inferred from the naming and verb.

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 operational context by mentioning OData and instructing to filter with $filter/$top/$skip/$orderby/$expand, implying when this tool is useful. It does not explicitly state when to prefer this over legalone_get_appointments or legalone_odata_get, nor any exclusions or alternatives.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the endpoint returns a unified list of appointments and tasks and supports OData filtering, but it does not disclose potential behavior like default result limits, pagination semantics, or response shape beyond 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 tool's purpose and then names the query parameters. It contains no filler or redundant restating of the tool name.

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

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

Despite having 8 parameters, a nested query object, and no parameter descriptions, the description gives only a high-level OData hint. It does not explain how each parameter behaves, what the return value represents, or how to construct a valid query. Sibling tools and annotations help, but for an OData-heavy listing operation this is too sparse.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions $filter, $top, $skip, $orderby, and $expand, but provides no actual semantics or syntax examples for these parameters, and ignores $select, $count, and the 'query' nested object. This is insufficient guidance for an 8-parameter tool.

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

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

The description clearly states the resource and action: 'Lista Agenda unificada: compromissos e tarefas na mesma lista' (lists appointments and tasks together), and names the OData endpoint. It distinguishes itself from sibling tools like legalone_list_appointments and legalone_list_tasks, which handle each type separately.

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 'compromissos e tarefas na mesma lista' clearly indicates when this should be used: when a unified view of appointments and tasks is needed. The OData filter instructions also tell the agent how to query/limit results, though it does not explicitly call out when not to use it or name 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, so the return-safety profile is covered. The description adds the OData endpoint and supported query options, which is useful context, but does not describe return format, default pagination, or behavior beyond the annotations, so it adds moderate rather than rich value.

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

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

Two concise sentences front-load the core purpose and immediately list the relevant OData capabilities. No padding or repetition; each 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?

With 8 optional parameters and no output schema, the description gives a helpful overview of the OData filtering surface but omits details about the 'query' object, $select/$count behavior, and what the response contains by default. This is adequate for a straightforward read-only list tool but not fully 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 names five of the eight parameters ($filter/$top/$skip/$orderby/$expand) as OData query options, giving some meaning beyond the bare schema. However, it does not explain the remaining parameters ($count, $select, and the 'query' object), leaving partial gaps.

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

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

The description states a specific verb ('Lista' = list) and resource ('Áreas de atuação' = practice areas), and adds the OData endpoint '/Areas'. This clearly identifies the tool as a list operation, though it does not explicitly contrast it with the sibling legalone_get_areas, relying on the list/get naming convention.

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 indicates this is a listing tool and tells users they can filter with $filter/$top/$skip/$orderby/$expand, providing key usage context. However, it does not explicitly state when to prefer this over legalone_get_areas or legalone_odata_get, nor when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds minimal behavioral context—it mentions the OData endpoint and that it lists contacts—but does not disclose response format, pagination, or any side effects. This is acceptable given the annotations, but no extra value is added.

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 action and resource type. It avoids fluff and directly states the filtering capabilities. Efficient and well-structured, though slightly under-specified.

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

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

For a list tool with 8 parameters, no output schema, and minimal annotation detail, the description gives the essential resource and filtering hints but lacks information on return structure, pagination behavior, or example usage. It hints at returning a list of contacts but does not elaborate. Given the annotations cover safety, this is minimally sufficient but leaves gaps for a complex OData interface.

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 explain parameters. It lists $filter, $top, $skip, $orderby, and $expand but does not define what each does, leaving interpretations to OData knowledge. It omits $select, $count, and query entirely. This fails to compensate for the schema's lack of descriptiveness.

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

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

The description clearly states the tool lists contacts (pessoas físicas/jurídicas) and specifies the types (clients, parties, lawyers), distinguishing it from get_contacts (which retrieves a single contact) and other list tools. It also names the OData endpoint, making the action unambiguous.

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

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

It explicitly instructs users to filter with $filter/$top/$skip/$orderby/$expand, providing immediate guidance on how to customize the list. While it doesn't explicitly contrast with alternatives like legalone_get_contacts, the filter options and resource type make the intended use clear.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds no additional side effects or restrictions, but 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 concise sentence that directly states the purpose and available filters without unnecessary words.

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

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

Provides the endpoint and filter hints, but does not describe the return structure or any potential limitations. For a simple list operation this is acceptable, though more detail could improve completeness.

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

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

The schema has no parameter descriptions. The description enumerates some OData parameters but omits $count and $select, and does not explain their meanings beyond indicating they are for filtering.

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 lists custom field definitions, specifying the OData endpoint. This distinguishes it from other list 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?

Mentions OData filter options but does not explicitly state when to use this tool versus alternatives. However, the entity-specific name implies when it is appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the OData endpoint and suggests query capabilities, but does not disclose return shape, pagination behavior, or any system-specific constraints beyond that.

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

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

The description is two concise sentences, front-loaded with the main purpose and followed by a compact filter-related usage hint. 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?

Given no output schema and a fairly complex query surface, the description does not fully explain what the response contains, how pagination works, what $query means, or how this tool differs from the get-documents sibling. It is sufficient only for agents already deeply familiar with OData APIs.

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

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

There are 8 parameters with 0% schema description coverage, so the description needs to compensate. It only repeats a subset of parameter names ($filter, $top, $skip, $orderby, $expand) without explaining their meaning, and it completely omits semantics for the 'query', '$select', and '$count' parameters.

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

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

The description clearly states the action: 'Lista Documentos (GED)' and identifies the target resource and endpoint: 'OData /Documents'. It is specific enough to know this tool lists documents, but it does not explicitly differentiate itself from the sibling tool 'legalone_get_documents'.

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 the OData filter instruction: 'Filtre com $filter/$top/$skip/$orderby/$expand'. This gives some context for when to use the tool, but it does not explain when to prefer this over 'legalone_get_documents' or when not to use it.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making it safe. The description adds useful context about OData filtering and module-specific fields, but doesn't detail pagination or default limits beyond what annotations imply. With such annotations, the bar is lowered; the description covers the key behavioral aspects.

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

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

The description is compact and front-loaded with the primary purpose. It could be more structured, but it is not verbose or padded. The OData reference is useful, but the sentence about filtering is somewhat generic and might be clearer with a concrete example.

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

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

Given the tool's complexity (8 parameters, OData operations), the description is minimal but sufficient to understand the basic function. It lacks details on default behavior, response format, or common use cases, but the output schema is absent, so some gaps remain. An average score is appropriate.

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 mentions OData parameters but does not explain them individually. The schema has 8 parameters with 0% description coverage, so the description must compensate but does not. It only lists the parameter names without clarifying their semantics or providing examples, leaving the agent to infer from the single OData mention.

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

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

The description clearly states it lists lawsuits with module-specific fields (e.g., value, parties, requests) and indicates it uses OData operations. It is specific enough to distinguish from sibling tools like legalone_get_lawsuits, which likely retrieves a single lawsuit, while this lists multiple.

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 communicates usage via OData parameters ($filter, $top, etc.) and that it's a listing operation. However, it does not explicitly state when to prefer this over legalone_get_lawsuits, which seems redundant given the sibling context, but it is clear enough for an experienced agent.

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

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

The description expands on the read-only annotations by indicating this is an OData listing with filtering/pagination operations. It doesn't disclose pagination limits, response shape, or potential complexity of the consolidated view, but given the annotations already mark it as safe and idempotent, the additional context is modestly useful.

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

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

The description is extremely concise: two compact sentences with no filler words. It front-loads the core purpose and immediately gives the most useful operating hints, making it easy for an agent to parse and act on.

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

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

This is an 8-parameter listing tool with no output schema, yet the description does not specify return structure, pagination behavior, or required permissions. 'Visão consolidada' is only a vague indication of response shape, and the query object parameter is left completely unexplained.

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 8 parameters and 0% schema description coverage, the description carries the full burden of parameter explanation. It names only five OData filtering/pagination parameters and offers no details on how to build filters, the meaning of the 'query' object, or the use of $select and $count, leaving significant 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 identifies the tool as listing lawsuits/litigations ("Lista Processos/litígios") and references the OData endpoint (/Litigations). It conveys the resource and a consolidated litigation view, but does not explicitly differentiate from sibling legalone_get_litigations or legalone_list_lawsuits.

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 "Lista Processos/litígios" implies this tool is used to list litigation records, and the mention of OData filtering options suggests how to refine the listing. However, there is no explicit when-to-use/alternative guidance or exclusion of sibling tools, leaving the usage context implied rather than clearly structured.

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 established. The description adds the OData endpoint and specific query capabilities, which goes beyond annnotations by clarifying the API style and supported operations. No contradiction; it complements the annotations effectively.

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 purpose and immediately identifies the OData endpoint and key query options. Every word earns its place; no fluff. Extremely concise and well-structured.

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

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

For a list tool with no output schema, the description provides enough to know it's an OData queryable list, but it doesn't explain the 'query' object or all available parameters. The tool is moderately complex due to 8 optional parameters, yet the description only hints at some. It's adequate for a basic list operation but leaves gaps for advanced usage.

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 for parameter meanings. It explicitly names $filter, $top, $skip, $orderby, and $expand, covering 5 of 8 parameters. However, it omits $count, $select, and the 'query' object, leaving their semantics unexplained. Partial coverage, so a score of 3 is appropriate.

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

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

The description clearly states it lists service/process types, specifies the OData endpoint (/ServiceTypes), and implies a collection operation. This distinguishes it from sibling tools like legalone_get_servicetypes which likely retrieves a single item. The verb 'Lista' is specific and unambiguous.

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

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

The description mentions OData filtering capabilities ($filter/$top/$skip/$orderby/$expand), which gives usage hints, but it does not explicitly state when to use this tool versus alternatives (e.g., when to use get_servicetypes). It lacks clear when-not guidance, though the filtering options imply it's for list queries.

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 safe read-only nature is covered. The description adds that the deadline is in the 'deadLine' field and mentions OData filtering capabilities. This is helpful but does not go beyond what structured metadata already conveys.

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 purpose, and includes the key filter options. It is efficient with no fluff. However, it could be slightly more structured by explicitly listing all parameters or providing a brief example, but overall it earns a high score for 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?

With 8 parameters, no output schema, and zero schema coverage, the description leaves significant gaps. It does not indicate the return format (e.g., collection vs single item), pagination behavior beyond $top/$skip, or any special considerations. For a tool of this complexity, the description is under-specified.

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 for parameter understanding. It explicitly names five of the eight parameters ($filter, $top, $skip, $orderby, $expand) but omits $select, $count, and 'query'. The 'query' object is undocumented and unclear. This partial coverage is insufficient given the high parameter count.

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

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

The description clearly states it lists tasks/providências, and specifies the OData endpoint '/Tasks'. It also highlights the deadline field, which adds specificity. However, it does not explicitly distinguish itself from sibling tools like legalone_get_tasks, though the 'Lista' (list) verb implies a collection listing.

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

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

The description mentions using OData filters ($filter, $top, $skip, $orderby, $expand), which implies usage for querying and pagination. But it provides no explicit guidance on when to use this tool versus alternatives like legalone_get_tasks, nor any exclusions or prerequisites. Usage is implied rather than explicitly stated.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description is consistent with these annotations and does not introduce contradictions, though it adds no extra behavioral context beyond what annotations provide.

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

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

The description is a single concise sentence that includes the resource and key filtering options without unnecessary words 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?

Without an output schema, the description does nothing to indicate the return structure or pagination details. It gives the core purpose but lacks context on expected results, making it minimally adequate for a straightforward list operation.

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 8 parameters but no descriptions. The description mentions only a subset (filter, top, skip, orderby, expand) without explaining their semantics or the 'query' parameter, leaving significant gaps in compensation for the lack of schema descriptions.

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 lists updates (movements/publications) of a process and mentions the OData /Updates endpoint, which distinguishes it from other list tools. However, it could be more specific about what 'updates' entails.

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

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

The description mentions filtering options ($filter, $top, $skip, $orderby, $expand) but does not explain when to use this tool versus other list tools (e.g., legalone_list_appointments). No alternative or exclusion 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the OData endpoint and filter capabilities, but it does not disclose pagination behavior, return shape, or authentication requirements. This is acceptable 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 sentences with no filler. It front-loads the verb and resource, then immediately provides the most relevant filtering options. 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?

With 8 parameters, no output schema, and sibling tools like legalone_get_users, the description is too minimal. It does not explain return values, pagination behavior, the query object, or how this tool differs from the get_users sibling, leaving significant gaps for an agent to choose 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It names five of eight parameters ($filter, $top, $skip, $orderby, $expand) but omits $select, $count, and query, and provides no syntax or format details beyond the parameter names.

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 ('Lista') and resource ('Usuários/responsáveis do escritório') and identifies the OData endpoint (/Users), making the core purpose clear. However, it does not distinguish this tool from the sibling legalone_get_users, which likely serves a similar or overlapping use case.

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 filtering guidance ('Filtre com $filter/$top/$skip/$orderby/$expand') but gives no explicit guidance on when to use this tool versus alternatives such as legalone_get_users or legalone_odata_get. There are no when-to-use or when-not-to-use 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?

While readOnlyHint and idempotentHint annotations already indicate a safe read operation, the description adds practical context by explaining what the metadata includes (scopes, products, collections) and how to interpret 403 errors. This goes beyond what the annotations provide.

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

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

The description is two sentences, front-loaded with the essence (connection metadata) and immediately followed by usage instructions. No filler or repetition, directly addresses purpose and invocation timing.

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

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

Despite having no parameters or output schema, the description lists the key metadata components (scopes, products, base, collections) and when to use it (before query, after 403). This is complete for a metadata discovery tool.

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

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

The tool has zero parameters, so the schema already fully describes it (no parameters). The description appropriately focuses on what the metadata contains and when to use it, adding value beyond the empty schema. Given the baseline of 4 for zero params, this is appropriate.

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

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

The description clearly states that this tool provides connection metadata: scopes, API products, base URL, and available collections with associated tools. It uses specific nouns and verbs, and it is distinct from sibling tools which perform specific operations (create/get/list/update).

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

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

Explicitly tells when to call: "Chame antes de montar uma consulta, e depois de um 403" (call before building a query, and after a 403). It also explains that a 403 is usually due to missing scope, not wrong credentials, which guides troubleshooting behavior.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe read operations. The description adds valuable behavioral context by mentioning support for OData query operators (filter/expand/select/top/skip/orderby) and bulk execution via `ids`, which goes beyond the annotations. No contradictions detected.

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 exceptionally concise: two sentences covering purpose, usage guidance, parameter hints, and bulk support without redundancy. It front-loads the core purpose and then adds examples and options efficiently, earning a high score for structure.

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 OData GET tool with 11 parameters and no output schema, the description provides sufficient context: it defines the target resource, gives an example, lists supported OData options, and notes bulk capabilities. It does not describe response format, but that is standard OData JSON and not essential for a read-only tool. The description is complete for the tool's intended use.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `entity` with an example, mentions `id` as optional, and lists several OData query parameters ($filter, $expand, etc.). However, it does not explain `$count` or the `query` object, and only briefly mentions `ids` for bulk support. While it adds meaning for key parameters, it leaves some undefined, so a score of 3 reflects partial 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 'GET genérico em qualquer coleção/recurso OData do LegalOne', specifying the action (GET) and the resource (any OData collection). It also provides a concrete example ('Litigations') and distinguishes itself from sibling tools by targeting 'entidades não cobertas por uma tool nomeada', making its purpose unmistakable.

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

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

The description explicitly says 'Use isto para entidades não cobertas por uma tool nomeada', providing clear when-to-use guidance and implicitly when-not-to-use (for entities with dedicated tools). It also lists supported OData query options and mentions bulk support, giving practical usage context without ambiguity.

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

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

Annotations are all false/unknown, so the description carries the full transparency burden. It reveals that arbitrary HTTP methods including DELETE/POST/PATCH/PUT are accepted, but it does not warn about potential side effects, authentication requirements, or raw response/error behavior. The 'raw OData call' label gives some signal, but not enough.

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 only two sentences, front-loaded with the key 'Escape hatch' concept, and contains no fluff or repetition of schema properties.

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 deliberately open-ended raw OData tool, the description adequately covers purpose, method, path, and optional inputs. However, with no output schema, it gives no guidance on response format, pagination, or error behavior, and it does not mention authentication prerequisites even though sibling tools like authenticate/connect exist.

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

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

The schema has 0% description coverage, so the description must add meaning. It compensates by explaining the method enum, giving a concrete path example ('/Litigations/2479'), and noting that query/body are optional. It does not detail OData query syntax, but this is acceptable for a generic escape-hatch tool.

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

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

The description clearly identifies the tool as an 'escape hatch' for raw OData calls and specifies the core inputs (method, path, query/body). It also distinguishes itself from siblings by explicitly covering endpoints/actions outside the named 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 'Cobre endpoints/ações fora das tools nomeadas' gives clear guidance that this tool is for cases not covered by the dedicated sibling tools. It implies use only when no named tool fits, though it does not explicitly list when-not-to-use cases.

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

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

The description indicates a non-read-only operation (update) and that `data` contains fields to change, which implies partial modification. It does not detail side effects like return values, error handling, or atomicity for bulk updates, but the annotations (readOnlyHint false, destructiveHint false) are not contradicted. The description provides basic transparency but lacks in-depth behavioral details.

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

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

The description is concise, consisting of two sentences that convey the operation, endpoint, parameter role, and bulk capability. It is well-structured and free of unnecessary jargon.

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 operation and parameter meaning, but it does not mention response format, required vs. optional fields within `data`, or specific constraints. Given the open schema for `data`, a more detailed description could list common fields, but it is not strictly necessary for basic usage. It is moderately 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?

The description explicitly explains `data` as fields to change, which adds meaning beyond the schema's open object definition. It does not clarify the roles of `id` and `ids` beyond implying they are identifiers (with `ids` for bulk). The schema provides no descriptions for these parameters, so the description partially compensates but leaves some ambiguity about usage and mutual exclusivity.

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 updates appointments (Compromissos/agenda) and specifies the HTTP method (PATCH) and endpoint (/Appointments/{id}). It distinguishes itself from sibling update tools for other entities (contacts, lawsuits, etc.) by explicitly naming the target 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 description implies usage for updating existing appointment records and explains the `data` parameter as fields to change. It also mentions bulk support via `ids`, giving clear guidance on when to use the multi-record capability. However, it does not explicitly contrast with create or get tools, but the context makes that 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?

Além das annotations, a descrição informa o método PATCH do OData, que `data` contém os campos a alterar e que `ids` permite execução em lote. Isso agrega contexto comportamental útil, embora não detalhe coerções de resposta ou erros de execução.

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

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

Duas frases curtas e diretas, já começando com ação e recurso, e depois apresentando o endpoint e o suporte a lote. Não há excesso de texto nem redundância com a estruturação fornecida.

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

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

Para uma ferramenta de update relativamente simples, a descrição é suficiente: informa método, path, role do corpo `data` e detalhes de batch. Como não há output schema, um pouco mais de detail sobre success/failure ou validação fechado ainda útil, mas a tool é 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?

A descrição atribui significado a `data` ('campos a alterar') e a `ids` ('accepted for batched execution'), além de mencionar `{id}` no endpoint. Mas não explica explicitamente como `id` e `ids` interagem, se um é opcional para o modo lote, nem o formato exato de `data`.

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?

A descrição define claramente a ação ('Atualiza'), o recurso ('Contatos'), o contexto legal (clientes/partes/advogados) e o endpoint OData (`PATCH /Contacts/{id}`). Isso distingue bem a ferramenta dos tools de criação e listagem de contatos.

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

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

A descrição deixa claro que é para atualizar contatos existentes e menciona explicitamente suporte a execução em lote via `ids`. Não apresenta cenários de quando não usar nem alternativas, mas o contexto de atualização via PATCH é suficiente para orientar o uso.

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

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

The annotations already state readOnlyHint=false, so 'Atualiza' is not surprising. The description adds valuable behavioral context beyond annotations: it is an OData PATCH operation, `data` represents only the fields to change, and bulk execution via 'ids' is supported. This meaningfully informs the agent 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 compact and efficient: two sentences deliver the operation, target resource, method, parameter semantics, and batch behavior. There is no filler, and the most important action is front-loaded.

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

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

For a straightforward CRUD update tool with 3 params, the description is mostly complete: it explains the update semantics, the PATCH method, and the optional bulk path. It stops short of describing the return value or the exact relationship between the required 'id' and optional 'ids', but it gives enough for a competent agent to use the basic single-update flow reliably.

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 is very sparse: `data` is an arbitrary object with no property semantics, and 'ids' is merely an array. The description compensates by explaining that `data` is 'campos a alterar' and that 'ids' enables batch execution, while `id` is shown in the endpoint path. This is useful but could be clearer about id vs ids coordination for batch calls.

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 a specific verb and resource: 'Atualiza ... Processos judiciais' and further specifies the module fields (valor da causa, partes, pedidos) and the HTTP endpoint OData PATCH /Lawsuits/{id}. This distinguishes it from the sibling update/create tools for other LegalOne 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 provides clear context for when to use the tool: it updates existing lawsuit records, optionally in bulk using 'ids'. It does not explicitly compare with create or list alternatives, so it misses the full 5-level, but the usage context is unambiguous.

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 signal readOnlyHint/idempotentHint/destructiveHint false; the description goes further by stating OData PATCH semantics, that `data` holds fields to change, and that ids enables batch execution. This is useful behavioral context beyond the structured annotations, though it does not cover auth, validation, or response 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 compact and front-loaded with purpose, endpoint, and a separate bulk-support note. Every sentence is informative with no filler; the minor awkwardness in 'um(a) Processos/litígios' and the parenthetical OData reference are acceptable.

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 write tool with no output schema and 0% schema coverage, the description covers the endpoint, core semantics, and batch behavior. But it omits any detail about expected response, validation, or which fields can be updated, making it adequate for basic invocation but not fully self-sufficient.

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; it explains `data` as 'campos a alterar' and identifies `ids` as batch support, which the schema alone does not convey. However, it does not explain the `id` parameter's role or enumerate allowed fields for `data`, leaving significant gaps.

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

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

The description opens with 'Atualiza um(a) Processos/litígios' – a clear verb (updates) and resource (litigations) – and reinforces it with the OData PATCH endpoint. However, it does not explicitly distinguish this from the sibling legalone_update_lawsuits tool, and the mixed 'Processos/litígios' phrasing adds slight ambiguity.

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 tells the agent this tool updates litigations and mentions 'Bulk support: accepts ids for batched execution,' which is a concrete usage hint. But it never explains when to prefer this over legalone_update_lawsuits or other update tools, nor provides 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?

Annotations only state readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description carries moderate disclosure burden. It adds useful behavioral context by naming the PATCH method, clarifying that `data` contains fields to alter, and mentioning bulk execution via ids. It does not cover response behavior or error conditions, but with annotations present this is acceptable.

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

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

The description is compact: two sentences carry the action, endpoint, field semantics, and bulk support. All sentences add value with no repetition of the tool name or obvious 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 simple PATCH-style update tool with no output schema and basic annotations, the description is mostly complete: it identifies the resource, HTTP method, request payload semantics, and bulk capability. It could additionally clarify expected response/return values or error behavior, but these omissions are not critical for basic invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the central parameters: `data` are the fields to alter, the endpoint path exposes `id`, and `ids` are for bulk/batched execution. The deadline note ('o prazo vem no campo deadLine') adds further semantic value, though it does not enumerate all possible `data` 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 a specific operation ('Atualiza um(a) Tarefas/providências') with a concrete endpoint ('OData PATCH /Tasks/{id}'). This distinguishes it from sibling create/get/list/update tools by resource and action, and adding the endpoint makes the intent unambiguous.

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

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

The description implies use when updating an existing task, and explicitly notes bulk support ('accepts ids for batched execution'). However, it does not state when to prefer this tool over alternatives such as legalone_create_tasks or legalone_get_tasks, and it provides no 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 critical behavioral traits not captured by annotations: invoke works even when MCP is not installed, returns connect/checkout links for auth/payment, requires owner/admin for writes, and explains the one-off install behind invoke. It also flags that search/describe indicate installation status. No contradictions with the annotations (readOnlyHint=false, openWorldHint=true, etc.).

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

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

The description is long but each sentence serves a purpose, covering the full workflow, edge cases, and multiple subsystems. It is front-loaded with the core purpose and flows naturally into operational details. It could be tighter by splitting into sections, but for the complexity it handles, 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?

Given the complexity (23 parameters, zero output schema), the description is remarkably complete. It explains the end-to-end flow, distinguishes between invoke and install, covers auth/payment edge cases, permission requirements, and the separate prompt library. This is more than sufficient for an agent to correctly select and invoke the tool.

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

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

With 0% schema description coverage, the description must compensate. It explains the action enum and provides context for key parameters (mcp_id, tool_id, arguments, prompt_slug, etc.) by describing their roles in the flow. While not every one of the 23 parameters is individually documented, the description offers enough semantic guidance for the primary actions and the prompt library.

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

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

The description clearly identifies the tool as the official mcp.ai marketplace, listing both its catalog and execution capabilities. It explicitly covers multiple intents ('find an MCP that does X', 'consulta um CPF', 'is there a tool for Y') and distinguishes it from sibling tools by outlining its broad scope versus the domain-specific legalone_* 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 explicit guidance on when to use each action (search → describe → invoke), differentiates invoke vs. install (one-off vs. permanent), and mentions list_tools for current callables. It also covers alternative paths like subscribe/cancel, report_bug, request_mcp, and the prompt library, making it clear when to use this tool versus others.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds the specific instruction about including a conversation array for reproduction, which hints at a non-read-only reporting action. It does not contradict annotations but also does not elaborate on side effects (e.g., creating a ticket). Given the annotations cover safety, 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?

Two sentences, no filler. The first sentence states the purpose, the second gives a key usage instruction. Every word earns its place. Perfectly sized and front-loaded.

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

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

Given the tool's simplicity (3 params, no output schema), the description covers the basic purpose and offers one crucial usage hint. However, it omits details about what happens after reporting (e.g., confirmation, ticket ID) and what 'context' means. For a feedback tool, this 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?

Schema description coverage is 0%, so the description must compensate. It only provides meaning for 'conversation' ('Include the conversation array with recent messages for reproduction'). The 'message' parameter is self-explanatory but not explicitly described, and 'context' is completely unexplained. The description adds minimal additional semantics beyond the raw schema.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb (report) and resource (bug/feature/feedback), distinguishing it from sibling Legalone data operations. However, it doesn't explicitly differentiate from other potential reporting tools, though none exist among siblings.

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

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

The description gives an explicit usage instruction: 'Include the conversation array with recent messages for reproduction.' It implies when to use (when reporting an issue) but does not provide guidance on when not to use or mention alternative tools. Since the tool is generic, no exclusion contexts are 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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'Show' aligns with these traits. The description does not add behavioral context beyond those annotations, such as exact return format or what may happen in error cases, but nothing contradicts 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 sentence, front-loaded with the action, and contains no redundant or filler wording. It provides exactly the necessary information with maximum 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 zero-parameter, read-only, idempotent version query tool, the description is complete. It tells the agent what the tool exposes and leaves no significant assumption gaps.

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

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

The tool accepts zero parameters and the schema description coverage is 100%, so there is no parameter complexity for the description to clarify. The baseline of 4 is appropriate 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 uses a specific verb ('Show') and names a specific resource: 'current MCP platform and adapter versions.' This is unambiguous and clearly differentiates the tool from the many legalone_* and other 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?

The intended use case is implied: call this tool when you need MCP platform and adapter version information. However, it does not explicitly mention alternatives such as toolkit_info or define when not to use it. Since the tool is extremely simple, the implied usage is acceptable but not fully 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 read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat those. It adds value by specifying what state is returned (connection status, accounts, catalog counts), which helps the agent anticipate side-effect-free introspection. No contradictions with annotations.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and lists the exact data returned. No filler or redundancy; every word contributes to clarity.

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

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

Given the tool's simplicity (no params, no output schema), the description adequately covers what the agent needs to know: what the tool returns. It does not specify output format or potential pitfalls (e.g., whether it requires prior authentication), but for a read-only status tool, this is sufficient. Could mention when to use it, but that's covered by usage guidance.

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 no parameters, so the baseline is 4 per the rubric. The description doesn't need to add parameter details, and the empty schema aligns with the tool's zero-input nature. No additional semantic enrichment is necessary.

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 verb ('Returns') and resource ('current toolkit state'), and enumerates specific details (installed MCPs, connection status, connected accounts, catalog tool counts). This distinguishes it from siblings like show_version (version only) and authenticate (connection setup), which serve different purposes.

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

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

The description implies usage for checking toolkit status but provides no explicit when-to-use guidance or alternatives. It doesn't mention exclusions (e.g., 'use connect to establish connections') or suggest when this tool is preferable over show_version or marketplace. The intent is clear but not stated as guidance.

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