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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds substantial extra behavior: it can only observe one of BMW's three conditions (12V battery) and explicitly declares the other two 'no observable por CarData', plus it requires historical series data rather than a snapshot. This is exactly the kind of limitation disclosure that helps an agent set 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?

Two compact sentences with no filler. The key limitation (only one condition observable) and the data requirement (series, not snapshot) are placed immediately after the purpose statement, so every sentence carries weight.

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 parameterless, read-only diagnostic with an output schema and rich annotations, the description covers the purpose, limitations, and data expectation. Nothing critical seems missing for an agent to decide whether to invoke 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 tool has zero parameters and schema coverage is vacuous at 100%, so there is no parameter burden for the description to carry. The description's mention of working on the historical series is behavioral context rather than parameter documentation. Baseline 4 applies.

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

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

The description opens with a specific verb-resource combination: 'Informe acotado sobre por que no llega una Remote Software Upgrade' – a targeted report on why a remote software update isn't arriving. It clearly distinguishes itself from generic diagnostics by scoping to RSU and noting CarData's observation limits, so an agent can tell it apart from 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?

It implies the use case: diagnose missing Remote Software Upgrade. It also gives a contextual prerequisite: works on the SERIES of local history, not a point-in-time snapshot, which tells when it is applicable. However, it never explicitly names sibling alternatives or states 'when not to use', so it falls short of explicit routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral context beyond those: the data is derived from SQLite and the tool does not consume API quota, which is non-obvious and important for an agent deciding whether to call it. It also discloses that the reset time is estimated and that local cache state is included.

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 main data points, and ends with a clear safety guarantee. No filler or redundancy; every word earns its place.

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

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

For a zero-parameter tool with an output schema, the description fully covers purpose, behavior, and safety. The output schema presumably documents return values, so the description need not repeat them. The only potential missing detail (auth requirements) is unlikely given read-only annotations, making this 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 tool has zero parameters and the schema is empty with 100% coverage, so baseline for 0 params is 4. The description does not need to add parameter semantics, and it correctly avoids inventing any.

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 explicitly states the tool reports how many REST requests have been spent today, how many remain, the estimated window reset, and local cache state. It uses a specific verb ('Cuantas... se han gastado') and resource (API quota), and it is clearly distinguished from sibling tools which focus on vehicle data, search, or diagnostics.

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: to check quota status, and importantly that it does not spend quota ('NO gasta cuota'), making it safe to call. It does not explicitly name alternatives or 'when not to use', but all siblings are unrelated to quota, so the usage context is clear. No exclusion conditions 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?

Beyond annotations (read-only, idempotent, open world), the description adds concrete behavioral details: raw codes only, no translation because the catalog lacks meanings, and a 12h container-cache sharing behavior. These disclosures help the agent set expectations 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?

Two dense sentences lead with the core function, then add output constraints and a caching caveat. Every clause earns its place and there is no filler.

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

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

A parameterless read tool with an output schema and rich annotations is fully covered by this description: it explains grouping, delta behavior, field limitations, lack of translation, and cache lifetime. Nothing essential is missing for correct selection and invocation.

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

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

The schema has zero properties, so there is no parameter vocabulary to document. The description adds no parameter details, but with 0 params the baseline is 4 and no compensation 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?

States exactly what the tool returns: fault memory codes grouped by control unit plus codes that appeared or disappeared since the last reading. It also states output limitations (only control unit and code, no status/date/description/translation), which clearly distinguishes it from related diagnostic tools.

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

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

The description makes the tool's limited scope clear by warning that codes are not described or translated, so an agent can infer this is not the right tool when human-readable fault definitions are needed. However, it never explicitly names alternatives or says when-not-to-use, leaving the routing decision mostly implicit.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral caveats: measurement uncertainty, OBFCM being a frozen lifetime figure rather than current consumption, and a shared 12-hour container cache. These go well beyond the annotations.

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

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

The description is dense but every sentence earns its place: first the core fuel data, then the OBFCM caveat, then the cache behavior. No redundant 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 covers all important aspects of the tool's output and caveats, including measurement error and data freshness. The output schema exists, so return-value details are already structured. Nothing critical is missing 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?

The tool has zero parameters and schema description coverage is 100%, so there is no parameter information missing. The baseline of 4 for zero-parameter tools applies.

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

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

The description clearly specifies the tool's resource: fuel tank percentage and liters, range, refuels, and real consumption. It is far from a tautology and the detail about OBFCM consumption distinguishes it from generic vehicle status tools.

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

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

The description makes the tool's domain unmistakably clear: fuel status, refuels, and consumption. It does not explicitly name alternative tools or state 'use when', but the context is strong enough for an agent to select it appropriately among the sibling vehicle-data tools.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: the output is a pre-formatted text block, pressures are compared against targets, and the result includes the date of the oldest data used, which signals data freshness. There is 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?

