Skip to main content
Glama

Pregúntale al récord público de PR

dato_citable

Busca en el récord público verificado de Puerto Rico (PuertoRicoSinFiltros): datos con fuente primaria, contradicciones declarado-vs-entregado, y citas de vistas públicas ancladas al minuto de video. Cada dato viene con su fuente y el link al récord completo. Ideal para verificar afirmaciones sobre agua, luz, FEMA, salud, presupuesto y promesas públicas de PR.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limiteNoMáximo de datos (1-10, default 5)
preguntaYesLa pregunta o afirmación a verificar (ej: "¿cuánto del dinero FEMA ha llegado?")

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description bears the full transparency burden. It discloses that results include source and link to the full record, and implies a read-only search behavior. It doesn't over-promise, but omits details like pagination or auth; for a simple search tool this is adequate.

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?

Two sentences with the core action first, followed by data characteristics and practical use case. No filler or redundant restatement.

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?

The tool has no output schema, so it's important that the description communicates expected results—it does ('Cada dato viene con su fuente y el link al récord completo'). It covers topics and use case, though it could mention result format nuances or limitations. Still, for a 2-param search tool, this is sufficient.

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 description coverage is 100% for both parameters (pregunta and limite), so the baseline is 3. The description doesn't add parameter details, but it does enrich the understanding of what 'pregunta' should be via the example in the schema; no extra meaning needed.

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 uses a specific action ('Busca en el récord público verificado de Puerto Rico') and enumerates distinct content types (fuente primaria, contradicciones declarado-vs-entregado, citas ancladas al minuto), which clearly differentiates it from sibling tools like buscar_negocio or desiertos_salud.

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?

It explicitly states 'Ideal para verificar afirmaciones sobre agua, luz, FEMA, salud, presupuesto y promesas públicas de PR', giving clear use context. It doesn't formalize exclusions or alternative tool references, but the domain is well-scoped.

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