Orientación sobre tratamiento de agua, de Aguas SB. Agua de pozo, vertidos y reutilización: qué hacer, con lo publicado por Aguas SB. Solo consulta.
Scored across 6 tools
obtener_conocimiento and orientar_caso_agua both take a water type and return informational content, so an agent could reasonably confuse them; the descriptions do draw a line (parameters/docs vs. company approach/next steps) but the boundary is subtle. consultar_aguas_sb also overlaps with obtener_conocimiento, though its LLM-based free-form nature is explicitly called out as differentiator.
Five of six tools follow a clear verb_noun Spanish pattern (consultar_aguas_sb, estimar_depuracion, obtener_conocimiento, orientar_caso_agua, preparar_solicitud_estudio). Only 'procedimiento' breaks the pattern as a bare noun, a minor deviation.
Six tools is a well-scoped set for a consultative/reference server covering question answering, estimation, documentation, orientation, request drafting, and procedural guidance. Each tool has a distinct role and no filler.
The surface covers the full informational lifecycle: learn, orient, estimate, draft a request, and follow the legal procedure, with submission intentionally excluded (read-only, human sends). A minor gap is the absence of any way to check status or handle a resulting estimate, but this matches the stated scope.
Responde a una pregunta libre con un modelo de lenguaje a partir de lo publicado por Aguas SB (potabilización doméstica y de pequeñas comunidades, depuración industrial con oxidación avanzada, reutilización, control de cloro y pH, lavado de áridos, ensayos y alquiler), y enlaza la página de origen. Es la única herramienta que usa un modelo: útil cuando los documentos de obtener_conocimiento no cubren la pregunta o se pide una respuesta redactada, también en inglés. Solo consulta; no envía nada.
| Name | Required | Description | Default |
|---|---|---|---|
| idioma | No | Idioma de la respuesta (por defecto, el de la pregunta) | |
| pregunta | Yes | La pregunta en lenguaje natural (español o inglés). Sin datos personales. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), and the description reinforces with 'Solo consulta; no envía nada'. It adds genuinely new behavioral context: it is the only LLM-backed tool (with implied cost/latency) and it returns a link to the source page, which is distinct from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose before the parenthetical topic list, and the routing rule and read-only note come last. The long domain enumeration is the only mild verbosity, but it is arguably useful for matching questions to this 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 Q&A tool with no output schema, the description covers purpose, routing, language support, and the source-link return element, which is enough for correct invocation. It stops short of describing answer length, latency, or handling when nothing is published, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – both 'pregunta' and 'idioma' are documented in the schema, including the default-language behavior and enum. The description only echoes the language option ('también en inglés') without adding format or constraint detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: answers a free-form question using an LLM over Aguas SB's published material, and explicitly flags itself as the only model-backed tool. The topic enumeration (potabilización, depuración, reutilización, control de cloro/pH, etc.) makes scope concrete enough to distinguish it from other siblings at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use rule ('útil cuando los documentos de obtener_conocimiento no cubren la pregunta o se pide una respuesta redactada') naming the alternative tool and the condition that selects it, plus a language qualifier ('también en inglés'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cuenta en orden de magnitud para la depuración de un vertido: con el caudal y la DQO o la DBO₅ devuelve la carga diaria, los habitantes equivalentes, cuánto hay que quitar para cumplir un límite, el tamaño, la energía y el fango de un biológico aerobio (parámetros de manual), los riesgos de cada camino, el primer paso según el sector y qué tipo de especialista consultar. Determinista, sin modelo de lenguaje. Útil cuando se conoce el caudal y la carga de un agua residual. No es un proyecto: el diseño real se hace con analítica y, en oxidación avanzada, con ensayo.
| Name | Required | Description | Default |
|---|---|---|---|
| sector | No | ||
| destino | No | ||
| dqo_mg_l | No | DQO media en mg/L (si se conoce) | |
| dbo5_mg_l | No | DBO₅ media en mg/L (si se conoce) | |
| produccion | No | Cómo es la producción: regular todo el año, irregular (paradas, picos) o de campaña | |
| caudal_m3_dia | Yes | Caudal de agua residual en m³ al día | |
| limite_dqo_mg_l | No | Límite de DQO de la ordenanza o la autorización, en mg/L (opcional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent profile, and the description adds genuinely new behavioral context: it is deterministic with no language model, it is an order-of-magnitude ('orden de magnitud') estimate using rule-of-thumb ('manual') parameters, and it is explicitly not a substitute for a real design. These precision and limitation disclosures go beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the output list are front-loaded in the first long sentence, with usage caveats in the closing sentences. The output enumeration is dense but each clause carries distinct information; only minor trimming is possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates what the tool returns and flags the precision ceiling, which an agent needs to interpret results. The optional inputs (sector, destino, produccion, limite) are only loosely implied, leaving a small gap for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71% and most parameters are self-documenting via types/enums. The description only names caudal and DQO/DBO₅ in passing and adds no syntax or meaning for 'sector', 'destino', 'produccion' or 'limite_dqo_mg_l' beyond the schema, so it does little more than the structured fields already do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('cuenta... para la depuración de un vertido') and then enumerates the concrete outputs (carga diaria, habitantes equivalentes, tamaño, energía, fango, riesgos, especialista). This is clearly distinguishable from siblings like orientar_caso_agua or obtener_conocimiento, which are advisory/knowledge tools rather than deterministic calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear positive condition ('Útil cuando se conoce el caudal y la carga de un agua residual') and an explicit exclusion ('No es un proyecto: el diseño real se hace con analítica... y con ensayo'). It does not, however, name a specific sibling as the alternative for those out-of-scope cases, so routing remains partly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve los documentos públicos de Aguas SB sobre un tipo de agua: qué mide cada parámetro, qué decide el tratamiento, cómo trabaja la empresa y qué datos hacen falta. Determinista, sin modelo de lenguaje. Útil para responder preguntas generales sobre ese tipo de agua. Material público revisado. Solo consulta.
| Name | Required | Description | Default |
|---|---|---|---|
| filtro | No | Opcional: palabra o tema para devolver solo los documentos que lo tratan (p. ej. "perla", "ensayo", "nitratos", "cloro"). Si nada coincide, se devuelven todos. | |
| tipo_de_agua | Yes | ||
| incluir_metodo | No | Opcional (por defecto true): incluir el documento «cómo trabaja Aguas SB». |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real context beyond them: "Determinista, sin modelo de lenguaje" tells the agent output is a fixed document set, not generated text, and "Material público revisado" signals vetted content. "Solo consulta" merely restates readOnlyHint, but the two added facts earn a 4.
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 most important fact (what it returns) is front-loaded in the first sentence, and the rest is short declarative clauses. There is minor redundancy—"Solo consulta" duplicates readOnlyHint—but no wasted sentences.
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 retrieval tool with no output schema, the description adequately covers behavior (deterministic, no LLM, reviewed public material) and scope. The handling of a non-matching filtro is left to the schema, which documents it, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with the filtro and incluir_metodo parameters well documented in the schema, while tipo_de_agua's enum values carry no per-value description. The description references "un tipo de agua" but adds no syntax or semantics beyond the schema, so the baseline 3 for adequate schema coverage applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Devuelve") and resource ("documentos públicos de Aguas SB sobre un tipo de agua") and enumerates the content it covers (qué mide cada parámetro, qué decide el tratamiento, cómo trabaja la empresa, qué datos hacen falta). This makes the tool's scope clear, but it does not differentiate itself from the semantically close sibling consultar_aguas_sb, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Útil para responder preguntas generales sobre ese tipo de agua" implies when the tool is appropriate, but there are no explicit when-not conditions and no named alternatives among the siblings (consultar_aguas_sb, orientar_caso_agua, etc.). Usage is only implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Para un tipo de agua, cómo plantea Aguas SB el caso: qué decide el tratamiento, qué ofrece, qué datos conviene aportar y en qué página seguir (y qué herramienta de cálculo hay, si la hay). Determinista, sin IA. Solo consulta.
| Name | Required | Description | Default |
|---|---|---|---|
| descripcion | No | Descripción breve del caso (opcional). Sin datos personales. | |
| tipo_de_agua | Yes | consumo (pozo, manantial, vivienda), residual (depuración y vertido), reutilizacion (agua depurada que se quiere volver a usar) o aridos (lavado de áridos) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive behavior, and the description adds value by stating 'Determinista, sin IA' and describing the informational content returned (treatment decision, offer, data to provide, follow-up page, calculation tool). This is useful context beyond the annotations, though it does not detail response format or failure 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?
The description is compact and front-loaded: it names the input condition first, then lists the returned guidance, then flags determinism and read-only nature. Every clause contributes, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only orientation tool, the description covers what the tool does and what the response will contain. Although there is no output schema and the exact return structure is not specified, the described output scope and safety annotations leave the agent with enough context 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 100%, so both parameters are already documented in the schema, including the enum meanings and the privacy note for descripcion. The description adds only a high-level mapping ('para un tipo de agua') and no parameter-level semantics beyond that, matching the baseline for fully covered schemas.
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 ('orientar') with a concrete resource (a water case by water type) and spells out what the tool returns. It is clear and self-contained, but it does not explicitly differentiate itself from sibling tools such as consultar_aguas_sb or procedimiento.
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 opening 'Para un tipo de agua' gives a clear triggering context, and 'Solo consulta' implies a read-only orientation use. However, there is no explicit when-to-use vs. when-not-to-use guidance or mention of alternatives among the siblings, so usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redacta el texto de una solicitud de estudio del agua para Aguas SB a partir del caso, con los datos que conviene añadir. No envía nada ni maneja datos personales: devuelve el texto y la dirección del formulario (https://aguassb.com/contacto/), que la persona revisa y envía.
| Name | Required | Description | Default |
|---|---|---|---|
| descripcion | Yes | El caso con las palabras de la persona. Sin datos personales. | |
| tipo_de_agua | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them: it does not send anything, does not handle personal data, and returns both the draft text and the destination form URL. That is meaningful disclosure for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, then the safety/return boundary. No filler or restatement of the title, though it is terse enough that a little more routing guidance could have been included without bloat.
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, and the description covers the return shape (draft text plus form URL), which is the key missing piece. With annotations carrying the safety profile and only two simple parameters, the definition is close to sufficient, missing only explicit alternative-routing guidance.
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%: descripcion is documented, but tipo_de_agua (an enum of consumo/residual/reutilizacion/aridos) has no description in the schema. The phrase "a partir del caso, con los datos que conviene añadir" hints that extra data improves the draft but does not explain what tipo_de_agua controls, so the description only partially compensates for the 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 ("Redacta el texto de una solicitud de estudio del agua para Aguas SB") and scopes it to a case plus supporting data, so the agent knows it produces draft text rather than sending anything. It does not name or contrast with any sibling (consultar_aguas_sb, estimar_depuracion, orientar_caso_agua), so differentiation must be inferred from the function name.
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?
Implied usage is clear from the domain — draft a study request from a described case — and the boundary "no envía nada... la persona revisa y envía" tells the agent this is a pre-send step. However there is no explicit when-to-use versus orientar_caso_agua or procedimiento, and no stated prerequisites for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paso a paso de un trámite habitual en España: pedir una autorización de vertido (alcantarillado o cauce), pedir información pública sobre una depuradora, encargar una analítica de agua de consumo, o solicitar un estudio a Aguas SB. Con el marco legal y las competencias. Orientación general; no tramita.
| Name | Required | Description | Default |
|---|---|---|---|
| tarea | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint safety. The description adds value by clarifying that the tool provides general orientation and does not actually process or execute the procedure, which is useful operational information beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences convey purpose, scope, all options, legal context, and a disclaimer with no redundancy. The front-loaded phrase 'Paso a paso de un trámite habitual en España' immediately establishes the tool's function.
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, idempotent tool with a single enum parameter and no output schema, the description is complete: it states what the user gets, the geographical scope, the covered topics, and that the tool does not perform real transactions. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining the one parameter. It enumerates all four enum options in natural Spanish with helpful elaborations, such as 'alcantarillado o cauce' for discharge authorization. It does not provide exact enum code mappings, but the single parameter makes this easy to infer.
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 this tool provides step-by-step guidance for common water procedures in Spain and lists four concrete use cases. It does not explicitly name or differentiate from sibling tools, but the 'no tramita' caveat helps separate it from processing-oriented 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 usage context is implied: use this tool when the user asks about the listed procedures such as discharge authorization, public information about a treatment plant, or water analysis. It does not explicitly state when to prefer a sibling tool or provide exclusion criteria beyond 'no tramita'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimar_depuracionconsultar_aguas_sbobtener_conocimientoorientar_caso_aguapreparar_solicitud_estudioprocedimientoPrecios de obra en España (Base BuildGets 2026) y lectura de presupuestos BC3/FIEBDC-3 de Presto.
Subvenciones, licitaciones y boletines oficiales de España y Europa para tu IA. Gratis, sin login.
Cited home water treatment answers, part matching and sizing calculators for AI agents.
Subvenciones, licitaciones y contratos adjudicados de España, de fuentes oficiales. Solo lectura.
Add one secure layer between your agents and this server.
