Server Quality Checklist

Tool Scores

• confirmar_prestamoA
  4.1/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the full burden. It discloses that after calling this tool, the widget shows a keypad for PIN entry, and it clearly states that the PIN will not appear in chat or any response received by the agent. This provides useful behavioral context beyond a simple 'records acceptance', though it does not detail the tool's return value or error handling.

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

  Conciseness5/5

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

  The description is well-structured: it starts with the core purpose, then explains typical invocation and agent-initiated invocation, and finally clarifies the PIN flow. Every sentence adds value, with no redundant filler. It is appropriately sized for the tool's simple nature.

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

  Completeness4/5

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

  For a simple tool with one boolean parameter and no output schema, the description covers the main context: what the tool does, when to call it, and what happens after. It does not mention return values, but given the tool's simplicity and the fact that the widget proceeds to PIN entry, this is a minor gap. Overall, the description is fairly complete.

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

  Parameters2/5

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

  The input schema has only one boolean parameter 'acepta_terminos' with 0% description coverage. The description implies the parameter should be true when the user accepts, but it never explicitly states what true/false means or how to set it. Since schema coverage is zero, the description should compensate, but it does not add direct parameter-level meaning.

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

  Purpose5/5

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

  The description opens with 'Registra la aceptación de términos y condiciones del préstamo', which clearly states the action (records acceptance) and the resource (loan terms and conditions). It also distinguishes this tool from siblings by explicitly noting that PIN authorization is handled internally by the widget, not by this tool.

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

  Usage Guidelines4/5

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

  The description explains when to use the tool: normally invoked by the widget when the user accepts terms via the interface button, and also when the user explicitly accepts in chat (with an example phrase). It also provides a clear when-not by stating that PIN authorization is done by an internal widget tool and that the PIN never appears. However, it does not explicitly name a sibling tool as an alternative, so it falls slightly short of a 5.

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

• autorizar_con_claveA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that the tool is internal and returns a result, but does not describe the result format, error behavior, or side effects. The strong prohibition on agent invocation adds some behavioral context, but details are lacking.

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

  Conciseness5/5

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

  The description is two sentences, front-loads the purpose, and immediately delivers the key warning. Every word earns its place without fluff.

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

  Completeness4/5

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

  Given the tool's simplicity (one parameter, no output schema) and the explicit instruction that the agent must not use it, the description sufficiently covers what an agent needs to know. It omits return-value details, but those are irrelevant since the tool is not for agent use.

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

  Parameters3/5

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

  The schema already fully describes the pin parameter as a dynamic 4-digit key. The description only adds that the PIN comes from the user keypad, which is minor context and does not significantly enhance understanding of the parameter.

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

  Purpose5/5

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

  The description clearly states the tool receives a PIN and returns an authorization result, and explicitly marks it as internal to the widget, which distinguishes it from the sibling loan-processing tools.

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

  Usage Guidelines5/5

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

  It explicitly instructs that the agent must NOT invoke the tool, which is the ultimate usage guideline. This clearly signals when not to use it and provides no ambiguity about its intended caller.

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

• capturar_monto_y_fechaA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral burden. It discloses that the tool registers data (state-changing), triggers server-side calculation of three plans, advances the widget to the next step, and returns a message with the calculated plans. This provides a clear picture of the side effects and return value, though it does not mention error handling or state reversibility.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded with the core action ('Registra...'). Each sentence adds value: purpose, consequences, usage context, and return behavior. It is appropriately concise for the tool's complexity and contains no redundant fluff.

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

  Completeness4/5

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

  Given the absence of an output schema and annotations, the description effectively explains the full behavior, including the return value and when to use it. It covers the prerequisite and subsequent flow, making it nearly complete for an agent. Minor gaps include lack of error behavior specs, but these are mitigated by schema constraints.

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

  Parameters3/5

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

  Schema coverage is 100% (both parameters have descriptions in the schema), so the baseline is 3. The description reinforces the parameter meaning (amount in soles, day 1-28) and gives a concrete example, but does not add materially new semantic information beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool captures the amount (in soles) and payment day (1-28) for an existing loan request initiated with `iniciar_solicitud_prestamo`. It also explains the result (calculation of three payment plans) and its role in the flow, distinguishing it from sibling tools by referencing the prerequisite and next step.

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

  Usage Guidelines4/5

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

  The description gives explicit context on when to call: normally the widget calls it after form submission, and the AI can call it directly when the user provides both values in chat. It also states a prerequisite (loan must already be initiated), which acts as a when-not condition. However, it does not explicitly name alternative tools or exclusions beyond the prerequisite.

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