A single sentence front-loads the core purpose ('Bloque de texto listo para pegar en un prompt') and then uses a colon-delimited list to enumerate the exact contents. There is no filler or redundancy.

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

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

For a zero-parameter read-only tool, the description is complete: it names the output format, the specific data points included, units for tyre pressure, and a data-freshness qualifier. The presence of an output schema also reduces the need to explain return values further.

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 shows 100% coverage by having no properties. With no parameters to document, the baseline is 4; the description does not need to explain argument semantics.

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

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

The description clearly states the tool returns a ready-to-paste text block containing maintenance information: mileage, CBS items with remaining km and date, tyre pressures in bar versus targets, and the age of the oldest data used. This is a specific resource plus an explicit deliverable, though it does not explicitly contrast itself with sibling tools like get_vehicle_status or get_tyre_diagnosis.

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

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

The description implies usage when a copy-paste maintenance summary is needed and even mentions the intended use in a prompt, but it gives no explicit when-to-use versus alternatives, no exclusions, and no guidance about overlapping sibling tools. The usage context is only implicit.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds meaningful behavioral context: 'Fuente: GET /telematicData' indicates the underlying HTTP call, and 'Cache de 12 h' warns that data may be cached for up to 12 hours. This goes beyond what annotations provide and 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 two short sentences with no filler. The main purpose and data contents are front-loaded, followed by two compact implementation details (source and cache). Every sentence earns its place.

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

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

For a zero-parameter, read-only tool with an output schema and read/idempotent annotations, the description is nearly complete: it names the resource, lists key data fields, identifies the source endpoint, and notes the cache duration. The only minor gap is the lack of explicit differentiation from sibling maintenance tools, but that does not impair invocation correctness.

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 reflects that, so the baseline is 4. The description appropriately omits parameter details and instead supplies source and cache information, which is the only relevant invocation context.

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 and resource: 'Lee el contenedor de mantenimiento completo' and enumerates the included data fields (kilometraje, CBS, bateria de 12V, presiones, estado de sueno). This level of detail distinguishes it from sibling tools like get_maintenance_summary or get_vehicle_status without requiring schema inspection.

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

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

The description implies usage when a full maintenance telematics read is needed and provides useful context (source and cache), but it does not explicitly state when to use this tool versus alternatives such as get_maintenance_summary or get_tyre_diagnosis. No when-not conditions or alternative routing are given.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, but the description adds valuable behavioral context beyond that: the exclusion of pressures, the 7-day cache, and the verified BMW anomaly where an empty structure and zero values are not genuine measurements. This meaningfully informs interpretation of results.

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: it starts with the returned data categories, then gives the important exclusion, then adds caveats about reliability and caching. Every sentence carries distinct, useful information with no filler.

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

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

Given that the tool has no parameters and an output schema exists, the description covers the key remaining context an agent needs: what data is included, what is explicitly excluded, where to get that excluded data, known empty-response behavior, and cache freshness. Nothing critical is missing.

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 there is nothing for the description to add about parameter meaning. The schema already covers the empty parameter set completely, and the description does not need to compensate for any undocumented 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 names a specific resource (tyre diagnosis) and lists the concrete data categories returned: wear, defects, dimensions, mounting/manufacturing dates, season, runflat, and tread. It further differentiates itself by explicitly stating it does NOT return pressures and pointing to the telematics container for those.

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

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

The description explicitly tells the agent when not to use this tool for pressure data and where those values come from instead. The BMW warning provides condition-specific guidance: if the vehicle is a BMW, an empty structure with zeros should be treated as missing measurements, not real values.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds meaningful context beyond those annotations by specifying the API source endpoint and the 30-day cache, which informs the agent about data freshness expectations. No contradiction with annotations exists.

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

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

The description is a single concise sentence that front-loads the data contents and immediately follows with the source and caching behavior. Every element adds value without repetition 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?

For a no-parameter read-only tool with an output schema and robust annotations, the description is largely sufficient. It covers the data contents, the source endpoint, and the cache duration. Minor ambiguity remains around the meaning of 'puStep', but this does not significantly impair tool selection or invocation.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds the endpoint pattern with {vin}, clarifying that the data is VIN-scoped even though no CLI parameters are exposed. There are no parameter semantics to document further.

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 enumerates the specific contents returned by the tool: model, series, engine, construction date, equipment list, and 'puStep'. It identifies the source endpoint, making the resource and scope unambiguous, and the listed fields distinguish it from sibling vehicle tools like get_vehicle_status or get_telematic_data.

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

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

