Puerto Rico's hand-verified data layer: businesses, health deserts, FDA recalls, public record.
Scored across 12 tools
Most tools map to clearly distinct data sources and purposes, such as provider search, business directory, FDA recalls, transcripts, and demand data. The only mild overlap is between buscar_medico and directorio_plan_medico, both involving health provider information, but their descriptions specify different registries and use cases.
Names are consistently lowercase with underscores, but they mix conventions: buscar_medico and chequear_recall follow verb_noun, while dato_citable, desiertos_salud, and verificacion_estado are descriptive noun phrases. A few names like lo_que_no_se and que_dijeron are sentence-like and less conventional, making the pattern inconsistent though still readable.
12 tools is a well-scoped count for a broad Puerto Rico information and verification service. Each tool earns its place by covering a distinct source or analytical need without padding.
The tool surface is comprehensive for its apparent purpose: it covers finding providers, businesses, and events; checking recalls and insurance directories; searching verified public records and transcripts; measuring demand and unmet needs; citing data; and publishing its own verification freshness. There are no obvious dead ends for common queries in the domain.
Busca médicos, dentistas, farmacias, laboratorios y otros proveedores de salud de TODA la isla de Puerto Rico en registromedicopr.com (30,000+ fichas sobre el registro federal NPPES, con NPI). Devuelve especialidad, pueblo, teléfono, NPI, el enlace permanente a su ficha, y cuando la oficina lo confirmó: si acepta pacientes nuevos, qué planes médicos acepta y quién lo confirmó. Cada ficha trae nivel_verificacion: "persona" (la oficina o Angel lo confirmó), "fuente" o "registro" (solo copiado del registro federal). Úsalo para "¿hay un cardiólogo en Mayagüez que acepte MMM?", "¿esta farmacia sigue abierta?", "¿el Dr. X sigue ejerciendo en Cabo Rojo?".
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Máximo de resultados (1-25, default 8) | |
| nombre | No | Nombre del proveedor, o su NPI de 10 dígitos | |
| municipio | No | Municipio de PR (ej: "Cabo Rojo", "Mayagüez"). Vacío = toda la isla. | |
| especialidad | No | Especialidad o tipo (ej: "cardiólogo", "farmacia", "pediatra", "laboratorio"). Se busca en español. | |
| solo_confirmados | No | true = solo fichas que una persona confirmó (acepta pacientes / planes). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent, and the description adds valuable behavioral context: it explains conditional fields ('cuando la oficina lo confirmó') and the meaning of nivel_verificacion with its three possible values. This lets the agent correctly interpret data trustworthiness and know what the result contains.
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?
The description is efficiently structured: action and scope first, then return fields and verification semantics, then concrete use cases. It is longer than a minimal description but every sentence earns its place with relevant detail.
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?
Even without an output schema, the description clearly states what the tool returns, including specialty, town, phone, NPI, permanent link, acceptance status, accepted plans, and verifier. The use-case examples and schema coverage together provide enough context for an agent to select and invoke the tool correctly.
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?
The input schema already describes all five parameters with types and examples, so the description adds little new parameter-level meaning. The examples in the description reinforce especialidad, municipio, and plan-related usage, but do not go beyond the schema coverage.
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 uses the specific verb 'Busca' and names the exact resource: health providers across Puerto Rico in registromedicopr.com. It clearly identifies the domain and data source, though it does not explicitly name sibling tools to differentiate them.
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?
The 'Úsalo para' section gives three concrete example queries that clarify when to invoke this tool, such as finding a cardiologist accepting a specific plan or checking if a professional is still practicing. It does not mention exclusions or explicitly point to alternatives, but the use cases are sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca negocios y servicios locales de Puerto Rico (foco: Cabo Rojo y el oeste) en el directorio verificado a mano de mapadecaborojo.com. Devuelve nombre, teléfono, dirección y la FECHA en que un humano lo verificó por última vez — lo que Google Places no te puede dar de un pueblo de PR.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Máximo de resultados (1-20, default 5) | |
| consulta | Yes | Qué buscas: nombre del negocio o tipo de servicio (ej: "plomero", "farmacia", "Tino's") | |
| municipio | No | Filtrar por municipio (ej: "Cabo Rojo") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful context beyond those: it reveals that results include a human-verification date and that the directory is hand-verified, which signals data-quality expectations without contradicting the annotations.
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?
The description is two effective sentences: it front-loads the core purpose and scope, then lists return fields and the distinguishing value proposition. Nothing is redundant, and the Google Places contrast earns its place by clarifying when the tool is useful.
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 simple read-only search tool, it is reasonably complete: it names the source directory, geographic focus, return fields, and the unique verification-date feature. It could be more complete by explicitly routing users to buscar_medico for medical-provider queries, but the schema and annotations cover most invocation needs.
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 input schema already documents 'consulta', 'limite', and 'municipio'. The description does not add operational semantics beyond what the schema provides, so it stays at the baseline.
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 starts with the specific verb 'Busca' and names the resource: local businesses and services of Puerto Rico in the hand-verified directory of mapadecaborojo.com. It also states what is returned, making the tool's scope immediately understandable and distinguishable from siblings like buscar_medico.
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?
The description gives clear context: use this for local PR business/service searches, especially in Cabo Rojo and the west, when verified human-checked data matters. It does not explicitly name alternatives or say when not to use it, but the use case is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica si un medicamento o producto tiene un recall activo de la FDA, con razón en español cuando existe. Data federal actualizada a diario. Cobertura: Estados Unidos y Puerto Rico.
| Name | Required | Description | Default |
|---|---|---|---|
| medicamento | Yes | Nombre del medicamento o producto (ej: "metformin") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: results include the recall reason in Spanish when available, the federal data updates daily, and the coverage is limited to the US and Puerto Rico. It does not contradict the annotations.
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?
Three short sentences, each adding a distinct piece of information: the core check, output language behavior, data freshness, and geographic scope. Nothing is redundant or filler, and the main purpose is front-loaded.
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 simple one-parameter read-only tool, the description provides the essential operational context: what is checked, where it applies, and how current the data is. It does not spell out the exact return shape, but no output schema exists and 'verifica' implies a status check, while the Spanish-reason clause gives partial output semantics. A bit more detail on the result format would make it fully complete.
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?
The input schema fully documents the only parameter 'medicamento' with an example, so the 100% schema description coverage sets a baseline of 3. The description repeats 'medicamento o producto' but adds no new parameter-level meaning beyond what the schema already provides.
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 uses a specific verb ('Verifica') and a clear resource ('si un medicamento o producto tiene un recall activo de la FDA'), which immediately sets it apart from siblings like buscar_medico or eventos_proximos. It also adds scope details (daily federal data, US/Puerto Rico coverage) that make the tool's purpose unmistakable.
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?
The description establishes clear context: use this tool to check active FDA recalls for drugs/products. It does not explicitly name alternatives or exclusion criteria, but the sibling list is composed of unrelated domains, so the situations in which this tool applies are obvious from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve la cita lista para pegar de un negocio o ficha: enlace permanente, fecha de verificación y quién la verificó. Declara explícitamente si el dato lo confirmó una PERSONA o si solo se importó de un registro federal — importado NO es verificado. Usa esto cuando vayas a citar cualquier dato de esta fuente en una respuesta.
| Name | Required | Description | Default |
|---|---|---|---|
| negocio | Yes | Nombre o slug del negocio o ficha |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the citation explicitly distinguishes person-confirmed data from federal-registry imports, and clarifies that imported data is not verified. This adds meaningful behavioral context beyond the annotations, which only indicate the operation is read-only and idempotent.
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?
The description is two sentences: the first states the core function and output, the second adds a critical verification caveat and a usage directive. All content is relevant with no wasted words.
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 one-parameter read-only tool with no output schema, the description is complete: it explains what is returned (permanent link, verification date, verifier), the verification distinction, and when to use it. No additional information is needed for correct invocation.
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?
The schema already documents the single 'negocio' parameter with 100% coverage, describing it as a name or slug. The description only reiterates this by mentioning 'negocio o ficha,' adding no new semantic detail beyond the schema.
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 states a specific action ('Devuelve la cita lista para pegar') for a specific resource (business or record), and names the output components (permanent link, verification date, verifier). This clearly distinguishes it from sibling data-lookup tools like buscar_negocio by focusing on producing a citable output.
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?
The description includes an explicit use condition: 'Usa esto cuando vayas a citar cualquier dato de esta fuente en una respuesta.' It tells the agent when to invoke the tool, though it does not mention alternative tools or exclusion cases, leaving some ambiguity with the sibling 'dato_citable'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Máximo de datos (1-10, default 5) | |
| pregunta | Yes | La pregunta o afirmación a verificar (ej: "¿cuánto del dinero FEMA ha llegado?") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds meaningful behavioral context: every result comes with its source and a link to the full record, and results may include contradictions and video-timestamped quotes. This goes beyond the structured annotations without contradicting them.
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?
The description is two sentences with no filler. The first sentence front-loads the core resource and behavior, and the second adds output guarantees and concrete use-case domains. Every clause earns its place and the structure supports quick agent scanning.
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 only two parameters, rich annotations, and no output schema, the description does enough by explaining what results look like: data with source and link to the full record. It could be slightly more explicit about expected output structure or no-results behavior, but the overall tool context is adequately complete for an agent to call it correctly.
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 semantic guidance for the 'pregunta' parameter by listing the kinds of claims it is ideal for verifying (water, electricity, FEMA, health, budget, promises). This helps an agent formulate more useful queries than the schema alone would.
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 uses a specific verb ('Busca') and a clear resource ('el récord público verificado de Puerto Rico / PuertoRicoSinFiltros'), and lists concrete data types: primary-source data, declared-vs-delivered contradictions, and video-anchored public-hearing quotes. This clearly distinguishes it from the sibling tools, which target narrower domains like doctors, businesses, recalls, or plan directories.
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?
The description gives clear context for when to use the tool: verifying claims about water, power, FEMA, health, budget, and public promises in Puerto Rico. It does not explicitly state when not to use it or name alternative sibling tools, so it stops short of a full when/when-not guide, but the intended use case is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Qué servicios buscó la gente real de Cabo Rojo y el oeste de PR por el canal *7711, agregado por categoría (conteos solamente, nunca mensajes crudos). Útil para entender qué hace falta en el mercado local.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Ventana en días (1-90, default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool is read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it only returns category counts and never raw messages, which sets clear privacy and output expectations.
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?
Two concise, front-loaded sentences communicate purpose, scope, aggregation, privacy safeguards, and intended use with no filler. Every clause adds value.
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 simple read-only tool with one documented parameter and strong annotations, the description is nearly complete. It explains the output shape (category counts) despite there being no output schema, though it could briefly mention the time-window parameter as the primary input.
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?
The single parameter 'dias' is fully documented in the schema with type, range, and default. The description doesn't add parameter-specific detail, but with 100% schema coverage, the parameter semantics are already adequately handled.
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 states a specific resource: aggregated counts of service searches from real people in Cabo Rojo and western PR via channel *7711. The verb 'buscó' plus the aggregation and geographic scope make the tool's function clear, though it doesn't explicitly contrast with sibling tools.
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?
The phrase 'Útil para entender qué hace falta en el mercado local' gives an implied use case, but there is no explicit guidance on when to use this over siblings like buscar_medico or desiertos_salud, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Municipios de Puerto Rico con cero o casi cero proveedores de una especialidad médica, ordenados por riesgo real (déficit vs el área metro + pobreza + aislamiento geográfico + HPSA federal), no alfabéticamente. Basado en el registro federal NPPES cruzado con Census. Único dataset de este tipo para PR.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Máximo de municipios (1-76, default 10) | |
| especialidad | Yes | Especialidad (ej: "psiquiatra", "cardiologo", "pediatra") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds meaningful behavioral context: the data comes from NPPES crossed with Census, the ordering is based on a stated risk formula, and the output is deliberately not alphabetical. The exact 'casi cero' threshold is undefined, but this is a minor gap.
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?
Three sentences with no wasted words. The core output and ordering rule are front-loaded, followed by data provenance and a uniqueness claim. Every sentence contributes to the agent's understanding.
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 read-only, two-parameter list tool, the description gives the output domain, the ordering logic, the data source, and the uniqueness of the dataset. Even without an output schema, an agent can infer the response is an ordered list of municipios. The main missing detail is the precise threshold for 'casi cero', but that does not prevent correct invocation.
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 description coverage is 100%, so both 'especialidad' and 'limite' are already documented with clear semantics. The description reinforces that 'especialidad' is the core filter and that the result is a ranked set of municipios, but it adds no parameter-level detail beyond what the schema provides.
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 states the exact resource ('Municipios de Puerto Rico con cero o casi cero proveedores de una especialidad médica') and immediately adds a distinctive behavioral detail: ordering by 'riesgo real' rather than alphabetically. It also claims to be the only dataset of this kind for Puerto Rico, which differentiates it from sibling tools.
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 context is implied: an agent can infer this is for analyzing medical supply gaps by specialty in Puerto Rico. However, the description does not explicitly compare it to siblings like buscar_medico or directorio_plan_medico, and it gives no conditions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ú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).
| Name | Required | Description | Default |
|---|---|---|---|
| medico | Yes | Nombre del médico, o su NPI de 10 dígitos (ej: "Ramirez" o "1234567890") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Las anotaciones ya cubren readOnly, idempotent y no destructivo. La descripción añade contexto valioso: fuente publicada, ediciones temporales, pareo con NPPES, cobertura limitada y referencias regulatorias. No contradice las anotaciones.
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?
La información está bien organizada y es mayormente esencial, pero el inicio 'ÚNICO EN EL MUNDO' es publicidad y no aporta valor funcional. El resto es eficiente y accionable.
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?
Para un solo parámetro con anotaciones de seguridad, la descripción es suficiente: explica qué responde, con qué cobertura y para qué sirve. No hay output schema, pero el texto adelanta los tipos de respuestas que puede generar.
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?
El esquema ya documenta el único parámetro con ejemplos (nombre o NPI), por lo que la cobertura es 100%. La descripción no aporta semántica adicional más allá del esquema.
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?
La descripción usa un verbo específico y un recurso claro: 'consulta los directorios de proveedores PUBLICADOS por los planes médicos de Puerto Rico'. También delimita el alcance histórico y lo diferencia de búsquedas médicas genéricas como buscar_medico al centrarse en directorios de planes.
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?
Ofrece contexto de uso explícito con la sección 'Útil para' y la cobertura de planes y ediciones. No menciona exclusiones ni alternativas por nombre, pero la orientación es clara.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Eventos publicados y aptos para familia en Cabo Rojo y el oeste de Puerto Rico en los próximos días, con lugar, hora y precio cuando existe.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Ventana en días hacia adelante (1-60, default 14) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the read-only, idempotent, non-destructive safety profile, so the description does not need to repeat it. The description adds useful behavioral context by noting that events are vetted ('publicados y aptos para familia') and that fields such as price are only included when available ('precio cuando existe').
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?
The description is a single compact sentence that conveys the resource type, scope, time window, and expected output fields without filler or redundant restatement of the schema. Every element 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?
With one optional parameter fully documented in the schema, no output schema, and annotations covering side effects, the description supplies the remaining operational context: what events are returned, where, and what details they include. Nothing essential is missing for correct invocation.
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?
The only parameter, 'dias', is fully documented in the schema with its range and default (1-60, default 14), so the description needs no additional parameter explanation. The description adds no parameter-specific meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource precisely: published, family-friendly events in Cabo Rojo and western Puerto Rico in the coming days, with place, time, and price details. It clearly distinguishes itself from the sibling tools, which cover medical, legal, and business information, though it lacks an explicit verb such as 'list' or 'search'.
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?
The geographic scope and near-term time window provide clear context for when this tool is appropriate, and no sibling tool covers events, so alternatives are not needed. It does not explicitly say 'use this when...', but the usage is strongly implied by the scoped description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve lo que gente real de Puerto Rico le pidió a esta fuente y la fuente NO pudo contestar, agregado por categoría y pueblo. Sirve para 2 cosas: saber cuándo NO confiar en esta fuente, y ver demanda local medida que hoy nadie está sirviendo. Se ordena por personas distintas, no por número de preguntas, porque 40 preguntas de una sola persona no son demanda. Solo agregados: el texto de lo que escribió cada persona nunca se expone.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Ventana hacia atrás (7-365, default 90) | |
| limite | No | Máximo de huecos (1-60, default 20) | |
| municipio | No | Filtrar por pueblo (ej: "Cabo Rojo"). Vacío = toda la isla. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses key behavioral traits: results are ordered by distinct people rather than total questions, the rationale behind that ordering, and that only aggregates are returned while raw user text is never exposed. This adds meaningful privacy and methodology context the annotations do not convey.
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?
The description is efficiently structured: purpose first, then use cases, then key behavioral rules. Every sentence earns its place, including the concise justification for ordering by distinct people rather than question count.
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?
Given there is no output schema, the description provides enough return-related context: results are aggregated by category and town, sorted by distinct people, and raw text is withheld. It could be slightly more complete by clarifying whether 'esta fuente' refers to a specific named source or what the exact output shape looks like, but the essential information is present.
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?
All three parameters are fully described in the schema, so the description does not need to compensate for schema gaps. The description adds general context about aggregation by category and town, which supports the municipio parameter, but it does not add syntax or format details beyond the schema.
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 states a specific verb and resource: it returns what real people in Puerto Rico asked this source and the source could not answer, aggregated by category and town. This clearly identifies the tool's function, though it does not explicitly differentiate it from sibling tools like demanda_local 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives two explicit use cases: knowing when NOT to trust the source, and seeing unserved local demand. This is clear contextual guidance, but it does not explicitly contrast with sibling tools such as demanda_local or state when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca en los transcripts completos de vistas públicas, entrevistas y programas de análisis de Puerto Rico (Senado, Cámara, alcalde de Cabo Rojo, Jay Fonseca, Telemundo, Jugando Pelota Dura) guardados por CaboRojo.com. Devuelve el fragmento textual, quién lo dijo, la fecha y el enlace al minuto exacto del video. OJO: es lo que ALGUIEN DIJO, no un dato verificado (nivel_verificacion = fuente). Sirve para citar textual con derecho a réplica, no para afirmar hechos. Úsalo para "¿qué dijo la AAA sobre el agua de Esencia?", "¿qué prometió el alcalde sobre el balneario?", "¿qué dijo Jay Fonseca de las baterías de Tesla?".
| Name | Required | Description | Default |
|---|---|---|---|
| desde | No | Fecha mínima YYYY-MM-DD (opcional) | |
| frente | No | Tema para filtrar: "La luz", "El agua", "Esencia", "La cita" (opcional) | |
| limite | No | Máximo de fragmentos (1-12, default 6) | |
| pregunta | Yes | Qué quieres saber que se dijo (ej: "baterías Tesla sin instalar") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description adds key behavioral context: results are unverified quotes at 'nivel_verificacion = fuente' and the tool is meant for citation with right to reply, not fact assertion. It also states the exact return fields (fragment, speaker, date, minute link), which is valuable given no output schema.
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?
Three sentences, appropriately sized and front-loaded: action and resource first, then return format, then caveat and usage examples. Every sentence adds distinct value; the example queries are compact and concrete.
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?
Despite having no output schema, the description states the return format and source scope, and gives concrete usage examples. For a read-only search tool with rich annotations and full parameter coverage, nothing essential is missing.
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 description coverage is 100%, so the schema already documents all four parameters. The description's example queries reinforce how to phrase 'pregunta' but do not add detail for 'desde', 'frente', or 'limite' beyond the schema.
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 opens with a clear verb 'Busca' and a specific resource: complete transcripts of Puerto Rican public hearings, interviews, and analysis programs from named sources. It distinguishes itself from fact/verification tools by explicitly stating it returns what someone said, not a verified fact.
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 explicit example queries and states the intended use: 'Sirve para citar textual con derecho a réplica, no para afirmar hechos.' The when-not-to-use is clear, but no sibling tool (e.g., verificacion_estado) is named as the alternative for verified facts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ambito | No | Filtrar por municipio o categoría (ej: "Cabo Rojo", "HEALTH"). Vacío = todos. | |
| limite | No | Máximo de ámbitos (1-60, default 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral context beyond that: the source publishes its own margin of error, and 'Un dato importado de un registro federal NO cuenta como verificado por una persona' clarifies the meaning of the freshness metric.
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?
Three short sentences, each earning its place: the first states the return value, the second gives usage guidance, and the third clarifies an important semantic edge case. Information is front-loaded and there is no filler.
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 read-only tool with two optional parameters and no required inputs, the description covers what is returned, how it is grouped, and an important caveat about federal imports. An output schema is absent, but the description gives enough for an agent to understand the response shape at a high level.
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 description coverage is 100%, so the baseline is 3. The description adds only a small amount of semantic context by mentioning 'por municipio o categoría', which maps to the ambito parameter, but does not elaborate on limitation or formatting beyond the schema.
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 states a specific verb and resource: 'Devuelve el porciento de fichas verificadas a mano en los últimos 90 y 365 días, por municipio o categoría.' This clearly differentiates it from sibling tools like buscar_medico or chequear_recall by focusing on data freshness and manual verification percentages.
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?
The description gives contextual guidance: 'si vas a citar un dato de un ámbito con pct_frescas_90d bajo, dilo' implies the tool should be used when assessing whether a datum is fresh enough to cite. It lacks explicit alternatives or when-not-to-use conditions, but the intended context is clear.
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.
que_dijeronbuscar_medicocitardirectorio_plan_medicolo_que_no_severificacion_estadobuscar_negociochequear_recalldato_citabledemanda_localdesiertos_saludeventos_proximosPuerto Rico & Colombia real estate: listings, sales, parcels, permits, analytics, AVM reports.
US public-records intelligence for AI agents — companies, SEC, courts, spending, licenses.
OSM-sourced local business data across 9 niches — cuisine, dietary options, delivery, accessibility.
Normalized official data with provenance, aggregations, insights, free samples and agent access.
Add one secure layer between your agents and this server.
