CE3X-MCP-Server

Overview Schema Source Related Servers Discussions Admin

Calcular Puentes Termicos

calcular_puentes_termicos

Read-onlyIdempotent

Calculate linear thermal transmittances and total heat loss from thermal bridges per CTE DA DB-HE/3 to quantify facade slab edges, window perimeters, and pillars accurately.

Instructions

Calcula las transmitancias térmicas lineales (psi en W/m·K) y la pérdida térmica global por puentes térmicos integrados según el Documento de Apoyo DA DB-HE / 3 del Código Técnico de la Edificación.

Cuándo usar: Invoque esta herramienta para cuantificar el impacto térmico de frentes de forjado, contornos de hueco y pilares en fachada en lugar de usar valores globales estimados.

Comportamiento y efectos secundarios: Operación analítica de solo lectura (Read-Only). Sin efectos secundarios en disco.

Input Schema

TableJSON Schema

Name	Required	Description
`ano_construccion`	Yes	Año de construcción del edificio para asignar la transmitancia lineal de referencia según normativa histórica aplicable.
`longitud_pilares_m`	No	Longitud total de pilares integrados en fachada exterior en metros (m).
`perimetro_huecos_m`	No	Perímetro total de contornos de huecos y ventanas en metros (m).
`perimetro_forjado_m`	No	Longitud total de frentes de forjado en fachada en metros (m).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 17, 2026
- addedInput schema / properties / ano_construccion / description
```
Added value: +"Año de construcción del edificio para asignar la transmitancia lineal de referencia según normativa histórica aplicable."
```
- addedInput schema / properties / ano_construccion / maximum
```
Added value: +2050
```
- addedInput schema / properties / ano_construccion / minimum
```
Added value: +1800
```
- addedInput schema / properties / longitud_pilares_m / description
```
Added value: +"Longitud total de pilares integrados en fachada exterior en metros (m)."
```
- addedInput schema / properties / longitud_pilares_m / minimum
```
Added value: +0
```
- addedInput schema / properties / perimetro_forjado_m / default
```
Added value: +0
```
- addedInput schema / properties / perimetro_forjado_m / description
```
Added value: +"Longitud total de frentes de forjado en fachada en metros (m)."
```
- addedInput schema / properties / perimetro_forjado_m / minimum
```
Added value: +0
```
- addedInput schema / properties / perimetro_huecos_m / default
```
Added value: +0
```
- addedInput schema / properties / perimetro_huecos_m / description
```
Added value: +"Perímetro total de contornos de huecos y ventanas en metros (m)."
```
- addedInput schema / properties / perimetro_huecos_m / minimum
```
Added value: +0
```
- changedInput schema / required
```
Previous value: -[
-  "ano_construccion",
-  "perimetro_forjado_m",
-  "perimetro_huecos_m"
-]New value: +[
+  "ano_construccion"
+]
```
First observedv1.5.1Oct 17, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description repeats this ('solo lectura, sin efectos secundarios'). The normative citation adds context about the calculation basis, which is somewhat useful. However, there is no disclosure of assumptions like default zero for optional lengths, or that year drives the reference value selection—these behavioral nuances are left implicit.

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

Conciseness4/5

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

Front-loaded with the core purpose and normative reference, then clearly sectioned into 'Cuándo usar' and 'Comportamiento.' Every sentence serves a function. Slightly redundant to restate read-only given annotations, but not verbose.

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?

An output schema exists, so no need to describe return values. The description covers purpose, usage, and read-only nature, sufficient to invoke correctly. Minor gap: doesn't warn that optional bridge lengths default to 0, which an agent might miss.

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%, so all four parameters are already documented with descriptions and units. The description adds no parameter-level information beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (calcula) and resource (transmitancias térmicas lineales psi and pérdida térmica global por puentes térmicos), cites the exact normative reference (DA DB-HE/3 CTE). An agent can distinguish this from siblings like calcular_transmitancia_ventana_iso10077 which handles windows, not linear thermal bridges.

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?

Explicit 'Cuándo usar' section tells the agent to invoke this instead of estimated global values, and names the concrete elements it applies to (frentes de forjado, contornos de hueco, pilares en fachada). The alternative (valores globales estimados) is named, satisfying when-instead-of guidance.

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

Deploy Server