SmartCredit+ Hipotecas

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

Annotations already cover the safety profile (readOnly/openWorld=false/destructive=false), and the description adds substantial behavioral context beyond them: entity anonymization, exactly what is returned (top 5, TIN with bonus, initial and post-euribor tranches, effort, discard reasons) and what is deliberately withheld (unbonified TIN, bonus percentages). It also flags the consent precondition.

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 core function and then the returned fields and limitations; nearly every clause carries information. It is a dense single paragraph, but a minor structural split between output and constraints would aid scanning.

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?

No output schema exists, so the description must carry return-value burden and does so thoroughly, listing the fields returned and their exclusions. The main gap is the unresolved parameter semantics for a tool with 8 required inputs and low schema coverage.

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 only 38%, below the threshold at which the schema alone suffices, so the description is expected to compensate. It only gestures at the input scope ('solo usa datos de la operación y económicos') without explaining any individual parameter such as finalidad, provincia, plazo_anos or the nested titular 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?

Specific verb+resource: it counts matching mortgage products and returns the five best options by cuota, with a precise enumeration of the returned fields. It is clearly distinguishable from calculation siblings. However, it never names or contrasts any of the sibling tools, so differentiation relies on inference.

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

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

Usage is implied by the description of a matching/search flow (data in, ranked offers out), and it states the prerequisite that no personal data is required. But there is no explicit 'use this when' guidance and no routing against mortgage_evaluar_viabilidad, mortgage_prescoring_perfil or mortgage_calcular_cuota.

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 safe read-only, non-destructive, closed-world profile. The description adds real behavioral context beyond that: the data is anonymous, does not identify the entity, does not expose the unbonused TIN, and does not give per-bonus percentages — useful limits on what an agent can expect.

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 what the tool lists, then the negative constraints, in three tight sentences with no filler. Every clause carries information; structure is clean and scannable.

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?

There is no output schema, so the description carries the return-content burden, and it does describe the fields a listing includes (type, purpose, bonused TIN, bonification types). Combined with annotations covering safety, an agent has 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?

With 0% schema description coverage the description must compensate, and it does name both parameters, spelling out the 'tipo' enum values (Fija, Mixta o Variable) and the concept of 'finalidad'. It does not enumerate the finalidad values (vivienda_habitual, segunda_residencia), leaving a small gap.

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

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

States a specific verb and resource: an anonymous list of active mortgage products, and enumerates the fields returned (tipo, finalidad, TIN con bonificación, bonificaciones). It partially distinguishes itself from the mortgage_* siblings by stating 'No evalúa una operación concreta', but it does not name the tool it is not (e.g. banking_buscar_ofertas).

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 exclusion 'No evalúa una operación concreta' implies this is for browsing the catalog rather than assessing a specific case, which points away from the evaluar/simular siblings. However, no explicit when-to-use rule or named alternative is given, so the 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=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it tells the agent the payload includes connected domains, the tool set available to it, and that a call limit exists (implying throttling). It stops short of describing response format or freshness of the status.

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 with the resource front-loaded ('Estado del Gateway de SC+') followed by the three things it returns. No filler, no 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 no-argument, no-parameter status tool with rich safe-read annotations, the description is nearly sufficient: it tells the agent what information it will obtain. Minor gap is that it does not say whether the status reflects live connectivity or how it should be interpreted if domains show as disconnected.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-parameter tool is 4. The enumerated return contents are a useful substitute for the missing output schema.

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

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

The description states exactly what the tool reports: gateway status covering connected domains, tools available to this agent, and its call limit. That is a specific resource plus an enumeration of what the status contains, clearly distinguishing it from the banking/mortgage calculation siblings. It falls short of a 5 only because it never contrasts itself with 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?

There is no explicit 'use this when...' statement, but the listed contents (available tools, call limit) strongly imply the intended context: discovering capabilities and quota for this agent. Usage is inferable rather than stated, and no exclusions or alternatives are named.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is clear. The description adds that the tool performs a comparison between two repayment strategies, which hints at output content, but discloses no further behavioral traits such as calculation assumptions or output format.

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

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

The description is a single, front-loaded sentence with no filler, making it highly concise. However, given the tool has five parameters and no output schema, it is arguably too terse to be optimally structured for the task.

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 5-parameter calculator with no output schema, the description is incomplete. It states the high-level purpose but omits parameter details, output format (e.g., savings amount, new payment/term comparison), and when to use this tool over sibling calculators, leaving significant gaps for correct invocation.

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

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

Schema description coverage is only 40% (tin and comision_pct only), and the description provides zero parameter semantics. The three required parameters (capital_pendiente, meses_restantes, importe_amortizar) have no explanations in either schema or description, leaving the agent to infer units and meaning from names alone.

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

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

