io.github.danioni/servicialo

编码与调试

by servicialo

面向 AI agents 的专业服务交付开放协议,用于标准化服务请求、协作与执行流程。

什么是 io.github.danioni/servicialo

面向 AI agents 的专业服务交付开放协议,用于标准化服务请求、协作与执行流程。

README

<div align="center">

Servicialo

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<br> de entrega y liquidación financiera de servicios profesionales.

Protocolo abierto Legible por máquinas Agent-native Apache-2.0

Sitio webEspecificaciónGobernanzaMCP Servernpm

Nuevo en Servicialo? Empieza aqui → SPEC.md

Spec completa (crawler-friendly): https://servicialo.com/spec

Read in English

</div>

Protocol Specification

For a formal description of the architecture, message flows, and data model:


¿Por dónde empiezo?

Tengo un negocio de servicios y quiero que agentes AI descubran y agenden mis servicios → Necesitas una plataforma compatible con el protocolo, no este repositorio. Coordinalo es la implementación de referencia. A medida que el protocolo madure, esperamos que surjan muchas más plataformas compatibles.

Soy un desarrollador que quiere construir una plataforma compatible con el protocolo → Sigue leyendo. Empieza por IMPLEMENTING.md.


El problema

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.


Primitivas del protocolo

Servicialo define cuatro primitivas de coordinación. Juntas cubren la cadena de valor completa de la entrega de servicios profesionales:

PrimitivaQué resuelveSuperficie del protocolo
Coordinación de agendaIntersección de disponibilidad multi-parte (proveedor, cliente, recurso) con manejo de excepciones9 estados del ciclo de vida, 6 flujos de excepción, scheduler de 3 variables
Verificación de identidadCredenciales del proveedor, puntaje de confianza, separación cliente-pagadorCredenciales del proveedor, trust_score, separación payer_id
Liquidación financieraFacturación, cobranza, liquidación y revenue sharing con resolución de disputasDimensión de cobro, ledger de Orden de Servicio, payment_schedule
Señales de demandaTelemetría operacional anónima y agregada entre nodos de la redExtensión de Telemetría (modelo contribuir-para-acceder)

Cada primitiva se especifica de forma independiente. Las implementaciones adoptan lo que necesitan.


Qué es un servicio

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.

Un servicio nace de tres fuentes:

OrigenPregunta claveEjemplo
Desde un activoQué tienes que otros necesitan?Un departamento vacío → hospedaje temporal
Desde una ventajaQué sabes que otros no?Certificación en kinesiología → rehabilitación deportiva
Desde tu tiempoQué puedes hacer que otros no quieren o no pueden?Horas disponibles → limpieza profesional

Las 8 dimensiones

Todo servicio profesional — desde una sesión de kinesiología hasta una auditoría tributaria — se modela con las mismas 8 dimensiones:

DimensiónQué capturaEjemplo
1QuéLa actividad o resultado que se entregaSesión de kinesiología, reparación eléctrica
2Quién entregaEl proveedor del servicio, con credencialesKinesiólogo certificado, electricista SEC
3Quién recibeEl cliente — con pagador separado explícitamentePaciente (paga FONASA), empleado (paga empresa)
4CuándoVentana temporal acordada2026-02-10 de 10:00 a 10:45
5DóndeUbicación física o virtual, con resource_id opcional que referencia un Recurso físico (3.5b: sala, box, sillón, equipamiento)Sala 3 de clínica, domicilio, videollamada
6CicloPosición actual en los 9 estados del ciclo de vidaCobrado → próximo: Verificado
7EvidenciaCómo se prueba que el servicio ocurrióGPS + duración + firma del cliente
8CobroLiquidación financiera, independiente del ciclo$35.000 CLP · cobrado · paquete prepago

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.


Los 9 estados universales

No importa si es un masaje o una auditoría. Todo servicio transiciona por el mismo ciclo de vida:

code
Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → Facturado → Cobrado → Verificado
#EstadoQué ocurre
1SolicitadoEl cliente o su agente define qué necesita, cuándo y dónde
2AgendadoSe asigna hora, proveedor y ubicación. Se bloquea el horario
3ConfirmadoAmbas partes reconocen el compromiso
4En CursoRegistro de entrada detectado. El servicio está siendo entregado
5CompletadoEl proveedor marca la entrega como completa
6DocumentadoRegistro formal generado: ficha clínica, reporte, minuta
7FacturadoDocumento tributario emitido
8CobradoPago recibido y confirmado
9VerificadoEl cliente confirma — cierre del ciclo

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 son la regla

