Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@demo-app-mcp-prestamo Quiero solicitar un préstamo de S/ 3,500"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP que muestra un widget interactivo dentro de un cliente MCP (por ejemplo, Claude Desktop) para un flujo de solicitud de préstamo online. La app pertenece a Banco D, un banco ficticio.
Es una demo educativa del estándar MCP Apps (SEP-1865). Lo interesante no es la solicitud de préstamo en sí, sino que en un mismo flujo se muestran tres niveles distintos de qué ve el agente en cada paso.
Autor: Diego Ponce de León. Los datos, la marca y los cálculos son ficticios.
Related MCP server: inflow-mcp
Cada respuesta de una tool en MCP Apps tiene dos canales:
content: texto que el agente lee.
structuredContent: JSON que va al widget (el agente no lo ve).
Con esos dos canales y el flag _meta.ui.visibility, el desarrollador decide, en cada paso, qué llega al agente. Esta demo usa los tres niveles posibles.
En esta demo ocurre al iniciar la solicitud (iniciar_solicitud_prestamo). Si el usuario mencionó un monto en el chat, el agente lo pasa como monto_sugerido y el widget arranca con ese monto pre-llenado.
El widget captura los datos y el content de la tool devuelve solo el resultado agregado. Los detalles del formulario no llegan al agente.
En esta demo ocurre en la selección de plan. Cuando el usuario elige un plan en el widget, el agente recibe un texto como "Plan elegido: 12 cuotas de S/ 320,88 (pago total S/ 3 850,56, intereses S/ 350,56)". Nada más.
La tool tiene _meta.ui.visibility=["app"], así que el cliente MCP la oculta del listado del agente. El agente ni siquiera sabe que la tool existe. Solo el widget la puede llamar, vía postMessage.
En esta demo ocurre con autorizar_con_clave (el PIN nunca aparece en el contexto del modelo, ni siquiera un intento fallido) y con capturar_cuenta_destino (el número de cuenta destino se queda dentro del widget). Cuando el flujo termina, el widget emite un ui/message explícito para avisar al agente del resultado final.
Paso 1: monto y día de pago (nivel 1). El agente detecta que el usuario quiere un préstamo y llama iniciar_solicitud_prestamo. Si el usuario mencionó un monto en el chat, el agente lo pasa como monto_sugerido y el widget arranca con ese valor pre-llenado; si no, el widget arranca vacío. El usuario ajusta el día de pago y hace clic en "Ver mis opciones".
Paso 2: elegir plan (nivel 2). El widget calcula 3 planes (12, 24 y 36 cuotas) con cuota mensual, total, intereses y TCEA. El usuario elige uno. El agente recibe solo el plan elegido y los tres valores comerciales del plan.
Paso 3: evaluación y términos (nivel 2). El widget muestra un spinner por 2,5 segundos y transiciona a "aprobado". El usuario acepta los términos.
Paso 4: autorización con PIN (nivel 3). El widget muestra un keypad numérico con countdown de 2:00. El PIN de prueba es 1234. El agente no ve la tool autorizar_con_clave en su lista y no puede llamarla. Si el usuario ingresa mal el PIN, el widget lo indica; el agente no se entera.
Paso 5: cuenta destino (nivel 3). El usuario elige a qué cuenta se acredita el préstamo y la forma de pago. Las cuentas están escritas directamente en el widget (en producción vendrían del perfil autenticado del cliente). La tool que registra la selección también es solo-widget, así que el número de cuenta no pasa por el canal del agente.
Paso 6: desembolsado (nivel 1, cierre). El widget confirma el desembolso y emite un ui/message con el resumen: "Préstamo desembolsado: S/ 3 500,00 en 12 cuotas de S/ 320,88 (TCEA 19,56%). Nº operación BD-XXXXXXXX. Débito automático el día 15 de cada mes.". Con eso el agente puede continuar la conversación con contexto del cierre.
Requisitos:
Python 3.11+
uv instalado
Claude Desktop (macOS o Windows), o cualquier cliente compatible con MCP Apps
Clonar e instalar:
git clone https://github.com/dponcedeleonf/demo-app-mcp-prestamo.git
cd demo-app-mcp-prestamo
uv syncVerificar el servidor sin conectarlo al cliente:
uv run python -m banco_d --introspectDebería imprimir el UI resource, las 9 tools con su _meta y visibility, y validar que el HTML sea correcto.
Edita ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) o %APPDATA%\Claude\claude_desktop_config.json (Windows) y agrega la entrada:
{
"mcpServers": {
"banco-d": {
"command": "uv",
"args": [
"--directory",
"/ruta/absoluta/a/demo-app-mcp-prestamo",
"run",
"python",
"-m",
"banco_d"
]
}
}
}Reemplaza /ruta/absoluta/... con la ruta real. Cierra Claude Desktop con Cmd+Q y ábrelo de nuevo. Empieza una conversación nueva y pídele un préstamo al agente. PIN de prueba: 1234.
Esta demo corre en stdio con edición manual del config del cliente. Esa no es la forma en la que un producto real se conecta a Claude Desktop u otro cliente MCP. Ninguna empresa (banco, retail, salud) le pediría a un cliente instalar Python, copiar archivos y editar claude_desktop_config.json.
En producción, un servidor MCP orientado a clientes se despliega sobre HTTPS con OAuth 2.1 y se instala vía Settings → Connectors en Claude Desktop, claude.ai u otro cliente compatible. Ese modelo permite autenticación por usuario, multi-tenencia, auditoría, control de tráfico y actualización centralizada.
demo-app-mcp-prestamo/
├── pyproject.toml
├── README.md
├── uv.lock
└── src/banco_d/
├── __init__.py
├── __main__.py # punto de entrada: python -m banco_d
├── server.py # servidor MCP: registro de tools y resources
├── sessions.py # estado en memoria por session_id
├── prestamo/
│ ├── __init__.py
│ ├── state.py # PrestamoState + cálculo cuota francesa (TNA 18%)
│ └── tools.py # 9 tools del flujo, con visibility declarada
└── views/
└── prestamo_view.html # widget de 6 pantallas + keypad + countdownReferencias útiles para leer el código:
prestamo/tools.py: el docstring del módulo separa las tools visibles al agente de las que son solo del widget. Cada entrada de la lista TOOLS lleva un tag [AGENTE] o [SOLO WIDGET].
server.py, función _tool_meta: genera el _meta.ui.visibility que el cliente MCP respeta para ocultar tools del listado del agente.
prestamo_view.html, sección PANTALLA 4: el keypad, el countdown OTP, el enlace "Solicitar nueva clave" y el emisor de ui/message post-autorización.
prestamo_view.html, sección MCP APPS: descripción de cada método JSON-RPC del protocolo y quién lo manda.
prestamo_view.html, maybeEmitUiMessage: cómo el widget envía texto al contexto del agente cuando decide hacerlo.
MIT.
Tool interna del widget: recibe el PIN que el usuario tecleó en el keypad y devuelve el resultado de la autorización. NO debe ser invocada por el agente.
| Name | Required | Description | Default |
|---|---|---|---|
| pin | Yes | Clave dinámica (4 dígitos). |
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.
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.
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.
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.
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.
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.
Tool interna del widget: recibe la cuenta destino del desembolso y la forma de pago (automatico/manual) elegidas por el usuario post-autorización. Genera el número de operación y confirma el desembolso. NO debe ser invocada por el agente.
| Name | Required | Description | Default |
|---|---|---|---|
| forma_pago | Yes | ||
| cuenta_destino | Yes |
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.
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.
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.
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.
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.
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.
Registra el monto (en soles) y el día del mes para el pago (1 a 28) de una solicitud de préstamo que ya se inició con iniciar_solicitud_prestamo. Con esos dos datos, el servidor calcula tres planes de pago (12, 24 y 36 cuotas, cada uno con su cuota mensual, intereses totales y TCEA) y el widget avanza al paso donde el usuario elige uno de esos planes.
Normalmente la llama el widget cuando el usuario envía el formulario del primer paso. Tú también puedes llamarla si el usuario te da los dos valores directamente en el chat (por ejemplo, 'quiero 3500 soles y que me cobren el día 15').
Te devuelve un mensaje con los tres planes ya calculados, para que puedas comentarlos si el usuario te pregunta antes de elegir.
| Name | Required | Description | Default |
|---|---|---|---|
| monto | Yes | Monto solicitado en soles. | |
| dia_pago | Yes | Día del mes para el débito. |
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.
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.
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.
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.
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.
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.
Registra la aceptación de términos y condiciones del préstamo. Después de esta tool, el widget muestra al usuario un keypad donde ingresa su PIN para autorizar el desembolso.
Normalmente la llama el widget cuando el usuario acepta los términos con el botón de la interfaz. Tú también puedes llamarla si el usuario acepta explícitamente en el chat (por ejemplo, 'sí, acepto los términos y condiciones').
La autorización con el PIN la hace después el propio widget con una tool interna que tú no ves. El PIN del usuario no aparece en el chat ni en ninguna respuesta que tú recibas.
| Name | Required | Description | Default |
|---|---|---|---|
| acepta_terminos | Yes |
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.
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.
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.
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.
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.
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.
Devuelve un resumen en texto del estado actual de la solicitud de préstamo del usuario: en qué paso va, qué datos se capturaron hasta el momento, si ya autorizó o no. No modifica nada ni afecta al widget.
Llámala cuando el usuario te pregunte por el estado de su solicitud (por ejemplo, 'en qué paso voy', 'qué me falta', 'cuánto era el monto que puse').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Selecciona uno de los tres planes de pago disponibles (12, 24 o 36 cuotas) para una solicitud en la que ya se capturó monto y día. El widget avanza al paso de confirmación de términos.
Normalmente la llama el widget cuando el usuario hace clic en la tarjeta de un plan. Tú también puedes llamarla si el usuario te dice cuál elige en el chat (por ejemplo, 'prefiero el de 24 cuotas').
Te devuelve un mensaje con la cuota mensual, el pago total y los intereses del plan elegido.
| Name | Required | Description | Default |
|---|---|---|---|
| cuotas | Yes |
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.
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.
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.
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.
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.
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.
Tool interna del widget: devuelve el estado actual del préstamo en structuredContent. NO debe ser invocada por el agente.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Inicia una nueva solicitud de préstamo en Banco D. Muestra un widget interactivo (una pequeña app dentro del chat) donde el usuario captura él mismo el día de pago, el plan de cuotas, el PIN y la cuenta de destino paso por paso.
REGLA IMPORTANTE: llama esta tool INMEDIATAMENTE cuando el usuario expresa interés en un préstamo. NO le preguntes al usuario por día de pago, cuotas, plan, cuenta destino, PIN, ni ningún otro dato antes de llamar la tool. El widget se encarga de capturarlos.
El ÚNICO dato que puedes inferir del contexto conversacional es el monto_sugerido (si el usuario mencionó una cifra concreta, ej. 'una laptop de 3500', 'un electrodoméstico de 1200'). Ese monto pre-llena el formulario para que el usuario no lo escriba. Si no hay cifra clara, no pases el parámetro.
| Name | Required | Description | Default |
|---|---|---|---|
| monto_sugerido | No | Monto en soles a pre-llenar en el formulario, inferido del contexto conversacional. |
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.
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.
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.
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.
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.
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.
Descarta la solicitud actual y devuelve al usuario al primer paso del flujo (captura de monto y día de pago). Se pierden todos los datos capturados hasta el momento. El widget se vuelve a mostrar en el primer paso con los campos vacíos.
Llámala cuando el usuario te pida empezar de nuevo (por ejemplo, 'reinicia', 'cancela y empieza de cero', 'quiero cambiar el monto desde el principio').
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
The main flow tools are distinct, but the inclusion of internal widget tools (autorizar_con_clave, capturar_cuenta_destino, estado_prestamo) creates potential ambiguity, especially between estado_prestamo and consultar_estado_solicitud. Descriptions help clarify, but the agent must be careful to avoid invoking internal tools.
Most tool names follow a verb_noun pattern in Spanish snake_case (e.g., iniciar_solicitud_prestamo, capturar_monto_y_fecha, elegir_plan_pago). The main deviation is estado_prestamo, which is a noun phrase, and a couple of names use 'con' (autorizar_con_clave, capturar_cuenta_destino). Overall the convention is consistent.
Nine tools is within the typical range, but three are internal widget tools that the agent should never call, inflating the count and adding noise. The effective public tool count is six, which is well-scoped for the loan application flow.
The loan request flow is fully covered from initiation through capture, plan selection, confirmation, reset, and status query. PIN and destination account steps are handled internally by the widget, so no public tools are needed for those. No obvious gaps in the agent-facing surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
An AI concierge that turns static forms into adaptive AI conversations. From any MCP client.
Agent-native dental planning MCP for plan drafts, presentations, and price estimates.
Let AI agents query data and act across all your business apps via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dponcedeleonf/demo-app-mcp-prestamo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