The description states a specific calculation: savings from early repayment, comparing reduce installment vs reduce term. It clearly differentiates from sibling calculators (cuota, capacidad, cambio) by focusing on amortización anticipada, though it does not name any sibling 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?

The description implies usage (when evaluating early repayment and comparing two strategies) but offers no explicit when-to-use guidance, prerequisites, or alternatives like mortgage_calcular_cuota. Usage context is inferred from the purpose statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the computed outputs (new payment, savings, costs, payback period), which is useful since there is no output schema, but it says nothing about assumptions, rounding, or result limitations.

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

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

A single sentence that front-loads the decision question ('si compensa cambiar') followed by the outputs. No waste; only slightly terse for a 6-parameter tool.

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 calculator with no output schema, listing the return content is a reasonable substitute, and annotations carry the safety profile. However, the overlap with mortgage_calcular_cuota ('nueva cuota') is never resolved, and the undocumented parameters are left entirely to inference.

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 67% (tin_actual, tin_nuevo, gastos_cambio, meses_nuevo_plazo documented; capital_pendiente and meses_restantes undocumented). The description adds no parameter meaning whatsoever, so it fails to compensate for the two parameters left undocumented 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 states a specific resource (cambio de hipoteca) and enumerates concrete outputs — nueva cuota, ahorro, gastos, and cuándo se recuperan — so an agent can distinguish it from a plain payment calculator. It does not, however, name or contrast with the many sibling mortgage tools (e.g. mortgage_calcular_cuota).

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?

'Si compensa cambiar la hipoteca de banco' strongly implies the usage scenario (evaluating a bank switch/refinance decision), which is better than nothing. But there is no explicit when-to-use versus alternatives, no prerequisites, and no exclusions, leaving routing 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?

With annotations covering the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), the description adds substantive domain behavior: the 35%/45% effort thresholds, 90%/70% financing by home type, and the 10% fallback for purchase costs when no comunidad is given. That exposes the calculation model rather than restating the annotations, though it does not disclose defaults for obra_nueva or plazo_anos.

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, each earning its place: purpose/outputs first, then criteria, then the comunidad conditional. Dense but front-loaded and free of filler, with only minor strain from packing multiple thresholds into one sentence.

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

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

Without an output schema the description correctly enumerates the three return values (max loan, max price, savings), which is its strongest completeness signal. It falls short by not explaining the effect of plazo_anos or obra_nueva and by giving no indication of result format, leaving gaps for a computation tool with eight parameters.

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

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

Schema description coverage is only 50%, so the description carries extra weight and does clarify how comunidad drives tax calculation and how tipo_vivienda switches financing between 90% and 70%. However, obra_nueva, plazo_anos, and the required ingresos_mensuales_netos receive no added explanation, leaving half the parameters without semantic guidance.

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 precise verb+resource (calculating borrowing capacity from net income and debts) and enumerates the concrete outputs: máximo préstamo, precio máximo de vivienda, ahorro necesario. It explicitly positions itself relative to the viabilidad sibling ('usa los mismos criterios que la viabilidad de la compra'), so an agent can separate it from mortar_calcular_cuota or mortgage_evaluar_viabilidad without opening 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?

The description explains the criteria that govern the calculation and gives a conditional rule about the comunidad autónoma, but it never states when to choose this tool over the sibling evaluar_viabilidad, calcular_cuota, or simular_primera_vivienda. Usage is implied rather than instructed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real context by disclosing what is computed (monthly payment, total paid, interest) and the conditional rate logic per mortgage type, though it says nothing about input rejection or rounding behavior.

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

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

Three short sentences, front-loaded with the core output and then the per-mode parameter routing. No filler and every clause carries information an agent needs.

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 an 8-parameter calculation tool with no output schema and annotations covering safety, the description adequately covers the modes and outputs. The only mild gap is that it does not explain plazo_anos or the annual amortization table flag, but these are self-evident from their schema descriptions.

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?