Las excepciones no son casos excepcionales. Ocurren en el 15–30% de las citas. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan:

ExcepciónTransiciónQué pasa
Inasistencia del clienteConfirmado → CanceladoSe aplica penalidad, se libera tiempo del proveedor
Inasistencia del proveedorConfirmado → Reasignando → AgendadoSe busca reemplazo automáticamente
CancelaciónCualquier pre-entrega → CanceladoSe aplica la política de cancelación acordada
Disputa de calidadCompletado → DisputadoSe congela el cobro, se solicita evidencia
ReagendamientoAgendado/Confirmado → Reagendando → AgendadoSe mantiene el proveedor si es posible. Incluye conflictos de recurso (doble reserva, recurso no disponible)
Entrega parcialEn Curso → ParcialSe documenta lo entregado, se ajusta la factura

Servicio y Orden de Servicio

El protocolo se construye sobre dos objetos y su relación:

code
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

El Servicio es la unidad atómica de entrega — lo que realmente ocurrió. La Orden de Servicio es el acuerdo comercial que agrupa servicios bajo un alcance, un precio y un esquema de pagos.

Cuando un Servicio pertenece a una Orden, su dimensión de cobro es informativa — 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:

VerticalEjemploAlcancePagos
SaludPlan de kinesiología12 sesionesPor sesión
ConsultoríaContrato por horas40 horas de asesoría legalMensual según consumo
ProyectosAuditoría previa en 3 fasesHitos definidosPor hito aprobado

Evidencia por vertical

Cada vertical define qué constituye prueba de que el servicio ocurrió. Sin ambigüedad — para que un algoritmo pueda resolver el 80% de las disputas sin intervención humana:

<details> <summary><b>Salud</b> — 4 tipos de evidencia</summary>
EvidenciaDescripciónCaptura
Registro de entradaMarca temporal GPS del proveedor al llegarauto
Registro de salidaMarca temporal GPS del proveedor al salirauto
Ficha clínica firmadaRegistro clínico firmado por profesional y pacientemanual
Adherencia al planLista de verificación del plan de tratamiento ejecutadomanual

Regla de resolución: Si registros de entrada/salida existen y ficha clínica está firmada por ambas partes → servicio entregado. Si falta ficha o firma → escalar.

</details> <details> <summary><b>Hogar</b> — 4 tipos de evidencia</summary>
EvidenciaDescripciónCaptura
Foto antesFoto del estado inicial con marca temporal y GPSmanual
Foto despuésFoto del resultado final con marca temporal y GPSmanual
Lista de verificaciónTareas acordadas marcadas como completadasmanual
Firma del clienteFirma digital del cliente confirmando recepciónmanual

Regla de resolución: Si fotos antes/después existen con metadatos válidos y lista completa → servicio entregado. Si falta firma del cliente → escalar.

</details> <details> <summary><b>Legal</b> — 3 tipos de evidencia</summary>
EvidenciaDescripciónCaptura
Minuta de reuniónRegistro de lo discutido y acordadomanual
Entrega de documentosConfirmación de entrega de documentos generadosmanual
Registro de horasHoras facturables con descripción de actividadesmanual

Regla de resolución: Si minuta existe y horas registradas dentro del rango acordado → servicio entregado. Si horas exceden lo acordado sin justificación → escalar.

</details> <details> <summary><b>Educación</b> — 3 tipos de evidencia</summary>
EvidenciaDescripciónCaptura
Registro de asistenciaConfirmación de presencia del alumno y profesorauto
Entrega de materialMaterial o tareas entregadas al alumnomanual
EvaluaciónEvaluación o retroalimentación de la sesiónmanual

Regla de resolución: Si asistencia registrada y material entregado → servicio entregado. Si falta evaluación y contrato la requiere → escalar.

</details>

Resolución de disputas

Cuando hay desacuerdo, el mecanismo no depende de buena voluntad, no requiere un juez centralizado, y un agente AI puede ejecutarlo con la misma confianza que un humano:

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.

80/20. El 80% de las disputas se resuelven automáticamente comparando evidencia contra contrato. Sin intervención humana, sin discrecionalidad, sin demora. El 20% restante escala a árbitros del mismo vertical profesional que votan en 48 horas.


Servidor MCP

Servicialo expone sus herramientas como un servidor MCP, permitiendo que agentes AI descubran y coordinen servicios profesionales de forma nativa.

