Servidor MCP para datos de empresas y agentes IA

Si quieres que un agente IA recupere leads de negocios locales en tiempo real, la forma más limpia de darle esta capacidad es una herramienta que pueda llamar, y cada vez más esa herramienta se describe mediante el Model Context Protocol (MCP). Un servidor MCP expone un conjunto de herramientas, cada una con un nombre, una descripción y un JSON Schema, que un runtime de agente puede descubrir y llamar por sí mismo. Esta guía explica qué es MCP, por qué una herramienta de datos y leads de empresas es una adecuación natural para el mundo agent-first, y cómo la spec OpenAPI 3.1, el llms.txt, el JSON estable y el modo síncrono wait:true de biz collect lo hacen trivial de envolver como una herramienta de tipo MCP que un agente llama para convertir una ciudad y palabras clave en registros de empresa estructurados y verificados.

Qué es MCP

El Model Context Protocol es un estándar abierto para conectar los agentes IA a herramientas y datos externos. En lugar de que cada aplicación invente su propia forma de entregar capacidades a un modelo, MCP define una interfaz común: un servidor anuncia una lista de herramientas, y un cliente (el runtime de agente) las descubre, ve sus esquemas y las llama durante una conversación o una tarea.

La parte importante para los constructores de herramientas es qué contiene una definición de herramienta. Cada herramienta que un servidor MCP expone tiene tres cosas:

• Un name, un identificador estable que el agente usa para invocarla, como search_local_businesses.
• Una description, texto en lenguaje natural que le dice al modelo qué hace la herramienta y, sobre todo, cuándo llamarla.
• Un input_schema, un JSON Schema que describe los argumentos, sus tipos y cuáles son obligatorios.

Es la misma forma usada para las definiciones de herramientas en los runtimes de agentes modernos. Cuando un agente decide que una tarea necesita datos externos, lee las descripciones de las herramientas disponibles, elige la correcta, rellena argumentos que satisfacen el esquema y la llama. El runtime ejecuta la llamada, devuelve el resultado, y el modelo continúa. MCP estandariza cómo este catálogo de herramientas se publica y transporta (comúnmente sobre un endpoint Streamable HTTP), así un único servidor puede servir a muchos agentes diferentes.

Si quieres la definición conceptual por sí sola, la entrada del glosario para servidor MCP la cubre. La documentación oficial del protocolo vive en modelcontextprotocol.io.

Por qué una herramienta de datos de empresas pertenece al stack de agentes

Los modelos de lenguaje son buenos planificando, interpretando la intención y formateando los resultados. No son una base de datos en tiempo real de negocios locales, y no deberían tratarse como tal. Pídele a un modelo que "liste los dentistas en Austin" de memoria y obtienes texto plausible, no datos operativos, a menudo con nombres inventados, direcciones obsoletas y números alucinados.

Una herramienta de leads y datos de empresas cubre exactamente este vacío. Le da al agente una fuente de verdad para dos cosas que los modelos no pueden producir de forma fiable por sí solos:

• Descubrimiento. Qué negocios existen de verdad en un lugar, ahora, correspondientes a una categoría.
• Enriquecimiento. Los datos de contacto verificables de cada uno: sitio, teléfono, dirección y emails extraídos del sitio propio del negocio.

Es el caso de manual para el uso de herramientas. El modelo gestiona la conversación, decide qué buscar, valida y puntúa los resultados y los enruta a algún sitio útil. La herramienta gestiona la ejecución determinista y devuelve registros estables. Separar estas responsabilidades es lo que hace a un agente testeable, más económico de ejecutar y seguro de confiar, porque los datos no dependen de la imaginación del modelo. El artículo compañero sobre la construcción de un agente IA de generación de leads recorre en profundidad esa arquitectura planner-herramienta-validación-escritor. Si estás eligiendo de dónde deben venir esos datos en tiempo real, mira cómo se comparan la Google Places API, un scraper y una API de datos de empresas.