• consultar_estado_solicitudA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It states the tool is non-mutating ('No modifica nada ni afecta al widget') and that it returns a text summary, which is useful. However, it does not disclose behavior for edge cases, such as what happens if no solicitud exists or if data is incomplete, leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core purpose and followed by usage examples. Every sentence serves a purpose; there is no fluff or repetition of schema information.

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

  Completeness4/5

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

  For a simple no-parameter read-only tool, the description covers purpose, usage, and non-mutating behavior adequately. It lacks guidance on failure modes or preconditions (e.g., no existing application), but overall it is complete enough for an agent to use it correctly in the given context.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds meaning context by explaining what the summary covers ('en qué paso va, qué datos se capturaron, si ya autorizó'), which helps an agent infer what information it can retrieve even though there are no parameters to document.

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

  Purpose5/5

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

  The description uses a specific verb 'Devuelve un resumen en texto' and clearly states the resource (solicitud de préstamo) and the content (step, captured data, authorization state). It also distinguishes itself from mutation siblings by explicitly saying 'No modifica nada ni afecta al widget'.

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

  Usage Guidelines4/5

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

  The description explicitly says when to call it: 'cuando el usuario te pregunte por el estado de su solicitud' and provides concrete example phrasings. However, it does not mention when not to use it or contrast with the sibling 'estado_prestamo', so it lacks explicit exclusions or alternative guidance.

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

• capturar_cuenta_destinoA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosure. It reveals that the tool confirms the disbursement and generates an operation number, indicating significant side effects. It also transparently marks the tool as internal and off-limits to the agent, though it stops short of detailing permissions, reversibility, or failure modes.

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

  Conciseness5/5

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

  The description is two concise sentences, with the functional purpose stated first and the critical warning delivered immediately after. Every word earns its place, and the structure front-loads the most important information for the agent.

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

  Completeness5/5

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

  For a tool that the agent is explicitly forbidden to invoke, this description is complete: it explains what the tool does internally, what inputs it expects, and, crucially, tells the agent not to use it. No output schema is needed given that the agent will never see the results. The description fully suffices for its intended audience.

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

  Parameters3/5

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

  The schema has 0% description coverage, so the description must add meaning. It identifies 'cuenta destino del desembolso' and 'forma de pago (automatico/manual)', which directly maps to the two parameters but does not add validation, formatting, or behavioral differences between payment methods. The explanation is minimal but sufficient to understand what each parameter represents.

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

  Purpose5/5

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

  The description clearly states the tool receives the destination account and payment method, generates an operation number, and confirms the disbursement. It uses specific verbs and resources, and its role as an internal widget step distinguishes it from sibling tools like initiating a loan or choosing a payment plan.

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

  Usage Guidelines5/5

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

  The description explicitly says 'NO debe ser invocada por el agente' (must not be invoked by the agent), providing an unambiguous exclusion. It also places the tool in the context of post-authorization internal widget flows, making it clear when it should (not) be used.

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

• elegir_plan_pagoA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the side effect (widget advances to terms confirmation), the return value (message with monthly installment, total payment, interest), and a prerequisite (amount and day captured). This goes beyond simple operation semantics, though it does not address error conditions or auth requirements.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the primary purpose, then usage context, then return value. No redundant information, every sentence earns its place.

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

  Completeness5/5

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

  For a simple one-parameter selection tool with no output schema, the description covers the essential aspects: what it does, when to call it, prerequisite state, side effect, and return value. It is fully self-contained for an agent to invoke correctly.

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

  Parameters4/5

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

  The schema has 0% description coverage, but the description compensates by explaining the meaning of the plan choice (12, 24, or 36 cuotas) in the context of the flow. It does not explicitly name the parameter 'cuotas' but the enum values are clearly tied to the plan selection. The description also adds output semantics beyond the schema.

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

  Purpose5/5

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

  The description clearly states a specific action ('Selecciona uno de los tres planes de pago disponibles') with a precise resource (12, 24, or 36 cuotas) and context (solicitud with monto and día already captured). It also distinguishes from sibling tools by placing it in the flow before confirmation.

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

  Usage Guidelines4/5

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

  Explicit guidance is provided: normally the widget calls it on user click, and the agent can call it when the user states a plan choice in chat. It also implies the prerequisite that amount and day must already be captured. However, it does not explicitly mention when not to use it or name alternative tools.

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