Inicio rápido

El package @servicialo/mcp-server es un thin-client que conecta a la API HTTP de una plataforma Servicialo-compatible. Por defecto apunta a Coordinalo (servicialo.com). Si estás construyendo tu propio backend, apunta al tuyo con SERVICIALO_BASE_URL. Si eres una organización usuaria (clínica, consultora, etc.), las credenciales las obtienes desde tu plataforma — no necesitas instalar este package directamente.

bash
npx -y @servicialo/mcp-server

Con eso, tu agente ya puede buscar organizaciones, consultar disponibilidad y listar servicios — sin credenciales.

Modo autenticado

Para el ciclo completo — agendar, verificar entrega, cobrar:

json
{
  "mcpServers": {
    "servicialo": {
      "command": "npx",
      "args": ["-y", "@servicialo/mcp-server"],
      "env": {
        "SERVICIALO_API_KEY": "tu_api_key",
        "SERVICIALO_ORG_ID": "tu_org_id"
      }
    }
  }
}

Las credenciales las obtiene cada organización desde la plataforma Servicialo-compatible que utilice.

Las fases del agente — 34 herramientas

Un agente bien diseñado sigue este orden:

#FaseQué resuelveHerramientas
0ResolverDónde está el endpointresolve.lookup · resolve.search · trust.get_score
1DescubrirQué hay disponibleregistry.search · registry.get_organization · registry.manifest · scheduling.check_availability · services.list · a2a.get_agent_card
2EntenderDimensiones y reglas del servicioservice.get · contract.get
3ComprometerIdentidad del cliente y reservaclients.get_or_create · scheduling.book · scheduling.confirm
4GestionarEstado y transicioneslifecycle.get_state · lifecycle.transition · scheduling.reschedule · scheduling.cancel
5VerificarEvidencia de que ocurriódelivery.checkin · delivery.checkout · delivery.record_evidence
6CerrarDocumentación y cobrodocumentation.create · payments.create_sale · payments.record_payment · payments.get_status
RecursosEspacios físicos y equipamientoresource.list · resource.get · resource.create · resource.update · resource.delete · resource.get_availability
Resolver adminPortabilidad y telemetríaresolve.register · resolve.update_endpoint · telemetry.heartbeat

El servidor envía telemetría anónima al arrancar para estadísticas del protocolo. Se puede desactivar con SERVICIALO_TELEMETRY=false.

El protocolo garantiza que cualquier agente pueda completar el ciclo completo con cualquier implementación compatible.

Ejemplos completos

Sesión de kinesiología — Vertical salud. Registro de entrada con GPS, ficha clínica firmada, pago por transferencia.

Reparación eléctrica — Vertical hogar. Visita a domicilio, fotos antes/después, lista de verificación, firma del cliente, pago en efectivo.

A2A Ready

Servicialo soporta A2A (Agent-to-Agent) como extensión opcional, permitiendo que agentes externos (Salesforce Agentforce, Google ADK, etc.) descubran y reserven servicios sin pasar por MCP.

Guía completa: docs/a2a-interoperability.md


Los 7 principios

#Principio
1Todo servicio tiene un cicloNo importa si es un masaje o una auditoría. Los 9 estados son universales.
2La entrega debe ser verificableSi no puedes probar que el servicio ocurrió, no ocurrió. El protocolo define qué constituye evidencia válida para que humanos y agentes AI puedan confiar en ella.
3El pagador no siempre es el clienteEn salud paga la aseguradora. En corporativo paga la empresa. En educación paga el apoderado. El protocolo separa explícitamente al cliente del pagador.
4Las excepciones son la reglaInasistencias, cancelaciones, reagendamientos, disputas. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan.
5Un servicio es un producto legible por máquinasTiene nombre, precio, duración, requisitos y resultado esperado. Definido así, cualquier agente AI puede descubrirlo, coordinarlo y cerrarlo con la misma confianza que un humano.
6El acuerdo es separado de la entregaLa Orden de Servicio define lo acordado. El servicio atómico define lo entregado. Son dos objetos distintos con dos ciclos de vida distintos.
7La inteligencia colectiva es un bien común del protocoloCada nodo que implementa el protocolo contribuye datos operacionales. La inteligencia agregada mejora a todos los nodos — como Waze, donde cada conductor contribuye y todos navegan mejor. Ninguna implementación es dueña de los datos de la red.

Arquitectura por capas