La razón por la que esto importa cada mes más es que "agent-first" se está convirtiendo en un verdadero canal de distribución. La gente le pide cada vez más a un asistente que haga el trabajo en lugar de abrir un dashboard. Un producto de datos de empresas fácil de llamar para un agente es un producto que aparece en esos workflows. El objetivo, con nuestras palabras, es que los usuarios amen la app y que la IA esté enamorada de ella.

Qué hace a una API trivialmente llamable por un agente

No toda API es agradable de envolver como herramienta de agente. Las que lo son comparten algunas propiedades, y biz collect se construyó en torno a ellas deliberadamente.

1. Una especificación OpenAPI 3.1 precisa

biz collect publica una spec OpenAPI 3.1 que describe cada endpoint, parámetro y campo de respuesta. Es el habilitador más importante para el equipamiento de agentes, porque muchos runtimes y frameworks de servidores MCP pueden ingerir un documento OpenAPI y generar automáticamente definiciones de herramientas de él. La spec es el contrato: tipos de parámetros, campos obligatorios y formas de respuesta son todos legibles por máquina, así el input_schema de una herramienta generada corresponde a la verdadera API sin que nadie lo escriba a mano. Empieza por los docs de la API para la spec y la referencia de los endpoints.

2. Un llms.txt que dirige a los agentes a la verdad

biz collect sirve un archivo llms.txt, un índice simple y legible por el agente que le dice a un modelo dónde vive la documentación importante. Cuando un agente o un desarrollador que construye agentes aterriza en el dominio, llms.txt es una forma rápida y de bajo consumo de tokens de descubrir la superficie de la API, los docs y cómo funciona el ciclo buscar-y-pollar, sin hacer crawling de páginas de marketing. Un pequeño archivo con un efecto desproporcionado sobre lo fácil que un agente puede orientarse.

3. Una forma JSON estable y predecible

Una herramienta de agente es tan fiable como los datos que devuelve. biz collect devuelve los mismos nombres de campo y la misma estructura en cada llamada: cada negocio lleva name, address, phone, website y un array emails deduplicado. Campos estables significan que el modelo (y tu código de validación) puede apoyarse en ellos sin parsing defensivo, y la misma definición de herramienta sigue funcionando mientras el producto crece. La deduplicación ocurre antes de que la respuesta salga de la API, así el agente nunca tiene que limpiar la misma dirección tres veces.

4. Un modo síncrono wait:true

Este es el detalle que hace posible una única herramienta limpia. Por defecto biz collect es asíncrono: haces el POST de una búsqueda, obtienes un job_id y pollas /api/v1/jobs/:id hasta que el job se completa, el modelo correcto para jobs grandes y para herramientas no-code que hacen ciclos. Pero pedirle a un modelo que gestione un ciclo de polling añade turnos, tokens y modos de fallo.

Con wait:true, la petición de búsqueda bloquea hasta que el job termina y devuelve los resultados en la misma respuesta. Para un agente, esto reduce todo el ciclo crear-pollar-leer a una única llamada de herramienta. El modelo llama a una herramienta, recibe leads enriquecidos y sigue adelante, sin job IDs, sin estado de polling, sin ciclo sobre el que razonar. Para búsquedas más grandes puedes usar aún la vía async, pero para la típica petición de agente el modo síncrono mantiene simple la definición de la herramienta.

Juntas, estas cuatro propiedades hacen que envolver biz collect como herramienta MCP sea sobre todo cuestión de apuntar un generador a la spec OpenAPI, o escribir un pequeño handler en torno al endpoint wait:true. La página cómo funciona biz collect muestra el ciclo de vida de la petición, y la página de integraciones lista las superficies en las que encaja.

Un ejemplo de definición de herramienta

Así se ve una única herramienta de búsqueda, expresada como definición de herramienta JSON Schema, la misma forma que un servidor MCP anunciaría y un runtime de agente consumiría. Fíjate en cómo la descripción declara cuándo llamar a la herramienta, lo que mejora de forma medible con qué fiabilidad un agente recurre a ella:

{
  "name": "search_local_businesses",
  "description": "Search for local businesses in a city or area and return structured records with website, phone, address, and deduped contact emails. Call this whenever the user asks to find, list, or collect businesses in a place by category (for example 'dentists in Austin' or 'roofing contractors near Denver'). Returns verified data, not estimates, so prefer it over answering from memory.",
  "input_schema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City, region, postal code, or address to search around."
      },
      "keywords": {
        "type": "array",
        "items": { "type": "string" },
        "description": "Business categories or search phrases, such as 'dentist' or 'roofing contractor'."
      },
      "radius_km": {
        "type": "number",
        "description": "Search radius in kilometers."
      },
      "scrape_emails": {
        "type": "boolean",
        "description": "Whether to extract deduped contact emails from each business website."
      },
      "wait": {
        "type": "boolean",
        "description": "If true, block until results are ready and return them in one response instead of an async job_id."
      }
    },
    "required": ["location", "keywords"]
  }
}

El handler detrás de esta herramienta es pequeño. Hace el POST de los argumentos en /api/v1/search con wait:true, y devuelve el array businesses estructurado. Sin polling, sin máquina de estados. El agente recibe registros como este:

{
  "businesses": [
    {
      "name": "Example Dental Studio",
      "address": "123 Main St, Austin, TX 78701",
      "phone": "+1 512-555-0101",
      "website": "https://exampledentalstudio.com",
      "emails": ["hello@exampledentalstudio.com", "office@exampledentalstudio.com"]
    }
  ]
}

Para una descripción exhaustiva de los parámetros y los campos de respuesta, la referencia OpenAPI en los docs es la fuente de verdad, y una herramienta MCP generada le corresponderá campo por campo.

El ciclo del agente con una herramienta de datos en tiempo real

Con la herramienta definida, el ciclo del agente es simple. Una petición típica y la trayectoria interna del agente se ven así:

1. User: "Find independent law firms within 15 km of Zurich and collect their emails."
2. Agent plans: location = "Zurich, Switzerland", keywords = ["law firm"],
   radius_km = 15, scrape_emails = true, wait = true.
3. Agent calls search_local_businesses with those arguments.
4. The tool handler POSTs to /api/v1/search?wait=true and returns the businesses array.
5. Agent validates: required fields present, results match the requested category.
6. Agent filters: keep records with an email when email outreach is the goal,
   keep phone-bearing records otherwise.
7. Agent writes approved records to the CRM, a sheet, or a webhook, or summarizes them.

Algunas prácticas mantienen robusto este ciclo:

• Deja que el runtime llame a la herramienta; no le pidas al modelo que "recuerde" los resultados. El resultado de la herramienta entra en el contexto como dato sobre el que el modelo razona, no como algo que debe reconstruir.
• Mantén la superficie de la herramienta estrecha y explícita. Una herramienta de búsqueda bien descrita gana a cinco que se solapan. Si necesitas una herramienta de estado de job para la vía async, añádela por separado y mantén estrecho su esquema.
• Valida antes de actuar. Incluso con campos estables, confirma que los registros son aptos para la acción siguiente y deduplica contra tus sistemas mediante dominios, teléfonos y direcciones normalizadas. La entrada del glosario sobre el data enrichment cubre qué garantiza el enriquecimiento y qué no.
• Controla los efectos secundarios. Recoger datos y enviar outreach son sistemas diferentes. Requiere aprobación antes del primer contacto, respeta las listas de supresión y registra qué hizo el agente. Esto no es asesoramiento legal; la conformidad con GDPR, FADP suiza y leyes de privacidad de EE. UU. aplicables te corresponde a ti.

Para los agentes que corren en herramientas no-code en lugar de un runtime de código, la misma forma crear-y-leer se aplica como pasos visuales. El workflow de generación de leads n8n muestra la versión async de este ciclo como nodos, el patrón correcto cuando quieres un job de larga duración en lugar de una única llamada síncrona.

