Subastech — subastas judiciales de inmuebles (BOE)

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the authorization prerequisite (verified account, scope `alertas:write`), which is not present in the structured fields.

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 with zero filler; the action semantics come first and the auth requirement second, so an agent gets the key constraint immediately.

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?

An output schema exists, so return values need no explanation, and the description covers action, non-destructive scope, and auth requirements. It is only slightly short on how this differs from alertas_editar for an agent choosing among five sibling alert tools.

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 100% and both parameters are documented there, including where `id` comes from (alertas_listar) and what `activa` true/false mean. The description only restates the toggle semantics, so the baseline of 3 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?

Specific verb pair (activar/pausar) plus resource (alerta) and an explicit scope qualifier ('sin borrarla' / 'tuya'), which separates it from alertas_eliminar. It stops short of naming alertas_editar or alertas_listar as adjacent options, so an agent must still infer the boundary with editing.

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 'sin borrarla' implies the contrast with alertas_eliminar and usage is reasonably implied by the toggle framing, but there is no explicit when-to-use/when-not-to-use statement or routing to alternatives such as alertas_editar for changing alert contents.

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 the annotations (which only declare it is not read-only/idempotent/destructive), the description discloses three concrete traits: the auth requirement (verified account + `alertas:write` scope), a side effect (a confirmation email is sent on creation), and quota behavior (alert/channel limits depend on plan via `ajustes`). These are exactly the auth-needs and rate-limit context the rubric rewards.

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?

Five tightly packed sentences, front-loaded with the creation action and followed by requirements, side effect, limits, and the preview recommendation. No filler, though the density of separate clauses makes it slightly more than the bare minimum needed.

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 6 params, nested objects, and an output schema, the description covers the practical gaps: purpose, prerequisites, side effects, limits, and a safer alternative. Return values are handled by the output schema, so nothing essential 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?

Schema description coverage is 100%, including enums and nested criteria/quiet_hours docs, so the schema carries parameter semantics. The description only restates the top-level groups (criterios, tipos, cadencia, canales) without adding new meaning, which is the correct baseline of 3.

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 a specific verb and resource ("Crea una alerta de subastas") and enumerates what the alert is composed of (criterios, tipos de aviso, cadencia, canales), so an agent immediately knows the shape of the payload. It also names a sibling (alertas_previsualizar), making it distinguishable from the other alertas_* 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?

Gives a clear prerequisite (verified account with scope `alertas:write`) and explicitly routes the agent to `alertas_previsualizar` before creating. There is no explicit "when not to use" (e.g. prefer alertas_editar for existing alerts), so it falls just short of full routing 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 cover the safety profile (destructiveHint=false, idempotentHint=true), lowering the bar. The description still adds value beyond them: it declares an auth requirement (verified account, scope `alertas:write`) and a notable side-effect (no email is sent). It omits that omitted fields are required-vs-replaced semantics, but the auth and no-notification disclosures are genuine additions.

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, front-loaded with the core action and scope, then the operational caveat. No filler; every clause 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 nested-object mutation with 7 params, rich schema coverage, an output schema, and annotations, the description covers purpose, auth, and the no-email behavior. Its main omission is update semantics (full replace vs partial) and plan-gating notes that live only in the schema, but overall it is complete enough to call 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 100%, so the nested schema fully documents every field, enum, and constraint. The description's list of editable fields mirrors what the schema already shows, adding no syntax or format detail beyond it. Baseline 3 is appropriate when the schema carries the load.

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 a specific verb (Modifica) and resource (una alerta existente), and even enumerates which fields can change (nombre, criterios, tipos, cadencia, canales, horas de silencio). It does not explicitly contrast with sibling alertas_crear, though the 'existente' qualifier implicitly differentiates an update from a create.

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: this is the update operation for an existing alert, and the required `id` from alertas_listar signals a prerequisite. But the description states no explicit when-to-use/when-not guidance and never names the alternative (alertas_crear) or dependencies. Adequate-but-with-gaps.

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 destructiveHint=true and idempotentHint=true, so permanence is partly covered; the description reinforces it and adds genuinely new context via the auth/scope requirement. It still doesn't state whether the alert must be active, whether it's soft vs. hard delete beyond 'permanente', 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?

Two short sentences, front-loaded with the action and its permanence, followed by the precondition. 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?

An output schema exists, so return values needn't be described. Auth requirement, permanence, and target are all covered; only edge-case behavior (missing ID, already-deleted alert) is unaddressed.

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 100% and the single `id` parameter is already documented as coming from `alertas_listar`, so the schema does the heavy lifting. The description adds nothing about the identifier format, which is acceptable given full schema coverage — baseline 3.

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 a specific verb+resource ('Elimina una alerta'), scopes it to the caller's own alerts ('tuya'), and notes permanence. It is clearly distinguishable from the alertas_* siblings by name, but it never explicitly contrasts itself with alertas_editar or alertas_listar.

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 a real precondition (verified account, scope `alertas:write`), which tells the agent whether the call can succeed. However, it offers no when-to-use vs. alternatives guidance — e.g., that this is the irreversible counterpart to alertas_editar or how it relates to alertas_listar for discovering IDs.

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, so the bar is low. The description still adds real value beyond them: the required account and `alertas:read` scope, and the pagination contract (20 per page max, follow via `total`/`paginas`/`hasMore`).

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 tight sentences: purpose first, then the auth prerequisite, then the pagination mechanics. Every sentence carries information; 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?