Adopta solo lo que necesitas. Core cubre el ciclo completo de entrega. Las extensiones agregan capacidades para operaciones especializadas.

Servicialo Core — estable

Todo lo necesario para modelar un servicio profesional de principio a fin.

Para cualquier plataforma donde dos partes toman un compromiso de entrega y necesitan una cuenta verificable de lo que ocurrió — desde una sociedad de psicólogos hasta una empresa de limpieza con múltiples cuentas, equipos y personal.

Incluye: 8 dimensiones · 9 estados del ciclo de vida · 6 flujos de excepción · 7 principios fundamentales · gestión de recursos · órdenes de servicio · prueba de entrega · protocolo MCP (34 herramientas) · resolución DNS · interoperabilidad A2A

Servicialo/Finanzas — en diseño

Distribución de pagos entre profesional, organización e infraestructura — con reglas claras de liquidación.

Para plataformas que intermedian pagos entre clientes y profesionales, o que cobran comisiones.

Servicialo/Disputas — en diseño

Resolución formal con arbitraje algorítmico (~80%) y por pares del mismo vertical (~20%).

Para plataformas con volumen suficiente o donde el monto por servicio hace que las disputas sean económicamente relevantes.


Schema

JSON Schemas para validación automática: schema/service.schema.json y schema/service-order.schema.json

yaml
# ─────────────────────────────────────────────
# SERVICIALO v0.9
# Dos entidades: Orden + Servicios atómicos
# ─────────────────────────────────────────────

orden_de_servicio:
  id: texto                      # Identificador único
  alcance: texto                 # Qué se acuerda entregar
  precio: número                 # Precio total acordado
  esquema_pagos: texto           # prepago | por_sesión | mensual
  currency: texto                # ISO 4217

  servicios[]:                   # Cada servicio atómico — 8 dimensiones

    servicio:
      id: texto
      orden_de_servicio_id: texto  # Referencia a la Orden padre
      tipo: texto                # Categoría del servicio
      vertical: texto            # salud | legal | hogar | educación | ...
      nombre: texto              # Nombre legible
      duración_minutos: entero
      visibilidad: texto         # public | unlisted | private

      proveedor:
        id: texto
        credenciales: texto[]    # Certificaciones requeridas
        puntaje_confianza: número  # 0-100 calculado por historial
        organización_id: texto

      cliente:
        id: texto
        pagador_id: texto        # Puede diferir del cliente

      agenda:
        solicitado_en: fecha_hora
        agendado_para: fecha_hora
        duración_esperada: minutos

      ubicación:
        tipo: presencial | virtual | domicilio
        dirección: texto
        recurso_id: texto        # Opcional — referencia a recurso físico

      ciclo_de_vida:
        estado_actual: enum[9]   # Los 9 estados universales
        transiciones: transición[]
        excepciones: excepción[]

      prueba_de_entrega:
        entrada: fecha_hora
        salida: fecha_hora
        duración_real: minutos
        evidencia: evidencia[]   # GPS, firma, fotos, documentos

      cobro:
        orden_de_servicio_id: texto  # Referencia a la Orden padre
        monto:
          valor: número
          moneda: texto          # ISO 4217
        pagador: referencia
        estado: pendiente | cobrado | facturado | pagado | disputado
        cobrado_en: fecha_hora
        documento_tributario: referencia  # Boleta/factura si se emitió

      mandato:                   # Delegación explícita a agente IA
        mandato_id: texto        # UUID único
        principal_id: texto      # Humano u organización
        agente_id: texto         # Agente que recibe la delegación
        alcances: texto[]        # resource:action (e.g. schedule:write)
        estado: activo | expirado | revocado | suspendido

# Ledger computado desde servicios verificados — nunca editable

Implementaciones

Cualquier plataforma puede implementar Servicialo. Para ser listada debe modelar las 8 dimensiones, implementar los 9 estados, manejar al menos 3 de los 6 flujos de excepción, adherir a los 7 principios fundamentales y exponer una API conectable al MCP server.

PlataformaVerticalCoberturaEstado
CoordinaloHealthcare8/8 dimensiones · 9/9 estados · 6/6 excepciones · 7/7 principiosLive

Coordinalo es la implementación de referencia. El segundo nodo es una oportunidad abierta — ver IMPLEMENTORS.md.

Para implementadores

Guía paso a paso para construir una plataforma compatible desde cero — 7 pasos, el primero toma 20 minutos. Empezar aquí: IMPLEMENTING.md (English)