The description implies this tool is for fetching basic vehicle data, but it provides no explicit guidance about when to choose it over sibling tools such as get_vehicle_status, get_maintenance_summary, or get_fault_memory. No alternatives or exclusion criteria are mentioned.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description attempts to add a verification caveat about the CBS breakdown, but the phrasing is self-contradictory ('pendiente de verificar' vs 'verificado'), leaving the data trustworthiness unclear.

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 first sentence is concise and useful, but the second sentence is garbled, repetitive, and internally contradictory. It does not earn its place and undermines the overall clarity of the description.

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 zero parameters, a full output schema, and safety annotations, the description only needs to clarify purpose and data caveats. It conveys the core purpose but the confusing verification statement leaves important ambiguity about the reliability of the CBS breakdown.

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 parameter semantics are not a concern. The baseline of 4 applies because there is nothing the description needs to add beyond what the empty schema already indicates.

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 resource and payload: mileage and CBS maintenance reminders. It is not a tautology and conveys a specific read operation, although it does not explicitly differentiate this tool from get_maintenance_summary or other vehicle-data siblings.

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

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

The description provides no guidance about when to use this tool instead of siblings such as get_vehicle_basic_data, get_maintenance_summary, or get_fuel_status. No alternatives, selection criteria, or exclusions are mentioned.

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

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

Annotations already establish readOnly/idempotent/non-destructive behavior, so the description only needs to add extra context. It adds a 30-day cache and the source endpoint, which are useful behavioral traits not present in 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 short sentences pack the output fields, source endpoint, and cache policy without repetition. Information is front-loaded and 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?

With no parameters, a rich annotation set, and an output schema present, the description covers the remaining essentials: what is returned (VINs, mappedSince, mappingType), where it comes from, and staleness via cache. Nothing critical is missing for invoking the tool correctly.

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

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

There are zero parameters and schema description coverage is 100%, so the baseline is 4. The description has no parameter documentation burden; no additional parameter semantics are needed.

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

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

The title supplies the verb 'Listar' and the description identifies the exact resource: VINs mapped to the account, with fields mappedSince and mappingType. The source endpoint /customers/vehicles/mappings also distinguishes it from sibling get_* tools that return telematics, status, or diagnostics.

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 given for when to prefer list_vehicles over search_descriptors or get_vehicle_basic_data. The usage context is only implicit from the title and fields; there are no explicit when-to-use rules, alternatives, or exclusions.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context beyond those: it verifies that /basicData does not return puStep and explains that the tool reports the absence rather than substituting fabricated data. This tells the agent exactly what to expect when the data is missing.

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

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

Three short sentences, each earning its place: the first states the core purpose, the second prevents a critical misinterpretation, and the third explains the tool's observed behavior. No filler or redundancy.

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

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

For a zero-parameter tool with an output schema and comprehensive annotations, the description provides all necessary context. It clarifies what the tool exposes, what it does NOT expose, and how it behaves when the underlying data is absent. Nothing important is missing for correct invocation and interpretation.

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 schema description coverage is 100%, so the baseline of 4 applies. There are no parameter details to add; the description correctly focuses on the tool's purpose and behavior.

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 action and resource: 'Expone puStep, el paso de actualizacion de PRODUCTO.' It clearly distinguishes the tool from a vehicle software version, which is a likely confusion point, by stating that descriptor does not exist in the BMW catalog. It could be even stronger by naming a specific sibling tool, but the core purpose is unambiguous and differentiated.

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

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

The description gives explicit when-not guidance: it is NOT the vehicle software version and that descriptor is absent from both the BMW catalog and /basicData for this vehicle. This helps an agent avoid using it as a software-version lookup. However, it does not explicitly name which sibling tool to use instead for software-version queries, so the guidance is strong but not fully complete.

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/destructive hints. The description adds important non-obvious behavior: the catalog is a local file, has 294 entries, does not spend API quota, and accepts Spanish or English input. This goes beyond the annotations without contradicting them.

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

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

Three short, focused sentences with no filler. The main purpose is front-loaded, followed by high-value operational details such as API quota usage and language support.

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 purpose, local scope, quota behavior, and the catalog as source of truth, and the output schema handles return values. However, with no parameter descriptions in the schema and 0% coverage, the missing explanation of limit and include_electric leaves the tool incompletely 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, but it only clarifies that queries may be in Spanish or English. It does not explain the semantics of 'limit' or 'include_electric', which are not self-evident from the schema alone.

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 names a specific verb and resource: 'Busca en el catalogo telematico local de BMW CarData (294 descriptores).' It also clearly states the tool is the 'unica fuente de verdad' for which descriptors exist, which distinguishes it from sibling data-retrieval 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 clear context on when to use the tool: it searches a local catalog, accepts Spanish/English queries, and does not consume API quota. It does not explicitly name alternatives or exclusions, but it makes the intended use obvious.

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