With an output schema present, returns need not be described, and the description correctly focuses on the auth scope and pagination workflow. Slightly incomplete only in not surfacing the `limite` alias, but nothing essential for a correct call 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?

Schema coverage is 100%, so the baseline is 3. The description restates the `pagina`/`por_pagina` pagination and the 20-per-page cap, but omits the `limite` alias parameter documented in the schema, adding little beyond what the schema already conveys.

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 a specific verb ('Lista') and resource ('tus alertas de subastas') and enumerates the returned facets (criterios, tipos de aviso, cadencia, canales, estado). Among the sibling alert tools (crear/editar/eliminar/activar/previsualizar), the read/list verb makes this unmistakably the retrieval operation.

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

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

It supplies a prerequisite (requires an account with scope `alertas:read`), which is useful selection context. However, it never states when to prefer this over siblings like alertas_previsualizar nor any when-not-to-use condition, so usage is only implied.

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 already covering safety (readOnly, non-destructive), the description adds valuable context: it requires an account with `alertas:read` scope, advanced criteria require Pro plan and are ignored otherwise (informing in `ajustes`), and it returns warnings with `fix`. This goes beyond annotations meaningfully. It does not detail rate limits or other behavioral traits, but it's solid.

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

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

The description is front-loaded with purpose, then requirements, then plan limitations. It is reasonably concise, though the plan-pro caveat could be slightly more concise. 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?

The tool has a complex nested schema and an output schema exists, so the description needn't explain return values. It covers scope requirements and plan limitations, which are crucial. It could mention the output structure more (e.g., `ajustes`) but the output schema likely covers that. Overall complete enough.

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 100%, so the schema already documents all parameters. The description adds no parameter-level semantics beyond what the schema provides. Baseline 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 the tool previews an alert before creation, returning match count, a sample, and warnings with applicable `fix` for suspicious criteria. It distinguishes from siblings like alertas_crear by being explicitly a previsualization. However, it does not name alertas_crear or other siblings directly, so it's clear but not maximally 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?

It says 'Antes de crear una alerta' which gives clear context for when to use it. It does not explicitly state when not to use it or name the alternative tool, but the usage context is strong.

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?

Goes well beyond the readOnly/idempotent/destructive annotations by disclosing required auth scope, plan-tier gating, the exact degraded return ('locked' with 'upgradeUrl'), and that it consumes no quota. These are precisely the operational traits an agent needs that structured annotations cannot convey.

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 dense sentences with zero filler: purpose first, then requirements, then quota. Every clause carries information; front-loaded and appropriately sized.

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 an output schema present, the description needn't explain return values, and it correctly covers prerequisites, plan gating, and quota. Combined with full param documentation, an agent has everything needed to call 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 coverage is 100% and the single 'id' parameter is fully documented in the schema (10-char public identifier), so the schema does the heavy lifting. The description adds nothing about parameter format, which is the correct baseline when coverage is complete.

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 a specific verb+resource: produces a viability verdict ('veredicto de viabilidad') plus defined axes (cargas, posesión, rentabilidad, titularidad) for an auction. This distinguishes it from siblings like 'subasta' (raw data) and 'informe' (report), so an agent knows it delivers an analytical judgment, not raw lookup.

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

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

Provides concrete usage conditions: requires an account with scope `informes:read` and Pro plan or higher, and explains the fallback behavior for Radar/Starter (`locked` with `upgradeUrl`). It doesn't explicitly name when to prefer this over 'informe'/'subasta', but the gating conditions make applicability 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 establish the read-only, idempotent, closed-world, non-destructive profile, so the bar is lower. The description still adds real context: no account required, and that unauthenticated calls return only active records while authenticated calls also surface archived ones flagged `archivada: true`. That is useful behavioral disclosure, though it omits any error/not-found handling.

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, front-loaded with the action and code types, then the account-dependent behavior. Efficient overall, though the parenthetical and dual 'sin cuenta/con cuenta' clause make the second sentence slightly 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?

An output schema exists, so return-value description is unnecessary, and the single parameter is fully specified. The description covers access model and code types adequately; the only real omission is routing guidance relative to buscar_subastas.

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 a single parameter at 100% schema coverage, the schema already documents `codigos` fully, including the 1..5 bound. The description's 'hasta 5' merely restates maxItems without adding format or validation detail beyond the schema, so baseline 3 is correct.

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 a specific verb+resource ('localiza subastas del BOE a partir de códigos') and enumerates the accepted code types. It is clear what the tool does, but it does not distinguish itself from the obvious sibling buscar_subastas, which also searches auctions.

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 only implied: the agent infers it should be used when it holds a catastral reference, CRU, IDUFIR or BOE id. It never states when to prefer this over buscar_subastas, nor any exclusions, so the when-to-use guidance is left to inference.

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, yet the description adds substantial behavioral detail: official BOE data plus per-listing URL, `locked` responses with `upgradeUrl` for gated fields, silent degradation of `orden: score` to `recent` and ignoring `solo_viables` (surfaced via a `degradado` field), a 20-per-page cap, and rejection of undeclared parameters. This is exactly the extra context structured fields cannot carry.

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 purpose is front-loaded in sentence one, followed by access model, plan gating, and pagination in a logical order. It is dense and somewhat run-on, but nearly every clause carries actionable 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?

