Riesgos activos por zona en Colombia (IDIGER, USGS, reportes ciudadanos) y qué seguros responden.
Scored across 2 tools
The two tools have clearly distinct purposes: one retrieves active risk data for a location, the other explains insurance coverage by risk type. There is no overlap in their functionality.
Both tool names follow a consistent snake_case verb_noun pattern in Spanish (consultar_riesgo, explicar_cobertura). The convention is predictable and readable.
With only two tools, the set feels thin for the stated domain, even though each tool is well-scoped. The narrow focus may justify the count, but it sits at the borderline of the typical 3-15 range.
The tools cover the core functions: querying current risks and explaining insurance coverage for common risk types. Minor gaps exist, such as no tool for historical risk data or listing all supported locations, but these are likely out of scope for the intended utility.
Devuelve los riesgos activos alrededor de un lugar de Colombia: eventos en vivo de fuentes oficiales (lluvia fuerte, crecientes y vendavales de la red IDIGER, solo Bogotá), sismos recientes del USGS (todo el país) y reportes ciudadanos verificados (inundaciones, granizo, huecos, vías bloqueadas, árboles o cables caídos, deslizamientos, incendios). Acepta un lugar en texto ("Suba, Bogotá", "calle 80 con Boyacá", "Chía") o coordenadas. No contiene datos personales. Úsala cuando alguien pregunte si hay riesgo, lluvia, inundación, sismo o problemas en una zona, o antes de orientar sobre un seguro para un lugar concreto.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitud (alternativa a lugar). | |
| lon | No | Longitud (alternativa a lugar). | |
| lugar | No | Barrio, dirección o ciudad en Colombia. Incluye la ciudad si no es Bogotá. | |
| radio_km | No | Radio de búsqueda en km (0,5 a 15; por defecto 3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, and the description usefully adds that no personal data is included plus the per-source coverage limits (IDIGER Bogotá-only vs USGS nationwide). It does not address latency, rate limits, or how staleness of live events is handled, so it goes beyond annotations but not exhaustively.
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?
It is a single dense paragraph that leads with what is returned and closes with when to use it, so nothing is buried. The source enumeration is long but each clause carries distinct information, so it stays short of 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?
With no output schema, the description carries the burden of explaining returns and does so at the source/category level (rain, floods, quakes, citizen reports). It stops short of describing response shape or ordering, which an agent would still have to discover by calling 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real value: example place strings ('Suba, Bogotá', 'calle 80 con Boyacá', 'Chía') and the mutual exclusivity of text place vs coordinates that the schema only hints at with '(alternativa a lugar)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource ('devuelve los riesgos activos alrededor de un lugar') and enumerates exactly what is returned: live IDIGER events for Bogotá, USGS earthquakes nationwide, and verified citizen reports. It also pins the geographic scope of each source, which implicitly distinguishes it from the coverage-explanation sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete trigger scenarios ('cuando alguien pregunte si hay riesgo, lluvia, inundación, sismo o problemas en una zona, o antes de orientar sobre un seguro'). It does not, however, name an alternative tool or state a when-not condition, so the sibling relationship remains unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guía informativa para Colombia por tipo de riesgo: pasos inmediatos de seguridad, qué seguros suelen cubrir ese evento (todo riesgo de vehículo, hogar, construcción, accidentes personales, vida, responsabilidad civil, SOAT) y qué no suelen cubrir. No da precios. Tipos: lluvia, inundacion, sismo, vendaval, granizo, vial, deslizamiento, incendio, hueco, caida_objetos, hurto.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | Yes | Tipo de riesgo (acepta sinónimos: terremoto, derrumbe, aguacero, bache, choque, robo…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read. The description adds real behavioral context beyond that: the output is advisement-only, is scoped to Colombia, and explicitly does not produce prices. It stops short of stating that coverage statements are indicative and not binding, which matters for an insurance-coverage claim.
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?
One dense, front-loaded paragraph: purpose, then exclusions ('No da precios'), then the accepted types. Every clause carries information and nothing is padded. The parenthetical list of insurance lines is long but is the substance of the tool, so it 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 single-parameter, read-only, no-output-schema tool, the description covers what the agent needs: domain, content of the answer, and the no-pricing boundary. Minor gaps remain — no guidance on what happens with an unrecognized tipo, and no distinction from consultar_riesgo.
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% and the schema already documents synonyms, so the baseline is 3. The description goes further by enumerating the accepted risk domain (lluvia, inundacion, sismo, vendaval, granizo, vial, deslizamiento, incendio, hueco, caida_objetos, hurto), which the schema lacks since it defines no enums — genuine added value for callers picking a value.
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 ('Guía informativa ... por tipo de riesgo') and enumerates exactly what the guide returns: immediate safety steps plus which insurance lines cover and don't cover the event. That scope is far more precise than a tautology. However, it never references the sibling 'consultar_riesgo', so the agent must infer the boundary between the two from scope alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: 'Guía informativa' plus 'No da precios' signals an orientation/education call, not a pricing quote. There is no explicit when-to-use, when-not-to-use, or routing to consultar_riesgo for the alternative kind of lookup. Adequate but leaves the choice between siblings to inference.
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.
consultar_riesgoexplicar_coberturaPerfila créditos de vivienda en Colombia y dirige cada caso a radicar, vincularse o referir con LQN.
Climate and disaster risk for any place or property: flood risk, heat waves, storms and hurricanes, wildfires, earthquakes, sea level rise and 7-day weather risk. Is it safe to go there? Ask about any city, address or coordinates and get this week's weather risk (heat, cold, wind, heavy rain, snow), wildfires, earthquakes, floods and cyclones happening nearby right now, long-term exposure to 2050 and 2080 (flood depth, sea level rise, extreme heat, drought, water stress) and the country's disaster-risk profile and rank among 194 countries. Also compares and ranks countries by risk for ESG and insurance research, and in Claude and other MCP Apps hosts shows an interactive map of the place right in the chat. Every value cites its source: INFORM, ND-GAIN, World Bank, CMIP6, ERA5, IPCC AR6, WRI Aqueduct, GDACS, NASA FIRMS, OpenAQ, ECCC GDPS. Remote, free, no API key, read-only.
Disaster risk for any Japanese address from official government data. 6 hazards, sources cited.
Puerto Rico & Colombia real estate: listings, sales, parcels, permits, analytics, AVM reports.
Add one secure layer between your agents and this server.