Referencias adicionales:

  • schema/evidence/ — Schemas de evidencia por vertical (salud, hogar, legal, educación, consultoría)
  • ERRORS.md — Códigos de error del protocolo
  • WEBHOOKS.md — Notificaciones asíncronas de cambios de estado (borrador)

Qué hay en este repositorio

code
servicialo/
├── app/                  # servicialo.com — sitio del protocolo (Next.js)
├── components/           # Componentes del sitio
├── examples/             # Conversaciones agente-servidor
├── lib/                  # Datos del protocolo
├── packages/
│   └── mcp-server/       # @servicialo/mcp-server — servidor MCP (npm)
├── schema/               # JSON Schemas para validación
│   ├── evidence/         # Schemas de evidencia por vertical
│   │   ├── base.schema.json       # Envelope compartido
│   │   ├── health.schema.json     # Salud
│   │   ├── home.schema.json       # Hogar
│   │   ├── legal.schema.json      # Legal
│   │   ├── education.schema.json  # Educación
│   │   └── consulting.schema.json # Consultoría
│   ├── service.schema.json
│   ├── service-order.schema.json
│   └── ...
├── SPEC.md               # Quick spec — referencia autocontenida para evaluadores
├── PROTOCOL.md           # Especificación completa
├── ERRORS.md             # Códigos de error del protocolo
├── WEBHOOKS.md           # Especificación de webhooks (borrador)
├── IMPLEMENTORS.md       # Guía para construir una implementación
├── GOVERNANCE.md         # Gobernanza de red y política de datos
└── README.md
VersiónEstado
Protocol0.9Estable
@servicialo/mcp-server0.8.0npm

Ecosystem


Licencia

Apache-2.0 — Servicialo es un protocolo abierto. Cualquiera puede implementarlo.

常见问题

io.github.danioni/servicialo 是什么?

面向 AI agents 的专业服务交付开放协议,用于标准化服务请求、协作与执行流程。

相关 Skills

网页构建器

by anthropics

Universal
热门

面向复杂 claude.ai HTML artifact 开发,快速初始化 React + Tailwind CSS + shadcn/ui 项目并打包为单文件 HTML,适合需要状态管理、路由或多组件交互的页面。

在 claude.ai 里做复杂网页 Artifact 很省心,多组件、状态和路由都能顺手搭起来,React、Tailwind 与 shadcn/ui 组合效率高、成品也更精致。

编码与调试
未扫描114.1k

前端设计

by anthropics

Universal
热门

面向组件、页面、海报和 Web 应用开发,按鲜明视觉方向生成可直接落地的前端代码与高质感 UI,适合做 landing page、Dashboard 或美化现有界面,避开千篇一律的 AI 审美。

想把页面做得既能上线又有设计感,就用前端设计:组件到整站都能产出,难得的是能避开千篇一律的 AI 味。

编码与调试
未扫描114.1k

网页应用测试

by anthropics

Universal
热门

用 Playwright 为本地 Web 应用编写自动化测试,支持启动开发服务器、校验前端交互、排查 UI 异常、抓取截图与浏览器日志,适合调试动态页面和回归验证。

借助 Playwright 一站式验证本地 Web 应用前端功能,调 UI 时还能同步查看日志和截图,定位问题更快。

编码与调试
未扫描114.1k

相关 MCP Server

GitHub

编辑精选

by GitHub

热门

GitHub 是 MCP 官方参考服务器,让 Claude 直接读写你的代码仓库和 Issues。

这个参考服务器解决了开发者想让 AI 安全访问 GitHub 数据的问题,适合需要自动化代码审查或 Issue 管理的团队。但注意它只是参考实现,生产环境得自己加固安全。

编码与调试
83.4k

by Context7

热门

Context7 是实时拉取最新文档和代码示例的智能助手,让你告别过时资料。

它能解决开发者查找文档时信息滞后的问题,特别适合快速上手新库或跟进更新。不过,依赖外部源可能导致偶尔的数据延迟,建议结合官方文档使用。

编码与调试
52.2k

by tldraw

热门

tldraw 是让 AI 助手直接在无限画布上绘图和协作的 MCP 服务器。

这解决了 AI 只能输出文本、无法视觉化协作的痛点——想象让 Claude 帮你画流程图或白板讨论。最适合需要快速原型设计或头脑风暴的开发者。不过,目前它只是个基础连接器,你得自己搭建画布应用才能发挥全部潜力。

编码与调试
46.3k

评论