At 75% schema coverage the schema documents most parameters, so the baseline is 3. The description exceeds it by explaining the cross-parameter dependency between tipo and which rate fields to supply for each mode, which the schema does not spell out; plazo_anos remains undocumented 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 states a specific verb+resource: it computes the monthly payment (cuota mensual), total paid, and interest for a fixed, variable, or mixed mortgage, and it names the three rate modes. It is clear what the tool produces, but it never distinguishes itself from siblings such as mortgage_calcular_capacidad or mortgage_simular_primera_vivienda.

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 strong per-mode invocation guidance (Fija: tin; Variable: euribor + diferencial; Mixta: tin during anos_fijos then euríbor + diferencial), which is essentially 'which parameters to use when'. However it gives no guidance on when to choose this tool over alternative mortgage tools, so usage context 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=true, destructiveHint=false and openWorldHint=false, so the agent knows this is a safe, closed-domain computation. The description adds genuine value beyond that: it discloses that the amounts are approximate and that the returned notes carry conditions which can alter them, i.e. outputs are estimates with caveats rather than authoritative figures.

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 tightly packed sentences with no filler: the first front-loads the scope and cost components, the second front-loads the caveat about accuracy. Nothing is repeated from the schema or 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 read-only, 4-parameter estimator with no output schema and no nested objects, the description covers scope, the conditional tax branches and the reliability caveat. The only minor gap is that it does not hint at the shape of the returned breakdown, though the mention of notes partially covers that.

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 only 50% (obra_nueva and precio_vivienda have no schema description). The description compensates by tying comunidad and itp_joven together (regional ITP with youth rate) and by explaining what obra_nueva actually switches (IVA + AJD, or IGIC + AJD in Canarias), giving real semantic meaning to the two undocumented booleans.

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 gives a specific resource ('Desglose de impuestos y gastos de comprar una vivienda') and enumerates exactly what is covered (ITP/IVA/AJD/IGIC, notaría, registro, tasación, gestoría), so the agent can immediately tell this is a transaction-cost estimator rather than a payment or capacity calculator. It never explicitly contrasts itself with siblings like mortgage_calcular_cuota or mortgage_calcular_capacidad, which caps it at 4 under the rubric.

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 which tax regime applies under which condition (ITP by region with the youth rate, vs IVA+AJD for obra nueva), but that is calculation logic, not when-to-use guidance. There is no statement of when this tool should be chosen over alternatives, no prerequisites, and no exclusions.

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

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

Annotations already declare readOnly/openWorld=false/destructive=false, so the safety profile is covered. The description adds genuinely new behavior: the input is restricted to economic data and age, and no name/DNI/contact data is needed, plus it signals the informed-consent premise behind consentimiento_informado. It stops short of describing the output structure or sensitivity to the parameters.

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, front-loaded with the verdict categories before the conditional behavior and the data-minimization note. Every sentence carries information, though the enumeration of outputs is tight enough to require a re-read.

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 13-parameter, read-only, no-output-schema tool, the description covers what is returned (categories, max price, cuota, effort, costs, gaps) and the key conditional mode, plus privacy constraints. Coverage is strong; the remaining gap is that default-sensitive parameters like plazo_anos and itp_joven are not contextualized in the description.

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

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

With 69% schema coverage the schema carries most parameter documentation, but the description adds real meaning not present in the schema: the dual behavior of precio_vivienda (estimate max affordable price when omitted) and the scope of inputs actually consumed (ingresos, deudas, ahorros, edad). It does not explain plazo_anos, tin or itp_joven defaults beyond what the schema already states.

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 ('Evalúa') and resource (compra/viabilidad) and enumerates the four outcome classes and the outputs (precio máximo, cuota, esfuerzo, gastos, qué falta). This distinguishes it clearly from siblings like mortgage_calcular_capacidad or mortgage_calcular_cuota, which produce single figures rather than a viability verdict.

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

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

Explicitly defines a conditional usage mode: 'Sin `precio_vivienda` devuelve el precio máximo que encaja', which tells the agent when the tool is a reverse-solve versus a direct check. It does not, however, say when to prefer this over mortgage_prescoring_perfil or mortgage_calcular_capacidad, so the sibling routing is left implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the output arrives as a PDF attachment or a download link valid for 24 hours, a summary is also returned, and the report is branded and points to scplus.es. These delivery/link-lifetime details are exactly the kind of trait annotations do not capture.

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-loading the deliverable before the return format and the optional-field note. Every clause carries information; the only minor slack is that the branding/link detail could be trimmed, but it is not padding.

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 12-parameter, 9-required tool with no output schema and a nested 'titulares' array, the description does the important work of explaining what is returned (PDF plus summary) and how it is delivered. The enums and field-level requirements are self-documenting in the schema, so the remaining gap — no guidance on how the viability/prescoring inputs are derived — is modest.

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 only 50% across 12 parameters, so the description should compensate more than it does. It does add real meaning for 'nombre' — that it is optional and only personalizes the first line, and that surnames, DNI and contact data are not required — but the remaining parameters are left entirely to 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 names a specific verb and deliverable ('Genera un informe en PDF') and specifies its contents (viabilidad + prescoring) plus branding and an external link. It is clearly distinguishable from the sibling calculators by being the report/deliverable generator, but it never names or contrasts an alternative, so it stops short of full sibling differentiation.

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

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

