Directorio hispano Miami-Centroamérica: busca negocios, reserva citas reales y ordena comida.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: search businesses, check availability, place an order, book an appointment, and view business details. No overlap or ambiguity between them, and the relationships (availability → booking, search → details) are complementary rather than confusing.
All tool names follow a consistent 'verb_noun' pattern in Spanish (buscar_negocios, consultar_disponibilidad, pedir_comida, reservar_cita, ver_negocio). The verbs are imperative and the nouns indicate the resource, creating a predictable and uniform convention across the entire set.
Five tools is well-scoped for a directory system covering search, details, appointments, and ordering. Each tool earns its place, and the count is neither too sparse nor overwhelming for the domain.
The tool surface covers core workflows: find business, view details, check availability, book, and order. Minor gaps include missing appointment cancellation or order status/cancellation, but these are likely secondary and do not severely impede primary user goals.
buscar_negociosBuscar negocios / Search businessesAInspectES: Busca negocios del directorio público (Miami–Centroamérica) por ubicación {lat,lng}, ciudad, categoría o texto libre. Sin ubicación ni ciudad devuelve el listado por país/global. / EN: Search the public business directory (Miami–Central America) by location {lat,lng}, city, category or free text. Without a location or city it returns the country/global listing.
| Name | Required | Description | Default |
|---|---|---|---|
| texto | No | Búsqueda libre en nombre y descripción / Free-text search | |
| ciudad | No | Filtrar por ciudad, p.ej. "Miami" / Filter by city | |
| categoria | No | Categoría: restaurante, tienda, belleza, salud, fitness, hotel… / Category | |
| ubicacion | No | Ubicación del USUARIO (no la del agente) / The USER's location (not the agent's) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure. It does explain the geographic scope (Miami–Central America), public nature of the directory, and the fallback behavior when no location or city is supplied. However, it does not disclose result pagination, limits, ordering, or whether it is strictly read-only aside from what 'search' implies.
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 compact, front-loaded, and contains no wasted words. The bilingual text is the same idea in two sentences, which is appropriate and easy to scan.
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 the simplicity of the tool and the full parameter schema, the description covers the essential behavioral context: what is searched, where it is searched, and what happens with no location or city. It could also mention output shape or result limits, but the absence does not block expecting an agent from selecting or invoking the tool.
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 describes all four properties, so the baseline is high. The description adds meaningful semantics by clarifying that omitting both location and city falls back to a country/global listing, which is useful for deciding which of the optional parameters to provide. This is a valuable addition rather than a repetition of 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 uses a specific verb ('Busca/Search') on a clearly defined resource ('public business directory') and enumerates four concrete filters: location, city, category, and free text. This makes it easy to recognize and distinguish from sibling tools like ver_negocio or reservar_cita.
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 says when to use the tool—search the directory by location, city, category, or text—and adds an explicit fallback: without location or city it returns the country/global listing. It does not explicitly name exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
consultar_disponibilidadConsultar disponibilidad / Check availabilityAInspectES: Horarios libres para cita en una fecha (opcionalmente para un servicio). Devuelve horas por profesional con su staffId, listo para reservar_cita. / EN: Free appointment slots for a date (optionally for one service). Returns hours per staff member with staffId, ready for reservar_cita.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug del negocio (de buscar_negocios) / Business slug (from buscar_negocios) | |
| fecha | Yes | Fecha YYYY-MM-DD | |
| servicio | No | Nombre del servicio (como sale en ver_negocio) / Service name (as shown by ver_negocio) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states this is a read-only availability query and discloses the return structure (hours per staff with staffId). It does not mention edge cases like no availability, but for a simple query tool this is reasonably transparent.
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, bilingual, and front-loaded with the core action. Every phrase carries meaning, including the optionality and the integration with the next tool. No filler or redundancy.
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 3-parameter query tool with no output schema, the description is complete: it explains what the tool does, the optional parameter, the output structure, and the downstream workflow. This is sufficient for an agent to select and invoke 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. The description adds only minor context—confirming servicio is optional and that staffId is intended for reservar_cita—but does not provide additional 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 uses specific verbs and resources: 'Free appointment slots for a date' and 'Returns hours per staff member with staffId.' It distinguishes itself from siblings by explicitly stating the output is 'ready for reservar_cita,' making its role in the workflow clear.
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 'listo para reservar_cita' implicitly advises using this tool before booking, and the optional service filter is noted. However, it does not explicitly state when not to use this tool or how it compares to alternatives like ver_negocio, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pedir_comidaPedir comida/productos (efectivo) / Order food (cash)AInspectES: Crea un pedido REAL de comida/productos que se paga EN EFECTIVO al recoger (pickup) o al recibir (delivery). Mandá los nombres de los ítems tal como salen en ver_negocio; el servidor resuelve los productos reales y nunca inventa precios. Delivery exige direccion y que el negocio lo tenga habilitado. / EN: Places a REAL food/product order paid IN CASH on pickup or on delivery. Send item names as shown by ver_negocio; the server resolves the real products and never invents prices. Delivery requires an address and the business having delivery enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug del negocio (de buscar_negocios) / Business slug (from buscar_negocios) | |
| items | Yes | ||
| notas | No | Notas de entrega (solo aplican a delivery) | |
| nombre | Yes | Nombre del cliente / Customer name | |
| entrega | Yes | pickup = recoger en el local (paga en efectivo al recoger); delivery = a domicilio (paga en efectivo al recibir) | |
| telefono | Yes | Teléfono del cliente / Customer phone | |
| direccion | No | Dirección completa de entrega (obligatoria si entrega=delivery) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Explicitly states it creates a REAL order, cash payment, and no invented prices. Could mention side effects (e.g., order confirmation) but covers key behaviors.
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?
Bilingual but concise, with clear structure separating purpose, item guidance, and delivery constraints. No fluff or redundant content.
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?
Sufficiently complete for its purpose: covers key constraints, required flow, and specific delivery rules. No output schema exists, so return values are not part of the scope. Minor omission: no mention of error cases or cancellation policies.
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 covers most parameters with descriptions. Tool description adds crucial semantics for 'entrega' (cash on pickup vs delivery) and clarifies 'nombre' items should match ver_negocio. 'direccion' requirement for delivery is also highlighted.
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?
Clear statement that this tool creates a real cash-only order for pickup or delivery, distinguishing it from search/availability/appointment tools. Mentions it resolves real products and never invents prices.
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?
Provides explicit instructions to send item names as they appear in ver_negocio and notes delivery requires an address and enabled delivery. Lacks explicit 'when not to use' but context with sibling tools makes it unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reservar_citaReservar cita / Book appointmentAInspectES: Reserva una cita REAL como invitado (nombre + teléfono). La confirmación llega por WhatsApp/SMS al teléfono dado. Usá consultar_disponibilidad primero para elegir hora y staffId. / EN: Books a REAL appointment as a guest (name + phone). Confirmation arrives via WhatsApp/SMS to the given phone. Use consultar_disponibilidad first to pick a time and staffId.
| Name | Required | Description | Default |
|---|---|---|---|
| hora | Yes | Hora HH:MM (24h), de consultar_disponibilidad | |
| slug | Yes | Slug del negocio (de buscar_negocios) / Business slug (from buscar_negocios) | |
| fecha | Yes | Fecha YYYY-MM-DD | |
| notas | No | ||
| nombre | Yes | Nombre del cliente / Customer name | |
| staffId | No | staffId de consultar_disponibilidad (opcional: sin él se asigna el primer profesional con esa hora libre) / staffId from consultar_disponibilidad (optional: otherwise the first staff member free at that time is assigned) | |
| servicio | Yes | Nombre del servicio / Service name | |
| telefono | Yes | Teléfono del cliente (con código de país si es posible) / Customer phone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No se proporcionan anotaciones, por lo que la descripción carga con la transparencia. Se dice claramente que es una cita 'REAL', que se crea como invitado y que la confirmación llega por WhatsApp/SMS, revelando el efecto principal y el canal de retorno. Sin embargo, no se informa sobre modos de fallo, requisitos de autenticación, irreversibilidad o límites, quedando una transparencia media para una operación mutante.
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 descripción es breve y directa: dos frases por idioma (ES/EN), con el propósito al inicio y el prerequisito al final. No hay palabras de relleno ni repetición innecesaria; cada oración aporta información relevante. La estructura bilingüe es eficiente y bien organizada.
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?
Con 8 parámetros y sin schema de salida ni anotaciones, la descripción cubre los puntos clave: se trata de una reserva real, se requiere nombre y teléfono, la confirmación llega por WhatsApp/SMS, y se debe consultar disponibilidad antes. No menciona la forma de respuesta ni casos de error, pero el prerequisito y el efecto principal están presentes, lo que resulta suficiente para un flujo de reserva simple.
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?
La cobertura del schema es del 88% (7/8 parámetros documentados), por lo que el peso recae en el schema. La descripción agrega una pista sobre 'hora y staffId' vinculándolos a consultar_disponibilidad, lo que da contexto de procedencia, pero no explica cada parámetro individual. Ni el schema ni la descripción detallan el significado de 'notas', el único sin cobertura. Se mantiene en el puntaje base de 3.
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 ('Reserva/Books') con un recurso claro ('una cita REAL como invitado'), comunicando la acción y el alcance exacto. Diferencia de sus hermanos: consultar_disponibilidad es para ver disponibilidad, no para reservar. Menciona el tipo de cita (real) y el flujo, eliminando ambigüedad con las demás herramientas.
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?
La descripción entrega una instrucción explícita de uso previo: 'Usá consultar_disponibilidad primero para elegir hora y staffId'. Esto orienta al agente sobre el paso previo y la secuencia correcta. No indica explícitamente cuándo NO usar esta herramienta, pero el contexto de los hermanos (pedir_comida, buscar_negocios) hace evidente la distinción.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ver_negocioVer ficha del negocio / View business profileAInspectES: Ficha completa de un negocio por slug: horarios, rating y reseñas, catálogo con precios y variantes, promociones vigentes, eventos próximos y enlaces útiles. / EN: Full business profile by slug: hours, rating and reviews, catalog with prices and variants, active promotions, upcoming events and useful links.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug del negocio (de buscar_negocios) / Business slug (from buscar_negocios) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It clearly lists the contents of the profile (hours, rating, reviews, catalog, promotions, events, links), making the return behavior transparent. However, it doesn't mention any side effects, authorization requirements, or error behavior, but since it's a read-only view, it doesn't need to. The description adds value beyond a simple
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, information-dense sentence that front-loads the purpose and lists contents without redundancy. Bilingual formatting is efficient and doesn't waste tokens.
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 no output schema, the description enumerates the returned data (hours, rating, reviews, catalog, promotions, events, links). It lacks error behavior or notes on missing slug handling, but for a simple read tool this is adequately 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 schema covers full parameter details (pattern, max length) and description gives usage: 'Business slug (from buscar_negocios)'. This adds semantic context beyond schema, tying it to a sibling tool. Though schema covers constraints, the description adds source context.
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 clearly states the tool retrieves a full business profile by slug, listing all included sections (hours, rating, reviews, catalog, promotions, events, links). It uses a specific verb and resource, and the content distinguishes it from sibling tools like buscar_negocios (search) and reservar_cita (booking).
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 specifies that the slug comes from buscar_negocios, implying a workflow: first search, then get details. This gives clear context on when to use this tool after searching. However, it doesn't explicitly state when not to use it or alternative scenarios, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!