Webmotors

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

The annotations indicate idempotentHint=true and readOnlyHint=false, which means the tool may have side effects (e.g., initiating a login link). The description explains that calling with no args returns a link that requires a browser step, and calling with a token completes the login. It also mentions that the token is non-expiring if added to config. However, it does not disclose what happens on successful authentication in terms of session state or potential side effects beyond the link/token handling. Given the idempotent hint, the description does not contradict annotations but adds partial context about the two workflows. The bar is lower because annotations exist, but the description adds useful but incomplete behavioral context about session vs. permanent auth.

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 but covers all essential guidance: what to do in the browser, two alternative methods, and the parameter semantics. It is somewhat dense but not overly verbose. The structure is a bit run-on, but it front-loads the overall purpose and then explains the two options. Slightly more structure (such as bullet points) could improve readability, but as is, it is concise and earns its place.

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

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

Given the tool's complexity (auth flow with multiple steps) and the lack of output schema, the description covers the essential steps: obtaining a token via browser, providing it either via config or via parameter. It doesn't describe the output of the tool (return value when successful or failure), but since there is no output schema, the description could benefit from noting that the tool returns a link or an authentication status. However, the description is sufficient for the primary use cases and is well-suited for an agent to understand the intended flow.

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 only one parameter 'token' with no description, and schema_description_coverage is 0%. The description compensates by explaining that the token is a JWT to be pasted after the user copies it from the browser. It explains the login flow and when to provide the token vs. when to omit it. While it doesn't detail the token format (JWT is mentioned but not elaborated), it gives enough semantic meaning for an agent to use the parameter correctly. Given that the schema is almost empty, the description carries the full burden, and it does so effectively.

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

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

The description clearly states what the tool does: it authenticates the user for MCP.AI IDE agents by obtaining an access token, either via a browser login link or by accepting a pasted token. It also distinguishes between two ways of authenticating (permanent via config header, session-only via token parameter). This distinguishes it from sibling tools like 'connect' and 'marketplace' by focusing specifically on authentication.

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

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

The description provides explicit usage guidance: log in in the browser, copy the access token; best practice is to add it to the server's config as a header for permanent connection; or paste the token into the tool call for session-only login. It explains when to use which mode, and implicitly contrasts with the config-based approach. While no explicit alternatives are named among siblings, the alternatives within this tool are clearly laid out.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by disclosing the two distinct return states — authenticated:true with empty pending[] when fully connected, and connect_url plus per-install URLs when credentials are missing — which is useful behavior beyond annotation coverage.

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, both front-loaded and information-dense. Every clause earns its place: states the resource, the success case, and the failure case without any 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?

With no output schema, the description must convey return shape. It covers the two main states effectively, though the content of pending[] and the nature of per-install URLs remain unspecified. For a zero-parameter read-only status tool, this is reasonably 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?

Tool has zero parameters, so per rubric the baseline is 4. No parameter explanation needed; the description correctly focuses on return behavior instead.

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 specifies the tool returns connection status and URLs, with explicit details about connected vs missing-credential states. It doesn't explicitly distinguish from siblings like 'authenticate', but the STATUS-reporting 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?

No explicit when-to-use or when-not-to-use guidance. The status-reporting nature implies it's a pre-authentication health check, and 'authenticate' is the sibling for actually establishing connections, but no alternatives or exclusions are named.

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

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

With annotations only stating readOnly=false, openWorld=true, idempotent=false, destructive=false, the description adds substantial behavioral detail: invoke runs MCPs without installation, returns auth/payment links with retry instructions, writes require workspace owner/admin, and search/describe flag installation status. There is no contradiction with annotations; the description enriches understanding of side effects and preconditions.

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

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

The description is lengthy but well-organized: it starts with the overall purpose, then the core flow, key invoke-vs-install distinctions, action-specific notes, and the prompt library section. There is no redundancy, and each sentence adds value. Given the tool's complexity (14 actions, 23 parameters), the length is justified, though it could be slightly tighter by grouping related actions.

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

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