Usage is implied rather than stated: an agent infers this is the final reporting step that packages viability and prescoring, but there is no explicit when-to-use, when-not-to-use, or pointer to mortgage_evaluar_viabilidad / mortgage_prescoring_perfil as the tools that compute the inputs. The clarification about what data is not needed (apellidos, DNI, contacto) partially guides invocation without routing it.

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

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

Annotations already declare readOnly/openWorld=false/destructive=false, so the safety profile is covered. The description adds genuinely useful behavioral context: the output is a fixed-rule estimation and not an authoritative bank decision, plus a data-minimization statement (no name, DNI or contact data needed) that tells the agent what the tool will and won't consume.

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 what the tool returns before the estimation caveat and data-scope note. Every clause carries information, though the second sentence packs several ideas (estimation nature, input scope, privacy) that could be separated for easier scanning.

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?

There is no output schema, so the description carries the burden of describing return values, and it does so well (score, letter, per-category semaphore, strengths/weaknesses/alerts). Combined with the input-scope note, an agent has enough to call it correctly, with the only shortfall being partial parameter explanation against a 55% schema coverage and multiple required fields.

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 55%, so the schema documents only part of the 11 parameters. The description partly compensates by naming the categories derived from inputs and clarifying the data scope, but it does not explain required fields such as consentimiento_informado, plazo_anos or the titulares structure beyond what the schema already conveys. Baseline 3 is appropriate for this mid-level coverage.

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

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

The description states a specific deliverable: a 0–100 score plus an A–E letter for a given operation, broken down by category (effort, financing, job stability, savings, age at maturity) with strengths, weaknesses and alerts. That is a concrete verb+resource an agent can recognize. It does not, however, distinguish itself from close siblings like mortgage_evaluar_viabilidad or mortgage_calcular_capacidad.

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 frames the tool as a prior estimate with fixed rules, 'not a bank's study,' which implicitly positions it before a real lender assessment (mortgage_solicitar_estudio), and it notes it only needs operation and holder economic data. But it never explicitly says when to prefer this over the other mortgage siblings or names an alternative, leaving the routing 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=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds substantive domain behavior beyond that: 90% financing, a 35% effort ratio, and the rule that expenses use regional taxes when comunidad (and edad) is supplied and fall back to a 10% estimate otherwise.

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 primary purpose front-loaded, followed by the key assumption (90% financing / 35% effort) and the tax-handling rule. No filler, though the tax sentence is somewhat compressed.

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 10-parameter tool with no output schema and only 50% schema coverage, the description covers the core intent and key assumptions but leaves the remaining inputs and the shape of the result unexplained, so it is only adequately complete.

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

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

Schema coverage is 50%, and the description clarifies the role of comunidad and edad (tax computation) and the financing/effort assumptions. However, several parameters (m2, ahorros, plazo_anos, ahorro_mensual, deudas_mensuales) remain undocumented in both the schema and the description, so the gap is only partly bridged.

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 goal: determine how much income and savings are needed to buy a first home and how many years it takes to accumulate the down payment. This clearly separates it from sibling calculators like mortgage_calcular_capacidad or mortgage_calcular_cuota, though it never names an alternative 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?

The scenario (first-home purchase, young buyer via the edad/ITP mention) is implied and the community/age context hints at when it applies, but there is no explicit when-to-use guidance and no named alternative to route between this and the other mortgage_* tools.

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

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

Annotations already declare the safe read-only, non-destructive, closed-world profile. The description adds meaningful context beyond them: the tool only returns a link, the person fills the form themselves, and no personal data is received or stored — a useful privacy/behavior guarantee.

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 tightly written sentences, front-loaded with the core deliverable and followed by the sequencing context and the privacy note. 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?

No output schema exists, so the description carries the return-value burden and does so explicitly (it returns a link to an external form). For a zero-parameter tool it gives everything an agent needs to select and call it.

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

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

Zero parameters, so by rule the baseline is 4; the schema is empty and fully covered, and there are no parameter semantics the description needs to compensate for.

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 action and deliverable — 'devuelve el enlace al formulario' — plus the resource (the scplus.es form for a mortgage study). It also situates itself against siblings by naming the preceding steps ('una viabilidad, un prescoring o unas ofertas'), so an agent can distinguish it from mortgage_evaluar_viabilidad, mortgage_prescoring_perfil, and the offer 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?

Clear context for use: this is the step to proceed with an advisor after a viability, prescoring, or offers. It gives the trigger condition well but offers no explicit exclusions (e.g. when NOT to use it versus continuing with simulations).

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