Servicialo — Open Protocol for AI-Coordinated Services
About
Open standard for professional service delivery. Defines how any AI agent can discover, schedule, verify, and bill professional services across any compatible platform — without custom integrations.
Details
- Author
- servicialo
- Downloads
- 312
- Categories
- Other, AI, Automation, Project Management
Jump to
- 33 tools across 7 phases of service coordination.
- Resolve endpoints with resolve_lookup and resolve_search.
- Discover availability and services via registry_search and scheduling_check_availability.
- Commit to bookings with clients_get_or_create, scheduling_book, and scheduling_confirm.
- Manage lifecycle with state transitions, rescheduling, and cancellation.
- Deliver evidence with check-in, check-out, and recording evidence.
- Close billing and payments with sale creation and payment recording.
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
Servicialo — Open Protocol for AI-Coordinated ServicesCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
Configure the MCP server in your client with the command npx -y @servicialo/mcp-server@latest and set the environment variables SERVICIALO_API_KEY (your API key) and SERVICIALO_ORG_ID (your organization slug). Credentials are obtained from a Servicialo-compatible platform; the reference implementation is Coordinalo.
registry_search
Search for Servicialo-compatible organizations by vertical, location, and country. Use this as the primary discovery tool when a user needs a service (e.g., "find a physiotherapist in Santiago"). Do NOT use if you already have an org_slug (use registry.get_organization instead). Returns a ranked list of organizations with names, slugs, and service summaries.
registry_manifest
Get the Servicialo server manifest: protocol version, server name, and available capabilities. Use this to verify server identity and protocol compatibility before interacting with tools. Do NOT use for organization discovery (use registry.search) or service details (use services.list). Returns static metadata about this MCP server instance, not about any specific organization.
registry_get_organization
Get the full public profile of a specific organization: services offered, providers, and booking configuration. Use this after registry.search when you have an org_slug and need detailed info before booking. Do NOT use for searching across organizations (use registry.search). Returns service catalog with prices/durations, provider list, and booking policies.
scheduling_check_availability
Query available time slots for booking at an organization. No authentication required. Use this after services.list when you know the org and need to find open slots before booking. Checks 3-way availability: provider schedule AND client conflicts AND physical resource (room/equipment). Do NOT use for searching organizations (use registry.search) or listing services (use services.list). Returns available slots grouped by date, each with start time, end time, provider, and resource.
services_list
List the public service catalog of an organization: names, prices, durations, and modalities. Use this after registry.search to see what services an organization offers before checking availability. Do NOT use for organization discovery (use registry.search) or checking time slots (use scheduling.check_availability). Returns active, publicly bookable services only — internal or draft services are excluded.
resolve_lookup
Resolve an organization slug to its MCP/REST endpoints and trust level — the DNS of professional services. Use this when you know the org_slug and need its API endpoint before calling any other tool. Do NOT use for searching by vertical or location (use resolve.search or registry.search instead). Returns: endpoint URLs, trust score (0-100), trust level, and last heartbeat timestamp.
resolve_search
Search the global Servicialo resolver for registered organizations by country and vertical. Use this for broad discovery when you need to find all organizations in a country/vertical (e.g., "what physiotherapy clinics exist in Chile?"). Do NOT use if you already have an org_slug (use resolve.lookup instead). Unlike registry.search, this queries the DNS-level resolver and returns endpoint URLs + trust levels.
trust_get_score
Get the trust score of an organization from the Servicialo resolver. Use this to evaluate reliability before booking — returns score (0-100), trust level (unverified → declared → vouched → verified), and last activity timestamp. Do NOT use this to find organizations (use resolve.search). Trust accumulates passively from verified service history; it cannot be purchased or self-declared.
a2a_get_agent_card
Get the A2A (Agent-to-Agent) Agent Card for an organization, enabling inter-agent discovery. Use this when your agent needs to communicate with another agent managing this organization — the card declares supported capabilities, endpoints, and authentication requirements. Do NOT use for human-facing discovery (use registry.get_organization) or service listing (use services.list). Returns a JSON-LD Agent Card following the A2A v0.3 specification.
docs_quickstart
Get the complete 5-step onboarding guide as structured JSON data. Use this when helping a new organization join the Servicialo network — covers installation, signup, credentials, MCP client config, and publishing. Do NOT use for searching services (use registry.search) or checking availability (use scheduling.check_availability). Returns step-by-step instructions, config templates, and links. No parameters required.
market_list_segments
List every (event_type, vertical, region) segment that has at least 5 distinct contributing organizations over the last 90 days — i.e. every benchmark that the protocol is allowed to publish without violating k-anonymity. Use this to discover what benchmarks exist before issuing market.get_benchmark. Filters are optional; passing none lists all available segments sorted by contributor count. Returns: array of { event_type, vertical, region, sample_size, contributors, first_event, last_event }.
market_get_benchmark
Get the bucket distribution for a (event_type, vertical, region) segment over a time window. Returns the share of each bucketed value within the payload (e.g. for booking_created, the share of bookings in each lead_time_bucket). All values are categorical buckets — no raw prices, durations, or names are ever returned. If the segment has fewer than 5 distinct contributing organizations, returns { ok: false, reason: "insufficient_data", contributors }. Use market.list_segments first to know which segments will return data. Example: market.get_benchmark({ event_type: "payment_settled", vertical: "health", region: "CL" }) → distribution of price bands, payment methods, time-to-collect buckets.
registry_list_verticals
List every vertical present in the Servicialo network. Combines (a) verticals that registered nodes declare and (b) verticals observed in operational telemetry over the last 30 days. Use as the first call when an agent has no prior knowledge of the protocol taxonomy — before issuing market.get_benchmark, registry.search, or any other call that requires a `vertical` argument. Returns: array of { name, org_count, event_count_30d } sorted by activity. Test fixtures (verticals starting with `_`) are excluded.
registry_list_regions
List every country/region present in the Servicialo network. Combines countries declared by registered nodes with regions observed in operational telemetry over the last 30 days. Use this when an agent needs to know "where is this protocol active?" before issuing a region-scoped query. Returns: array of { code, org_count, event_count_30d } sorted by activity. Codes are ISO 3166-1 alpha-2.
registry_list_event_types
List the catalog of operational-telemetry event types defined by the Servicialo protocol. Static (changes via RFC), but exposed as a discovery call so agents can know what event names market.get_benchmark accepts and what bucketed fields each event carries — without having to read the JSON Schema. Returns: array of { name, description, payload_fields[] } plus a `schema_url` for the canonical reference.
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"servicialo \u2014 open protocol for ai-coordinated services": {
"servicialo": {
"command": "npx",
"args": [
"-y",
"@servicialo/mcp-server@latest"
],
"env": {
"SERVICIALO_API_KEY": "<tu_api_key>",
"SERVICIALO_ORG_ID": "<tu_org_slug>"
}
}
}
}
}McpServers
{
"servicialo": {
"command": "npx",
"args": [
"-y",
"@servicialo/mcp-server@latest"
],
"env": {
"SERVICIALO_API_KEY": "<tu_api_key>",
"SERVICIALO_ORG_ID": "<tu_org_slug>"
}
}
}La capa de orquestación para la economía de servicios en la era de agentes AI
Un protocolo abierto para coordinación de agenda, identidad, verificación
de entrega y liquidación financiera de servicios profesionales.
Protocolo abiertoLegible por máquinasAgent-nativeApache-2.0
Sitio web・Especificación・Gobernanza・MCP Server・npm
Nuevo en Servicialo? Empieza aqui →SPEC.md
Spec completa (crawler-friendly):https://servicialo.com/spec
For a formal description of the architecture, message flows, and data model:
- Whitepaper v0.9— formal protocol specification
- Protocol repository— schemas, RFCs, and reference materials
- PROTOCOL.md— full specification in this repo
El protocolo distingue primitivas de evento (SC, CAC) de modelos de billing (SC, CAC, RAC). VerGLOSSARY.mdpara definiciones completas.
Tengo un negocio de serviciosy quiero que agentes AI descubran y agenden mis servicios → Necesitas una plataforma compatible con el protocolo, no este repositorio.Coordinaloes la implementación de referencia. A medida que el protocolo madure, esperamos que surjan muchas más plataformas compatibles.
Soy un desarrolladorque quiere construir una plataforma compatible con el protocolo → Sigue leyendo. Empieza porIMPLEMENTING.md.
Sin un protocolo estándar, cada plataforma de servicios habla su propio idioma. Un agente AI que quiere agendar una cita médica, verificar una reparación a domicilio o cobrar una consulta legal necesita una integración distinta para cada una. Los datos quedan en silos, la interoperabilidad requiere integraciones custom, y la inteligencia colectiva sobre entrega de servicios nunca se forma.
Servicialo es el protocolo común.Define el esquema mínimo viable para que cualquier agente AI coordine cualquier servicio profesional en cualquier plataforma compatible — sin integración adicional.
Servicialo define cuatro primitivas de coordinación. Juntas cubren la cadena de valor completa de la entrega de servicios profesionales:
Cada primitiva se especifica de forma independiente. Las implementaciones adoptan lo que necesitan.
Un servicio es una promesa de transformación entregada en un momento y lugar específico.
A diferencia de un producto, un servicio no se puede almacenar, revender ni devolver. Se consume en el momento en que se entrega. Eso lo hace fundamentalmente diferente — y es por eso que necesita su propio protocolo.
Todo servicio profesional — desde una sesión de kinesiología hasta una auditoría tributaria — se modela con las mismas 8 dimensiones:
El pagador no siempre es el cliente.En salud paga la aseguradora. En corporativo paga la empresa. En educación paga el apoderado. El protocolo separa explícitamente al cliente del pagador — porque en la vida real casi nunca son la misma persona.
El ciclo de vida: 6 estados core + 3 financieros opcionales
El protocolo define estados independientes para observar el ciclo completo de una coordinación. Los 9 hitos siguientes son elcamino feliz— la ruta operativa más común, no una secuencia única obligatoria. Los 6 primeros son requeridos; los 3 financieros son una extensión opcional. Entrega, evidencia, aceptación y liquidación evolucionan de manera independiente ([PROTOCOL.md §6.0):
Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → (opcional) Facturado → Cobrado → Verificado
Verificado es el cierre.El cliente no puede verificar hasta tener el cuadro completo: la evidencia documentada, la factura emitida y el cobro aplicado. Verificación prematura obliga al cliente a confirmar algo que aún no tiene registro formal.
Las excepciones no son casos excepcionales. Ocurren en el15–30% de las citas. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan:
El protocolo se construye sobre dos objetos y su relación:
Organización └── Orden de Servicio ← acuerdo comercial (opcional) ├── alcance qué servicios, cuántos, de qué tipo ├── precio cómo se calcula el valor ├── esquema de pagos cuándo se mueve el dinero └── Servicios ← unidades atómicas de entrega └── 8 dimensiones cada uno
La Service Deliveryes la instancia atómica ejecutada — lo que realmente ocurrió. En el wire format actual se representa con el objetoService(nombre conservado por compatibilidad).La Orden de Servicioes el acuerdo comercial que agrupa entregas bajo un alcance, un precio y un esquema de pagos. "Servicio" a secas es el término general del dominio, no un cuarto objeto.
Cuando un Servicio pertenece a una Orden, su dimensión de cobro esinformativa— registra el valor económico, pero no genera factura. La facturación es responsabilidad exclusiva de la Orden.
La misma estructura funciona para cualquier vertical:
Cada vertical define, por política, qué evidencia acredita una entrega. Los perfiles siguientes son ejemplos configurables — no requisitos universales del protocolo: cada acuerdo puede exigir evidencias distintas, y la privacidad, la proporcionalidad y la regulación acotan qué corresponde recopilar. La acreditación resultante vale bajo la política aplicada y con su nivel de certeza; no determina por sí sola la calidad del servicio ni la verdad absoluta de cada afirmación. Sin ambigüedad — requisitos explícitos, previamente acordados, para producir una Prueba de Servicio acreditable:
Regla de acreditación ilustrativa:Si las evidencias que esta política exige — registros de entrada/salida y ficha firmada — están presentes y son válidas → la entrega se acredita bajo esta política, con su nivel de certeza. Si falta ficha o firma → escalar.
Regla de acreditación ilustrativa:Si fotos antes/después existen con metadatos válidos y lista completa → la entrega se acredita bajo esta política, con su nivel de certeza. Si falta firma del cliente → escalar.
Regla de acreditación ilustrativa:Si minuta existe y horas registradas dentro del rango acordado → la entrega se acredita bajo esta política, con su nivel de certeza. Si horas exceden lo acordado sin justificación → escalar.
Regla de acreditación ilustrativa:Si asistencia registrada y material entregado → la entrega se acredita bajo esta política, con su nivel de certeza. Si falta evaluación y contrato la requiere → escalar.
Resolución de disputas — extensión en diseño
El módulo de disputas (Servicialo/Disputas) estáen diseño— el flujo siguiente describe el diseño objetivo, no una capacidad operativa:
1. Apertura— Cualquier parte abre disputa dentro del plazo definido. Se congela el cobro automáticamente.
2. Revisión de evidencia— Se solicita evidencia adicional de ambas partes. El sistema compara evidencia registrada contra el contrato.
3. Resolución— Si proveedor gana: Cobrado → Verificado. Si cliente gana: Cancelado con balance restaurado.
Objetivo de diseño:automatizar la resolución de los casos cuya evidencia satisface reglas previamente acordadas en el contrato. Los casos que la evidencia no resuelve escalarían a revisión humana; el arbitraje por pares del mismo vertical es una línea de investigación, no un mecanismo desplegado.
Servicialo expone sus herramientas como un servidor MCP, permitiendo que agentes AI descubran y coordinen servicios profesionales de forma nativa.
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