With an output schema and full annotations present, the description still covers the tricky operational details an agent needs: plan-gated fields and their fallbacks, alias resolution, page limits, and parameter rejection. Nothing essential for correct invocation appears to be 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond it by documenting the `limite`/`por_pagina` alias precedence, the 20-item page cap, the plan-conditional behavior of `orden: score` and `solo_viables`, and the strict rejection of undeclared params, adding real meaning to specific 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 first sentence gives a specific verb ('Busca') and resource ('subastas judiciales de inmuebles del BOE') and enumerates the full filter surface (provincia, municipio, tipo, precio, superficie, texto, zona, estado). It clearly conveys scope, though it never names a sibling (e.g. buscar_por_codigo, similares) to distinguish itself from the other search-like 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 states the tool is public and requires no account, and explains that certain fields need a Pro plan, which implies the usage context. However, it never says when to choose this over alternatives like buscar_por_codigo or similares, leaving selection to inference.

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 (destructiveHint=true, idempotentHint=true), the description discloses that the operation releases an order draft, that completed/cancelled sessions are left unchanged, and that an idempotency-key is required in addition to ucp-agent. This is meaningful behavioral context, not a restatement of annotations.

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

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

Three short sentences, each carrying distinct information: what the tool does, its state semantics, and its required metadata. The core action is front-loaded and there is no filler or repetition of the title.

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

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

For a mutation with an output schema and full parameter documentation, the description covers the main invocation needs: object to cancel, effect on drafts, idempotence, and required metadata. It could be more complete by explicitly routing to complete_checkout for finishing a checkout, but nothing essential for a correct call 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?

Schema description coverage is 100%, so the baseline is 3. The tool-level mention of meta['idempotency-key'] is useful for emphasis but duplicates what the meta property description already states ('Obligatoria en complete_checkout y cancel_checkout'); the id parameter's source ('de create_checkout') is also already in the schema.

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

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

The description opens with a specific action and resource: 'Cancela una sesión de checkout UCP abierta', and adds a concrete effect ('libera cualquier borrador de pedido'). This clearly separates cancel_checkout from siblings like create_checkout, complete_checkout, get_checkout, and update_checkout.

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 states the applicable context—only an open checkout session should be cancelled—and that completed or cancelled sessions are unaffected ('Una sesión completada o cancelada no cambia'). It does not explicitly name alternatives or say when to use complete_checkout instead, so it stops short of full routing 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 idempotentHint=true and readOnlyHint=false, so the description goes beyond that by detailing the exact payment flow: if a Stripe Shared Payment Token is present, it charges and delivers instantly; otherwise it escalates and redirects. It also notes that included reports complete without charge and that meta['idempotency-key'] is required. This is rich behavioral context beyond the structured hints.

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 packs several essential details: the main action, two payment paths, the report exception, and the idempotency-key requirement. It is front-loaded with the purpose and then explains conditions. It is appropriately sized for the complexity, though slightly dense; a bullet list might improve readability, but it remains efficient.

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

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

Given the 3 parameters, nested objects, and an output schema (not shown but present), the description covers all necessary behavior for correct invocation: the payment decision logic, the escalation path, the report exception, and the required metadata fields. Nothing an agent needs to call this tool correctly 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?

While schema coverage is 100% with parameter descriptions, the description adds critical semantic value: it specifies that the checkout parameter carries the payment credential and precisely defines the trigger (handler_id 'stripe' and credential.token starting with 'spt_'). It also emphasizes the mandatory idempotency-key in meta, which the schema only marks as optional. This goes well beyond the schema's generic text.

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 ('Completa una sesión de checkout UCP') and clearly differentiates from siblings like create_checkout, update_checkout, cancel_checkout, and get_checkout by focusing on the finalization step. It also explains the two payment outcomes, making the tool's 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 explains the conditions under which the tool charges instantly vs escalates, and mentions the report case. It does not explicitly say 'use this instead of X', but the context is clear that this is the checkout finalization tool, and the payment logic gives a strong sense of when to invoke it. It could name the alternative for non-finalized sessions but that is implied by the siblings.

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

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

Annotations only indicate readOnlyHint=false and no destructive/idempotent hints. The description goes beyond this by explaining that the checkout creation may also create or link a buyer account, that subscriptions complete in the browser, and that a UCP-Agent metadata is required. This adds transparency about side effects and prerequisites not evident from the annotations alone.

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

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