• estado_prestamoA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses that the tool is internal, returns the loan status in structuredContent, and should not be invoked by the agent. This goes beyond the schema, which has no parameters, and gives the agent a clear behavioral guardrail.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with purpose and then the critical restriction. Every word earns its place; there is zero unnecessary information.

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

  Completeness5/5

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

  For an internal tool that the agent must not invoke, the description is complete. It states what the tool does and explicitly forbids its use. Sibling tools provide context for what the agent should use instead, but the description itself suffices for its intended purpose.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline score is 4. The description adds no parameter-specific details, but none are needed. The mention of 'structuredContent' hints at the return format, which is useful.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'devuelve el estado actual del préstamo en structuredContent' (returns the current loan status in structuredContent). It uses a specific verb and resource, and explicitly labels it as an internal widget tool, distinguishing it from the agent-facing sibling tools.

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

  Usage Guidelines4/5

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

  The description explicitly states 'NO debe ser invocada por el agente' (should not be invoked by the agent), providing a clear when-not-to-use directive. However, it does not name an alternative tool, so it does not fully meet the 'alternatives' criterion for a 5.

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

• reiniciar_solicitudA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses the behavioral consequences: all captured data is lost ('Se pierden todos los datos capturados hasta el momento') and the widget returns to the first step with empty fields. This gives the agent a complete picture of the side effects.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loaded with the core action and consequence, followed by usage examples. No redundant information is present.

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

  Completeness5/5

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

  For a simple reset tool with no parameters and no output schema, the description covers purpose, behavior, and usage triggers. It is complete for the agent to understand when and how to invoke it.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema confirms this with an empty properties object. The description adds no parameter-specific details, but none are needed; the baseline for 0-parameter tools is 4.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Descarta la solicitud actual y devuelve al usuario al primer paso del flujo' which specifically identifies the resource (the request/application flow) and the action (discard and reset). It distinguishes from siblings like 'iniciar_solicitud_prestamo' by focusing on resetting an existing request rather than starting one.

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

  Usage Guidelines5/5

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

  It explicitly tells when to call: 'Llámala cuando el usuario te pida empezar de nuevo' with concrete example phrases, giving the agent clear trigger conditions for when this tool is the right choice.

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

• iniciar_solicitud_prestamoA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool shows an interactive widget, that the user captures day, installment plan, PIN, and destination account step by step, and that only the suggested amount can be pre-filled from context. This is rich behavioral detail that goes beyond a simple 'starts a loan request'.

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

  Conciseness5/5

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

  The description is well-structured and front-loaded: it starts with the core action, then the widget behavior, followed by the critical rule and parameter guidance. Every sentence provides essential information, and the examples are brief and illustrative. No wasted words.

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

  Completeness5/5

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

  Given the tool's role as an entry point with no output schema and no annotations, the description provides complete context: when to call it, what it does, what the widget handles, and how to handle the optional parameter. It also implicitly guides the agent away from asking questions that the widget will handle, making it fully self-sufficient.

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

  Parameters5/5

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

  Although the schema already covers the only parameter (monto_sugerido) at 100%, the description adds significant meaning by explaining how to infer it from conversational context, giving concrete examples ('una laptop de 3500'), and specifying when to omit it. This exceeds the baseline expected for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's function: it starts a new loan request at Banco D by showing an interactive widget. It distinguishes itself from sibling tools (capturar_monto_y_fecha, elegir_plan_pago, etc.) by being the entry point that triggers the whole flow, with the widget handling subsequent steps.

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

  Usage Guidelines5/5

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

  The description gives explicit, actionable instructions: call immediately when the user expresses interest, do NOT ask for any data beforehand, and only infer the monto_sugerido parameter when a clear amount is mentioned. This provides strong when-to-use guidance with clear exclusions, fulfilling the dimension fully.

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