For a tool with no output schema and 23 parameters, this description is remarkably complete: it covers the full lifecycle (discover, describe, invoke, install, manage billing, request new MCPs) and the prompt library, plus permission requirements and edge cases (auth/payment links). Minor gaps remain, such as exact return structures for each action and detailed error handling, but the overall context is sufficient for an agent to use the tool effectively.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the central parameters: action (including each enum value's purpose), mcp_id, tool_id, arguments, query, and prompt-related fields (prompt_slug, prompt_vars). However, some parameters like immediate, tier_slug, conversation, and prompt_tool are not explicitly described, and the mapping between actions and required parameters could be more systematic. Still, it covers the majority effectively.

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

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

The description opens with a clear, specific statement: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It defines the verb (catalog/run) and resource (MCPs/tools), and distinguishes itself from sibling tools by explaining its unique role as both discovery and execution platform. The core flow (search → describe → invoke) further clarifies its purpose.

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

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

The description provides explicit when-to-use guidance: 'prefer invoke for a single/occasional use' vs install for permanent, and explains when to use search_prompts vs get_prompt. It also gives conditional instructions (e.g., 'if the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link'). This goes beyond simple context to offer actionable decision rules.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds context about including the conversation array for reproduction, which is helpful. However, it doesn't disclose what happens after submission (e.g., confirmation, tracking) or any rate limits.

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 primary purpose and a key usage hint. No wasted words.

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

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

Given the tool's simplicity (3 params, no output schema), the description is adequate but not complete. It covers the main purpose and one parameter's role, but lacks details on expected message format, context usage, and post-submission behavior. It's a minimum viable description.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'conversation' parameter's purpose (recent messages for reproduction) but does not clarify 'message' or 'context' beyond their names. The description adds some value but leaves gaps for two of three parameters.

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

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

The description clearly states the tool's purpose: reporting bugs, missing features, or sending feedback. It distinguishes itself from sibling tools, which are mostly about authentication, marketplace, and Webmotors data, by focusing on user feedback.

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

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

The description implies when to use it (when reporting issues or feedback) but does not explicitly state when not to use it or mention alternatives. It provides a hint about including conversation context for reproduction, which is useful but not a full guideline.

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, establishing it as a safe read. The description adds specificity about what versions are returned (platform and adapter), which is valuable beyond the annotations and makes the tool's behavior transparent.

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

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

A single sentence, 10 words, conveys the tool's entire purpose with no filler. Every word earns its place, and the structure is front-loaded with the primary verb and object.

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

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

This is a trivial zero-parameter informational tool with no output schema needed. The description gives the essential context (what versions are shown) and nothing more is required for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, so the parameter baseline of 4 applies. There are no parameter semantics to explain, and the schema accurately reflects this with an empty properties object. The description doesn't need to add parameter information.

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

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

The description uses a specific verb ('Show') with a clear object ('the current MCP platform and adapter versions'). It clearly identifies the tool's function and is distinct from sibling tools, which cover authentication, connection, marketplace, bug reporting, and Webmotors-specific operations.

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

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

The description implies usage context: call this when you need current version information for the MCP platform or adapter. It doesn't explicitly state 'when not to use', but with zero parameters and no competing version tool among siblings, the intended usage 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 already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds contextual value by specifying that the tool reports current dynamic state—connection status and accounts—rather than just static configuration. 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?

One dense, front-loaded sentence with no waste. Every phrase contributes meaning: 'current toolkit state,' the list of MCPs, connection status, accounts, and catalog tool counts.

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 introspection tool with strong annotations, the description is complete: it states the action and enumerates the output categories. The absence of an output schema is adequately compensated by this enumeration.

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

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

The tool has zero parameters and 100% schema coverage, so the baseline of 4 applies. The description adds no parameter-specific meaning because none is needed; it focuses on the return contents instead.

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 ('Returns') and clearly identifies the resource ('current toolkit state'), then enumerates the exact contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This is distinct from sibling tools like webmotors_search or authenticate.

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

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

Usage context is implied rather than explicit: it is obviously useful for inspecting toolkit state before or after connecting MCPs, but the description does not state when to use this over sibling info tools like show_version, nor does it mention 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds that the tool returns a list of categories, which is a small behavioral detail beyond the annotations, and it does not contradict them.

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

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

The description is a single sentence, front-loaded with the action and object, and contains no filler or redundant information. It is as concise as possible while conveying the tool's purpose.

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

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

For a zero-parameter, read-only category listing with strong annotations, the description is largely sufficient. It could mention the return format or whether categories are hierarchical, but the core purpose is clear and the schema/annotations cover the main risks.

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 is trivially complete and the description needs no parameter-level detail. The baseline of 4 applies because there are no parameters to document.

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 identifies the exact resource ('categorias de veículo da Webmotors'). It clearly distinguishes this tool from siblings like webmotors_search or webmotors_detail by focusing solely on category 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 implies the tool is for retrieving vehicle categories, but it does not explicitly state when to prefer it over alternatives such as webmotors_filters or webmotors_search. No exclusion criteria or alternative tool names are mentioned.

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

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

As anotações já indicam leitura segura e idempotência. A descrição complementa com o que o usuário receberá (specs, preços, vendedor, fotos e descrição), sem contradizer as anotações.

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

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

Texto curto, direto e informativo. A frase inicial já entrega o propósito e a frase seguinte dá a instrução essencial com exemplo, sem redundâncias.

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 com apenas um parâmetro e sem output schema, a descrição cobre o que retorna e como preparar a entrada. As anotações completam o contexto de segurança/efeito, tornando a definição autossuficiente.

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?

O schema fornece apenas o tipo 'string' e não cobre semântica. A descrição detalha que o parâmetro deve ser o slug vindo de wm_search, com exemplo prático do caminho, adicionando valor imprescindível para o uso correto.

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 usa verbo específico ('Detalhe completo de um anúncio') e identifica claramente o recurso (anúncio), diferenciando-se dos irmãos como wm_search e wm_category. O escopo é inequívoco: busca detalhes completos de um único anúncio.

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?

Instrui explicitamente a usar o 'slug' retornado por wm_search, com exemplo do formato do caminho. Fornece contexto claro de quando usar, embora não mencione explicitamente alternativas e casos de nã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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the content (brands, models, facets) but does not disclose output shape, pagination, or downstream integration details, providing only modest value beyond the annotations.

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

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

A single, front-loaded sentence that states the action, subject, examples, and purpose without any filler or redundancy. Every phrase 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?

The description is adequate for a zero-parameter, read-only tool: it names the output content and explains the intended use. It could be slightly more complete by specifying the returned structure or explicitly linking the facets to webmotors_search, but the low complexity and strong annotations keep it close to fully 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?

The tool has zero parameters and the schema coverage is trivially 100%, so there is no parameter semantic burden for the description to carry. No additional parameter detail is required.

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 action ('Lista'), the resource ('opções de filtro da busca'), and gives concrete examples ('marcas, modelos e demais facetas') plus a purpose ('montar consultas válidas'). This distinguishes it from sibling tools like webmotors_search or webmotors_category by focusing specifically on filter facets.

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 'para montar consultas válidas' communicates that this tool should be used before building search queries, which is useful context. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full exclusionary 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, covering the safety profile. The description adds that it resolves a location from free text, which is the core behavior, but does not detail the output format, potential errors, or edge cases. This is adequate given the annotations, 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 a single, concise sentence that efficiently states the tool's function and purpose. There is no wasted information or redundancy, and it is front-loaded with the verb 'Resolve'.

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

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

The tool is simple with one parameter and no output schema. The description covers the purpose and input, but does not mention the output structure (e.g., what the resolved location looks like). Given the annotations cover safety and the tool's low complexity, it is largely complete, though a note on return format would improve it.

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 parameter, 'query' of type string, with 0% schema description coverage. The description explains it accepts 'free text' (texto livre), which adds meaningful semantics beyond the type. It clarifies the expected input format, though it does not provide examples or constraints.

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

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

The description clearly states the tool 'resolves a location (city/state/geo) from free text' and its purpose is to filter searches by region. This is a specific verb+resource and distinguishes it from sibling tools like webmotors_search and webmotors_filters, which perform different actions (searching and filtering).

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 filtering search by region, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or mention sibling tools. It gives some context (preprocessing for regional filtering) but lacks explicit guidance on 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 declare readOnly, idempotent, non-destructive. Description adds bulk support and return structure, which is useful beyond annotations. No contradiction.

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

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

Two concise sentences, front-loaded with purpose and returns, then a note on bulk. Zero waste.

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

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

With only 2 parameters and no output schema, the description provides return fields, id source, and bulk capability. Missing error handling or edge cases, but adequate for this simple tool.

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

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

Schema coverage is 0%, so description must compensate. It explains 'id' as UniqueId from wm_search and mentions 'ids' for batch, adding meaning to both 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 the tool returns the average market price for a listing, tied to a specific id from wm_search. It lists the exact return fields, distinguishing it from search and detail 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?

Implies usage context (id from wm_search) but does not explicitly differentiate from alternatives like webmotors_detail or webmotors_filters. No when-not-to-use guidance.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds the response structure and downstream usage tips, going beyond the annotations. It does not mention auth or default pagination limits, but nothing contradicts the annotations and the extra context is meaningful.

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 three concise sentences: a purpose, a return specification, and downstream usage. Every sentence earns its place, with 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?

With no output schema, the description provides all return fields and the `total`/`results[]` wrapper, which is essential. It also connects to sibling tools. However, the 'path' parameter is undocumented and order semantics are vague, making it not fully complete for a 6-parameter 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 provides no descriptions (0% coverage), so the description must compensate. It explains brand/model filtering and pagination/order, covering most parameters, but 'path' remains unexplained and 'order' has no allowed values or defaults. This leaves a notable 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 searches vehicle listings on Webmotors, with filtering, pagination, and ordering. It also specifies the return shape and distinguishes itself from sibling tools by referencing wm_detail and wm_market_price.

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 the tool (searching listings) and provides cross-tool guidance: use the returned slug for wm_detail and id for wm_market_price. It does not explicitly exclude alternatives like webmotors_category or webmotors_filters, but the context is clear.

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