The description is a single dense paragraph that packs in product IDs, pricing, metadata requirements, and return behavior. It is not broken into sections or bullet points, making it harder to scan, but it does front-load the main purpose and includes essential details without excessive 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 complexity (nested objects, optional fields, multiple product types), the description covers key aspects: it specifies the product ID formats, pricing logic, the requirement for ucp-agent, the effect of providing buyer.email, and the return object structure. This provides a solid overall picture, though it remains somewhat dense and could benefit from clearer separation of concerns.

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?

While the schema already provides full descriptions for parameter structures, the description enriches understanding by specifying the pricing for each product ID (e.g., 49 €, 79 €, 20 €), the condition that nota-simple is charged only with verified PDF, and the idempotency-key requirement for related operations. This extra context goes beyond the schema's basic format 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 verb 'Crea' (creates) and the specific resource 'sesión de checkout UCP', and lists the exact products it covers (informe de viabilidad, nota simple registral, suscripción de Subastech). It distinguishes itself from sibling tools like update_checkout, complete_checkout, and cancel_checkout by focusing on creation.

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

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

The description does not explicitly mention when to use this tool versus the sibling tools (e.g., update_checkout, complete_checkout). It only describes its own function without naming alternatives or providing conditions for choosing among them, leaving the selection to inference.

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, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: no account/authentication is required, and it scopes what data is excluded. It does not mention rate limits or result size, but for a simple read tool that is minor.

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 sentences, zero boilerplate, with the data-scope listed first and the exclusion/alternative note last. The opening sentence packs four distinct capabilities into one long clause, which is dense though still compact 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?

An output schema exists, so return-value explanation is unnecessary, and with 100% schema coverage plus the auth and exclusion notes the agent has everything needed to call this correctly. No prerequisites, formatting constraints, or boundaries are left implicit.

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 100%, so the baseline is 3. The description adds meaning beyond the schema: it flags that property-type values must be EXACT matches for filtering, and documents the returned municipality key format (`provincia:municipio`) that an agent otherwise would not know. The `estado` enum is documented in the schema but not elaborated in the description.

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

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

The description enumerates exactly what the tool returns: catalog totals, provinces with active/historical auctions, property types, and municipality lookup. It explicitly draws its boundary against a sibling by stating it does NOT include market statistics and naming `mercado` as the tool that does. An agent can distinguish this from `mercado` and `buscar_subastas` without opening any schema.

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 states the access condition ('Pública, sin cuenta') and routes market-statistics needs to the alternative tool with its plan requirement ('herramienta `mercado`, plan Pro'). This gives clear context for when to pick this tool, though it stops short of an explicit 'use this when you need aggregate catalog numbers' instruction.

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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely new behavioral context: it is public, requires no account, and answers come from a human-written knowledge base rather than a language model. This tells the agent what kind of answer to expect, though it omits any limits on scope or length.

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 with the core purpose front-loaded and no filler. The parenthetical example list is slightly long but useful for scoping.

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 an output schema present, return values need not be explained, and the single param is fully documented. The description plus annotations give an agent enough to call 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 coverage is 100% and the single parameter's description already includes an example ('qué es la cesión de remate'). The description's list of concept types is not tied to the parameter and adds little beyond the schema, so the baseline 3 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?