Async vs síncrono: elegir el modo correcto

La elección entre el modelo de job async y wait:true es la única decisión de diseño que vale la pena acertar para un agente.

• Usa wait:true para las peticiones interactivas de agente. Cuando un usuario espera una respuesta y la búsqueda es de tamaño normal, una única llamada síncrona es la experiencia más limpia: una herramienta, un resultado, ninguna lógica de polling en el prompt. Es la recomendación por defecto para una herramienta de búsqueda de tipo MCP.
• Usa el modelo de job async para trabajo amplio o de background. Cuando la búsqueda es amplia, cuando ejecutas muchas búsquedas en batch, o cuando el trabajo ocurre de forma programada sin un humano esperando, el patrón job_id más poll es más robusto y deja al agente (o a tu orquestación) hacer otra cosa mientras el job corre. Combínalo con una segunda herramienta que comprueba el estado del job, o con un webhook para que el agente sea notificado al completarse en lugar de pollar.

Ambos modos golpean el mismo motor de búsqueda y devuelven la misma forma de registro estable, así que puedes exponer ambos como herramientas y dejar que el agente (o tu diseño) elija según la petición. El compromiso honesto es latencia contra simplicidad: wait:true mantiene la conexión abierta hasta que los resultados están listos, mientras que la vía async vuelve de inmediato y desplaza la espera al polling. Para la mayoría de las conversaciones de agente, la vía síncrona gana en simplicidad para desarrollador y modelo.

Ser honestos sobre qué devuelve la herramienta

Una herramienta de agente solo es fiable si es honesta sobre la cobertura, así que los mismos caveats que se aplican a la extracción de emails de sitio se aplican aquí.

• La cobertura de emails es parcial. Algunos negocios solo publican un formulario de contacto, y algunos renderizan su dirección como imagen. Esos registros vuelven con un sitio y un teléfono pero ningún email, lo cual es preciso, no un bug. Construye el filtrado del agente en torno a "registros con un email cuando el email es obligatorio" en lugar de asumir que cada negocio tiene uno.
• Los datos reflejan lo que es público. biz collect devuelve datos de contacto verificados extraídos de fuentes en tiempo real y de los sitios propios de los negocios. No inventa campos para rellenar los vacíos, exactamente la propiedad que lo hace seguro de entregar a un modelo.
• Las otras capacidades se describen de forma justa. Muchas herramientas pueden envolverse para los agentes; lo que hace fácil una herramienta de datos de empresas es la combinación de una spec OpenAPI precisa, una forma JSON estable, un modo síncrono y llms.txt. Cualquier API con estas propiedades es agradable de envolver; biz collect simplemente ofrece las cuatro.

Esta honestidad es lo que deja a un agente actuar sobre los resultados sin que un humano recompruebe cada registro, que es el propósito entero de darle a un agente una verdadera herramienta de datos.

Empezar a construir

Darle a un agente IA datos de empresas en tiempo real no requiere una integración a medida. Requiere una herramienta con un nombre claro, una descripción que dice cuándo llamarla y un esquema que corresponde a una verdadera API, más un backend que devuelve registros estables y verificados. biz collect proporciona el backend: una spec OpenAPI 3.1 de la que generar herramientas, un llms.txt que orienta rápido a los agentes, una respuesta JSON estable y un modo wait:true que convierte todo el ciclo buscar-y-enriquecer en una única llamada de herramienta síncrona.

Define una herramienta search_local_businesses, apúntala al endpoint wait:true, y tu agente puede convertir una ciudad y una categoría en leads locales enriquecidos y deduplicados en un solo round trip. Es gratuito para empezar con 200 créditos de registro y sin tarjeta, suficiente para construir la herramienta, cablearla en tu runtime y ver a un agente llamarla de principio a fin.

Abre los docs de la API para la spec OpenAPI, revisa las integraciones, consulta los precios y dale hoy a tu agente una herramienta de datos de empresas en tiempo real.