puerto-rico

Qué dice el directorio del plan médico (histórico)

directorio_plan_medico

ÚNICO EN EL MUNDO: consulta los directorios de proveedores PUBLICADOS por los planes médicos de Puerto Rico, en varias ediciones en el tiempo, pareados al registro federal NPPES. Contesta lo que ninguna otra fuente puede: si un médico sigue en la red del plan, en qué pueblo lo lista el plan, qué teléfono publica el plan, y si dejó de aparecer entre una edición y la siguiente. Cobertura: MMM Individuales (dic-2024, dic-2025, jun-2026) y Plan Vital / First Medical. Útil para: verificar si un médico acepta tu plan, detectar teléfonos publicados que no corresponden, y medir exactitud de directorio (42 CFR 422.111 y 438.68).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`medico`	Yes	Nombre del médico, o su NPI de 10 dígitos (ej: "Ramirez" o "1234567890")

TDQS

A4.1/5.0

Behavior4/5

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

There are no annotations, so the description carries the full transparency burden. It usefully explains the source, edition dates, matching to NPPES, and comparison behavior between editions. It does not fully describe the output format or no-match behavior, but it exposes the important semantic behavior more than most descriptions do.

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?

Despite being long, the description is organized with clear labels like Cobertura and Útil para, and each sentence contributes useful information. Slight deduction for the hyperbolic 'ÚNICO EN EL MUNDO' opening and the regulatory citations, which are not genuinely necessary for invocation.

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?

With one parameter and no output schema, it is still impressively complete: it states scope, coverage, offline limitation, and what the tool can answer. It does not describe the exact return shape or no-match behavior, but an uneven gap for a lookup tool of this kind.

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% and the schema already documents that the parameter accepts a physician name or 10-digit NPI. The tool description adds no additional parameter-level guidance, so the baseline score of 3 is appropriate.

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 clearly states a specific action and resource: consulting published provider directories of Puerto Rico health plans across time, matched to the federal NPPES registry. It also enumerates distinctive capabilities—network retention, town listing, published phone, and edition-to-edition disappearance—which distinguishes it from the other tools in the sibling set.

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 provides explicit use cases ('verificar si un médico acepta tu plan, detectar teléfonos publicados que no corresponden, y medir exactitud de directorio') and coverage details. It does not name alternative tools or state when-not-to-use it, so it stops just short of full usage guidance.

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

All puerto-rico tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?