States a specific verb ('Explica') and resource ('concepto de las subastas judiciales en España') and enumerates example domains (depósito, cargas, posesión, cesión de remate). It does not name a sibling, but the phrase 'desde la base de conocimiento de Subastech, redactada por personas' implicitly separates it from search/analysis 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 signals it is a public, no-account, non-LLM knowledge-base lookup, which implies the 'use this to understand a term' context. However, it never states when to prefer this over siblings like search, analisis_subasta, or informe, nor any exclusions. Usage is only implied.

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 it is a non-destructive, idempotent write (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the safety profile is covered. The description adds genuinely new behavior: the required auth scope and the tier-gated restriction on historical auctions, neither of which is visible in the schema.

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

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

Three short sentences with zero filler: action first, then auth requirement, then the tier restriction. Every sentence carries information the agent needs, and nothing is buried.

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 (one required param, output schema present so return values need no explanation), and the description covers action, authorization, and plan limits. Only the failure/error behavior when scope or tier requirements are unmet is left unspecified.

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

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

There is a single parameter with 100% schema description coverage, including a regex pattern and a human-readable explanation of the 10-character public ID. The description adds no further semantics about the identifier, so the schema does all the work — the baseline 3 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?

States a specific verb and resource ('Guarda una subasta en tus favoritos'), which an agent can immediately distinguish from favoritos_quitar and favoritos_listar. It does not explicitly name those siblings, but the action 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?

Gives real preconditions: an account with the `favoritos:write` scope, and the plan-dependent rule that Radar and Starter can only save active auctions while `fav.historico` is Pro+. It stops short of naming alternatives or stating what to do when the precondition fails.

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 cover the safe-read profile (readOnly, idempotent, closed-world, non-destructive), and the description goes well beyond them: required account scope, per-page cap, plan-gating of scoring/verdict/ROI/participants behind Pro, and the `locked` + `upgradeUrl` fallback when gated. That is exactly the extra context an agent needs.

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?

Dense but front-loaded: what it returns first, then preconditions, then pagination, then entitlement caveats. Every clause carries information, though the entitlement sentence is long and could be split.

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 an output schema present the description need not explain return shape, yet it usefully names `total`, `paginas`, `hasMore`, `locked` and `upgradeUrl` so the agent can drive pagination and handle gated fields. Only minor gaps remain, such as what identity the scope binds to.

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 100%, so the alias rules for `limite` vs `por_pagina` and the 1..20 bounds are already documented. The description repeats the 20-per-page cap but adds no syntax or format detail beyond the schema, which is the expected baseline.

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 a specific verb and resource: it lists the auctions the caller has saved as favorites. That clearly separates it from the write siblings favoritos_anadir and favoritos_quitar without the agent needing to open any schema.

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?

Gives the preconditions (account required, scope `favoritos:read`) and tells the agent how to page using `total`, `paginas` and `hasMore`. It does not explicitly name when to prefer a sibling, but the list/read intent is unambiguous from the name.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the required account scope `favoritos:write`, which is valuable auth context not present in 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 short sentences, front-loaded with the action followed by the prerequisite. Every word earns its place with no redundancy.

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

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

For a simple one-parameter mutation with an output schema and rich annotations, the description covers the purpose and auth requirement adequately. It could mention what happens when the auction is not already favorited, but that is a minor gap.

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

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

Schema description coverage is 100% and the single `id` parameter is fully documented in the schema, so the baseline is 3. The description adds no parameter-level semantics beyond what the schema already provides.

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 a specific verb (quita) and resource (subasta de tus favoritos), making the action immediately distinguishable from siblings like favoritos_anadir and favoritos_listar. No ambiguity about what the tool does.

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

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

Provides no guidance on when to use this tool versus alternatives; the only extra information is a prerequisite (account scope), which is behavioral context rather than usage routing. An agent gets no help deciding between favoritos_quitar, favoritos_anadir, or favoritos_listar.

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 the readOnly/idempotent annotations it discloses the access model (public, no account), the gated features (scoring, veredicto, cargas, ROI, valoración, intervinientes need Pro), and the exact failure behavior (`locked` + `upgradeUrl`). This is substantive behavioral context an agent cannot get from 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?

Front-loads the verb, resource, and returned fields before moving to access rules. Dense but every clause carries signal; only the field enumeration slightly overlaps with what the output schema already provides.

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

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

For a single-param lookup with an output schema and read-only annotations, the description covers everything an agent needs: availability, account gating, and the locked/upgrade response path. No meaningful gaps remain.

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 a single parameter at 100% schema coverage, the schema already documents that `id` is returned by `search` or can be a ficha URL. The description restates this rather than adding format or edge-case detail, so the baseline 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?

States a specific verb (read/lee) and resource (a single auction record by id), and enumerates the returned fields (`id`, `title`, `text` in Markdown, `url`, `metadata`). It is clearly a single-record fetch that consumes an id produced by `search`, distinguishing it from the search/browse 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?

Gives clear context: public access with no account needed, and notes id comes from `search` (or a ficha URL). It also states which capabilities need a Pro account. It does not explicitly name when to prefer this over siblings like `subasta`, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate those. It adds valuable context beyond annotations: the required UCP-Agent identification and the conditional presence of messages, continue_url, and order.

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, front-loaded with the main purpose and possible return states, and includes the important authentication requirement in a single additional sentence. Every element 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 full output schema, complete parameter descriptions, and annotations covering safety traits, the description provides the essential behavioral and authentication context needed for correct invocation. 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?

Schema description coverage is 100%, and both parameters have clear descriptions in the schema. The description adds a small amount of context by emphasizing the required UCP platform identification, but the schema already carries most of the semantic weight.

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: it returns the current state of a UCP checkout session by id, enumerates the possible states, and lists the fields that may be returned. This clearly distinguishes it from sibling mutation tools like create_checkout, update_checkout, complete_checkout, and cancel_checkout.

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: it queries a checkout session by id created by create_checkout, and the required meta['ucp-agent'] identification is stated. However, there is no explicit guidance about when to use this tool instead of the checkout mutation siblings, though their semantics make the distinction fairly obvious.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, yet the description layers substantial extra behavior: required auth scope, tier gating, the `unlock_required` error path, the MPP payment fallback, the guarantee that it never consumes quota or charges, and an AI-generated-text disclosure. This is exactly the kind of context annotations cannot express.

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

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

Front-loaded with purpose and sections, then progressive detail on auth, tiers, payment and quota. It is dense and sentence-heavy but every clause (sections, `locked`, scopes, tiers, no-quota, AI disclosure) earns its place, 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?

An output schema exists, so return values need not be explained, and the description still covers prerequisites, tier-dependent behavior, the error/payment path and side-effect guarantees. For a gated read tool with payments involved, nothing an agent needs to call it correctly 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?

Schema already documents both params at 100% coverage (baseline 3), but the description adds real semantic value: `basic`/`completo` are only served if already unlocked, otherwise `unlock_required` (plus a payment link) is returned, which the enum text alone does not convey.

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 a specific verb (report) and resource (auction feasibility report), and enumerates the exact sections it returns plus the `locked` behavior, which is far more concrete than the bare title. It does not name sibling tools like analisis_subasta or subasta to draw an explicit boundary, so differentiation is implicit rather than stated.

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

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

Gives clear preconditions (verified account, `informes:read` scope, tier unlock state) and explains what happens when the condition fails, which is useful context. However, it never says when to reach for this tool versus the sibling `analisis_subasta` or `subasta`, so the routing guidance is only implied.

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 non-destructive, so the safety profile is covered; the description adds genuine value beyond them by disclosing the auth scope and the plan-gated error contract. It does not mention result volume, pagination, or cost, but the output schema already covers the return shape.

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 sentence states what the tool returns and the dimensions; a second states the access requirement and failure mode. Nothing is repeated and the substantive purpose is front-loaded before the gating detail.

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

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

For a read-only, plan-gated statistics tool with a full output schema, the description covers purpose, dimensions, auth, and the denial case. It stops short of saying how both-optional parameters behave when omitted (aggregate across all provinces/types) or any result-size characteristics.

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 100%, with both `tipo` and `provincia` documented including the lowercase-slug pattern (p. ej. `madrid`). The description names the two dimensions but adds no format, matching, or cardinality detail beyond the schema, so the baseline of 3 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?

States a concrete resource (estadísticas de subastas resueltas) with the specific metrics returned (tasa de adjudicación, descuento real, precios) and the two grouping dimensions (provincia, tipo de inmueble). This is clearly more specific than a restatement of the title, but it never distinguishes itself from the nearby sibling estadisticas_publicas, which an agent could plausibly confuse it with.

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?

Gives concrete preconditions: an account with scope `informes:read` and a Pro-or-higher plan, plus the failure mode (`plan_required` with `locked`). What is missing is any explicit routing guidance against alternatives such as estadisticas_publicas or analisis_subasta, so the agent knows the gating but not the boundary case.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world. The description adds real context beyond them by naming the required auth scope (`cuenta:read`) and that an account is required, which is the key operational gating 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?

Two tight sentences with no filler; the returned content is front-loaded and the auth prerequisite is a single trailing clause. Every part 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?

An output schema exists to explain the return shape, so the description need not detail return values. It covers what the tool provides and the auth gate, which is everything an agent needs for a no-parameter read 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 takes zero parameters, so there are no parameter semantics to document; the baseline for a parameterless tool is 4. The description correctly adds no spurious parameter discussion.

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?

Enumerates concretely what the tool returns for the account: plan, report quota, available features, token scopes, usage limits, and useful URLs. The resource (account) is clear and no sibling in the list covers account-level information, so it is effectively distinguishable, though the sentence is a noun list rather than an explicit verb+resource statement.

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

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

States a prerequisite (requires an account with `cuenta:read` scope), which helps an agent confirm eligibility before calling. However, it gives no explicit when-to-use guidance or exclusions, and with no competing sibling it relies on implied usage.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is low. The description adds two things beyond them: the required auth scope `notas:read` and the fact that a URL may only become available 'cuando esté listo', implying an asynchronous readiness state.

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

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

Two sentences, front-loaded with the tool's function, then the auth prerequisite. No wasted words, though it is terse rather than richly 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?

An output schema exists, so return values need not be detailed, yet the description still usefully flags the URL/PDF payload. Auth scope is included. Missing only the explicit workflow position relative to nota_simple_pedir.

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 100%, and the schema documents pedido_id as the identifier returned by nota_simple_pedir. The description adds no further parameter detail, so the baseline 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?

States a specific resource and outcome: the status of a 'nota simple registral' order plus the URL to view or download the PDF. An agent can tell it apart from nota_simple_pedir (which creates orders) and notas_simples_listar (which lists them), though the description never names those siblings explicitly.

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

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

Provides a real prerequisite ('Requiere cuenta (scope `notas:read`)'), which is useful gating context. However, it never states when to call it rather than alternatives — e.g. that it is the polling step after nota_simple_pedir — leaving the workflow relationship 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?

Adds substantial behavior beyond the annotations: price (20 €) with retention semantics, scope requirement, the not_orderable error condition, the returned pedido_id/url/paymentLink and the guarantee that payment never completes server-side, the pedido_existente idempotency response, and a 20/day rate limit. This is exactly the extra context annotations cannot carry.

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 dense passage that front-loads the action, then conditions, returns, idempotency and limits in logical order. Every sentence carries information, though it is slightly packed for one paragraph.

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 an output schema already covering returns, the description still supplies prerequisites, error codes, payment flow, idempotency, and rate limits, leaving no operational gap for a mutation tool with these annotations.

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

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

Schema description coverage is 100%, so the `id` parameter's meaning (public auction identifier, 10 chars) is already documented in the schema. The description references CRU/IDUFIR requirements but adds no further detail about the id format beyond what the schema provides – baseline 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?

States a specific verb and resource ('Inicia el pedido de la nota simple registral de una subasta'), making it clearly distinct from sibling tools like nota_simple_estado (status) and notas_simples_listar (listing). An agent can identify the action without opening the schema.

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?

Gives concrete preconditions (verified account with scope `notas:write`, auction must have CRU/IDUFIR) and the failure mode (`not_orderable`), plus idempotency behavior. It does not explicitly name an alternative sibling tool for checking an existing order's status, so routing guidance is strong but not 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 a safe, read-only, idempotent, closed-world operation, so the bar is lower. The description adds genuinely useful behavior beyond them: a 20 € cost per nota simple and the required auth scope notas:read, plus the pagination ceiling and how to advance pages.

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 tight sentences, front-loaded with what the tool returns, then auth requirement, then pagination mechanics. Every clause carries information; minor density from the parenthetical detail, but 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?

With an output schema present, return values need not be described; the description instead covers the non-obvious prerequisites (scope, cost) and pagination workflow. Complete enough for correct invocation, though it omits any tie-breaker against sibling tools.

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 100%, so the baseline is 3. The description names pagina and por_pagina and repeats the 20-per-page cap, but it does not explain the limite/por_pagina precedence (which the schema already documents), so it adds no meaning beyond the structured 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?

States a specific verb and resource: it lists 'pedidos de nota simple registral' along with their estado, so an agent knows exactly what collection is returned. It does not explicitly distinguish itself from close siblings like nota_simple_pedir or nota_simple_estado, which is the only thing keeping it from a 5.

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 practical usage context (requires an account with scope notas:read, pagination via total/paginas/hasMore), but it never states when to pick this over nota_simple_estado (single note status) or nota_simple_pedir (create a request). Usage is implied by the listing nature rather than explicitly routed.

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, and closed-world behavior, so the safety profile is covered. The description adds auth-relevant context the annotations do not ('Pública, sin cuenta'), telling the agent no credentials are needed, though it says nothing about caching or freshness of pricing.

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

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

Two tight sentences with the resource and tier list front-loaded, then the access constraint. Nothing is padded or 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?

For a zero-parameter read tool with an output schema present, the description supplies everything the agent needs: what content is returned and that it is publicly accessible. Return-value detail is rightly delegated to the output schema.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument, fixed-content call, matching the empty 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 names the exact resource (Subastech plans) and enumerates the concrete tiers returned (Radar gratuito, Starter, Pro, Team, Enterprise) along with prices and a feature comparison. No sibling tool covers pricing or plans, so an agent can distinguish this immediately.

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 notes the tool is public and requires no account, which is useful context, but it never states when to reach for this versus other informational tools (e.g., estadisticas_publicas, explicar_concepto). Usage is implied rather than guided, and no exclusions 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 cover safety (readOnly, idempotent, non-destructive). The description adds real behavioral context beyond them: the auth requirement (scope `cuenta:read`) and the tier-dependent ranking algorithm, which changes the meaning of the returned order. Doesn't state rate limits or full return shape, but output schema 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?

Front-loads the resource and anchoring, then tacks on auth and plan-dependent behavior efficiently. Three dense sentences 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?

Covers what an agent needs for a no-param, read-only recommendation endpoint: personalization, auth scope, and algorithm variance by plan. An output schema exists so return values need not be described.

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?

Zero parameters, so the baseline is 4. The description's mention of (tipo, precio, provincias) hints at internal ranking signals rather than inputs, which is useful framing for a no-arg 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?

States a specific verb+resource: recommended auctions personalized to the user's history, with the fields used (tipo, precio, provincias), and anchors it to the known web feature «para ti». This distinguishes it from siblings like buscar_subastas and similares.

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?

Gives clear context: personalized recommendations requiring an account, with a distinct behavior difference between Pro+ (scoring ranking) and non-Pro (profile + end-date ordering). No explicit 'use X instead of Y', but the personalization requirement effectively steers agents away from it as a generic search.

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 non-destructive behavior, so the safety profile is covered. The description adds useful value by stating it is public with no account required, which annotations do not convey, but the 'máximo 15' cap merely repeats the schema and no retry/pagination behavior is disclosed.

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 dense sentence that front-loads the core scope ('últimas subastas del BOE con resultado oficial') followed by the optional filter, then the payout details. Efficient with no filler, though the trailing 'Máximo 15' is redundant with the schema.

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?

An output schema exists, so return-value explanation is unnecessary, and the description still signals the key returned fields (remate and descuento real). Combined with the auth statement and filter scope, an agent has enough to invoke it correctly; only the omission of sibling routing keeps it from full marks.

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 100%, so the schema already documents both parameters, including the provincia slug format and the 15-item cap. The description's 'opcionalmente por provincia' and 'máximo 15' add no semantics beyond the structured fields, matching the baseline of 3.

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+resource: it returns BOE auctions that already have an official adjudication result, optionally filtered by province. This 'adjudicadas' scope meaningfully distinguishes it from generic search siblings like buscar_subastas, though it never names those alternatives explicitly.

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 only implied: an agent can infer this is for querying closed/decided auctions rather than open listings, and that provincia is an optional narrowing filter. There is no explicit 'use this instead of X when...' guidance or statement of when not to use it, despite several overlapping sibling tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: it confirms no account or authentication is needed and describes the response shape and the follow-on `fetch` workflow. Minor tension: it queries an external public corpus while `openWorldHint` is false, though a bounded BOE index can reasonably be treated as closed.

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, front-loaded with the purpose, then scope/auth, then the next action. Every clause carries information — no filler and no 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?

An output schema exists, so return values need not be spelled out, yet the description still summarizes them; it also covers authentication and the follow-up call. For a single-parameter read-only search tool this is complete enough to invoke correctly, with only the sibling-routing gap as a minor omission.

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?

Only one parameter and schema description coverage is 100%, so the baseline is 3. The description repeats the schema's 'Búsqueda en lenguaje natural' wording without adding syntax, length limits (maxLength 200), or query-construction tips, so it contributes nothing new about the parameter.

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 a specific verb and resource: natural-language search over BOE judicial auctions, plus the ChatGPT deep-search compatibility and the return shape (`results` with `id`, `title`, `url`). However, it never distinguishes itself from the near-identical sibling `buscar_subastas`, leaving an agent unable to tell which search tool to pick without opening both schemas.

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?

Gives clear operating context ('Pública, sin cuenta') and an explicit next step: use `fetch` with the returned `id` to read the record. What is missing is exclusionary guidance — no statement of when to prefer this over `buscar_subastas`, `buscar_por_codigo`, or `similares`.

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, non-destructive, closed-world behavior. The description adds genuinely new context beyond that: an auth scope requirement and a plan-gated ordering rule (scoring for Pro+, fecha de fin otherwise). That material behavioral detail is exactly what annotations cannot convey.

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 dense sentence, front-loaded with the purpose before prerequisites and ordering rules. Every clause (similarity definition, scope requirement, plan-based ordering) earns its place 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?

With an output schema present there's no need to describe return values, and both parameters are fully covered by the schema. Purpose, auth requirement, and plan-dependent ordering are all given; only explicit sibling routing is missing for a full score.

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 100%, so the schema already documents both `id` and `limite`. The mention of `metodo` in the description describes ordering behavior, not an input parameter, so it adds no parameter-level meaning beyond the schema. Baseline 3 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?

States a specific resource (subastas similares to a given one) and even spells out the similarity dimensions (mismo tipo de inmueble, banda de precio, cercanía), so the agent understands exactly what is returned. It stops short of distinguishing itself from related siblings like recomendaciones or buscar_subastas.

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?

Surfaces a real prerequisite (requires account with scope `informes:read`) and plan-dependent behavior, which is implied usage context. However, it never says when to prefer this over a sibling such as recomendaciones or buscar_subastas, nor any when-not condition.

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, so the safety profile is covered. The description adds behavior annotations cannot express: a paywall boundary and a `locked` response carrying `upgradeUrl` when a section is gated. It stops short of describing completeness of the returned data or caching.

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

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

Front-loaded with the resource and the returned fields, then the access rules, then the gating behavior. Two dense sentences with essentially no filler; slightly compressed, but every clause carries 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?

An output schema exists, so return values need not be explained, yet the description usefully flags the `locked`/`upgradeUrl` shape that an agent must anticipate. For a read-only lookup tool with full schema coverage and annotations, this is complete enough; only sibling routing is unaddressed.

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 100%, so the three parameters (id, url, boe_id) are already fully documented with patterns and formats. The description restates the identifier forms (10 chars, SUB-…) and notes that boe_id yields all lots, which mirrors rather than extends the schema. Baseline 3 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?

States a specific resource (the public auction record) and enumerates the returned content: address, values, dates, result, lots and a citable summary. It also names the three accepted input forms. It never distinguishes itself from siblings such as analisis_subasta or buscar_subastas, so it stops short of a 5.

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?

Clearly frames the access context: the record is public and needs no account, while scoring, verdict, loads, ROI, valuation and participants require a Pro plan or above. That is real when-to-use guidance, though it does not say when to prefer this tool over the sibling search/analysis 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?

Discloses the replacement behavior (destructive in effect, though annotated destructiveHint=false) and the price/status recalculation side-effect. It adds state restrictions and the required ucp-agent identification beyond what annotations convey. 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?

Two sentences with no fluff: the core action is front-loaded, followed by constraints and the authentication requirement. Every clause is informative 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?

For a mutation tool with a rich schema and an output schema, the description covers the essential behavior (replacement, recalculation), state limitations, and required metadata. Nothing critical for calling the tool correctly appears to be 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?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond what the schema already documents: the 'checkout' parameter is described in the schema as 'Nuevo contenido del pedido, que sustituye al de la sesión abierta', which mirrors the description's replacement language. The meta ucp-agent requirement is also already in the schema.

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

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

States a specific verb ('Reemplaza') and a specific resource ('contenido de una sesión de checkout UCP'), and clearly identifies what is replaced (line_items y buyer) plus the recalculation of price and state. This distinguishes it from the siblings create_checkout, complete_checkout, cancel_checkout, and get_checkout without relying on the title.

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

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

Provides clear context: the tool updates an existing UCP checkout session, and it explicitly excludes sessions in complete_in_progress or terminated states. It also states the required meta['ucp-agent'] prerequisite. However, it does not explicitly name the alternative for creating new sessions (create_checkout), so the 'when vs alternatives' guidance is not fully explicit.

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