Skip to main content
Glama

Qué tan fresco está este dato (barras de error de la fuente)

verificacion_estado

Devuelve el porciento de fichas verificadas a mano en los últimos 90 y 365 días, por municipio o categoría. Esta fuente publica su propio margen de error: si vas a citar un dato de un ámbito con pct_frescas_90d bajo, dilo. Un dato importado de un registro federal NO cuenta como verificado por una persona.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ambitoNoFiltrar por municipio o categoría (ej: "Cabo Rojo", "HEALTH"). Vacío = todos.
limiteNoMáximo de ámbitos (1-60, default 15)

TDQS

A4.3/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 that this is a read-style query ('Devuelve...'), that results are limited to manual verification rates, and importantly that imported federal-registry records are not counted as verified. This is meaningful behavioral detail, though output shape and any other constraints 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.

Conciseness5/5

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

The description is a tight three-sentence structure: first the result, then the important usage caveat, then the technical qualification about federal imports. Every sentence earns its place and there is no redundant fluff.

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 with only two optional parameters and no output schema, this is complete: it explains what the tool computes, what the fields mean, the key interpretation caveat, and how the query is scoped. An agent has enough to call it correctly and interpret the result.

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 the parameters already have clear meanings. The description adds little beyond repeating 'municipio o categoría', which is acceptable but not additional semantic value.

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 states a specific verb and resource: it returns the percentage of manually verified records over 90 and 365 days. The title 'Qué tan fresco está este dato' and the error-margin framing make its purpose as a freshness/source-quality tool unambiguous.

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 a clear intended scenario: check this before citing data from an ámbito, and explicitly flag low pct_frescas_90d values. It does not name alternative sibling tools or explicit when-not-to-use conditions, but the usage context is concrete enough.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct resource or workflow: local businesses, recalls, provider directories, public records, events, demand, verification stats, and citations. The only mild concern is that citar, dato_citable, and buscar_negocio could be briefly confused by name alone, but their descriptions clearly separate them.

Naming Consistency3/5

All names are lowercase snake_case and mostly Spanish, so they feel cohesive. However, conventions vary: buscar_negocio and chequear_recall are verb-noun, directorio_plan_medico and eventos_proximos are noun-noun or noun-adjective, while lo_que_no_se is a complete phrase. This is readable but not a uniform verb_noun pattern.

Tool Count5/5

Ten tools is well within the ideal range, and each one addresses a distinct part of the server's mission: business search, verification, citations, health provider coverage, recalls, events, and demand/unknown signals. Nothing feels redundant or unnecessary.

Completeness4/5

The tool surface covers the key workflows well: search, cite, verify, check health access, find events, check leads, and surface unmet demand. Minor gaps exist — for example, business details are limited to the west PR focus and certain plans only — but those are clearly scoped limitations rather than missing core functions.

Resources