Servicialo

Protocolo aberto para entrega de serviços profissionais. Agentes de IA podem descobrir, agendar, verificar e liquidar serviços profissionais.

GitHub

Experimente este MCPPatrocinado

Documentação

Servicialo

A camada de orquestação para a economia de serviços na era dos agentes de IA

Um protocolo aberto para coordenação de agenda, identidade, verificação
de entrega e liquidação financeira de serviços profissionais.

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

Sitio web ・ Especificação ・ Governança ・ MCP Server ・ npm

Novo no Servicialo? Comece aqui → SPEC.md

Spec completa (amigável para crawlers): https://servicialo.com/spec

Leia em inglês

Especificação do Protocolo

Para uma descrição formal da arquitetura, fluxos de mensagens e modelo de dados:

Whitepaper v0.9 — especificação formal do protocolo
Repositório do protocolo — schemas, RFCs e materiais de referência
PROTOCOL.md — especificação completa neste repositório

Unidades do Protocolo

O protocolo distingue primitivas de evento (SC, CAC) de modelos de billing (SC, CAC, RAC). Veja GLOSSARY.md para definições completas.

Por onde começo?

Tenho um negócio de serviços e quero que agentes de IA descubram e agendem meus serviços → Você precisa de uma plataforma compatível com o protocolo, não deste repositório. Coordinalo é a implementação de referência. À medida que o protocolo amadurecer, esperamos que surjam muitas outras plataformas compatíveis.

Sou um desenvolvedor que quer construir uma plataforma compatível com o protocolo → Continue lendo. Comece por IMPLEMENTING.md.

O problema

Sem um protocolo padrão, cada plataforma de serviços fala seu próprio idioma. Um agente de IA que quer agendar uma consulta médica, verificar um reparo doméstico ou cobrar uma consultoria jurídica precisa de uma integração diferente para cada uma. Os dados ficam em silos, a interoperabilidade exige integrações customizadas, e a inteligência coletiva sobre a entrega de serviços nunca se forma.

Servicialo é o protocolo comum. Define o esquema mínimo viável para que qualquer agente de IA coordene qualquer serviço profissional em qualquer plataforma compatível — sem integração adicional.

Primitivas do protocolo

Servicialo define quatro primitivas de coordenação. Juntas, cobrem a cadeia de valor completa da entrega de serviços profissionais:

Primitiva	O que resolve	Superfície do protocolo
Coordenação de agenda	Interseção de disponibilidade multi-parte (provedor, cliente, recurso) com tratamento de exceções	Ciclo de vida 6+3, 6 fluxos de exceção, scheduler de 3 variáveis
Verificação de identidade	Credenciais do provedor, pontuação de confiança, separação cliente-pagador	Credenciais do provedor, trust_score, separação payer_id
Liquidação financeira	Faturamento, cobrança, liquidação e revenue sharing com resolução de disputas	Dimensão de cobrança, ledger de Ordem de Serviço, payment_schedule
Sinais de demanda	Telemetria operacional anônima e agregada entre nós da rede	Extensão de Telemetria (modelo contribuir-para-acessar)

Cada primitiva é especificada de forma independente. As implementações adotam o que precisam.

O que é um serviço

Um serviço é uma promessa de transformação entregue em um momento e local específicos.

Diferente de um produto, um serviço não pode ser armazenado, revendido nem devolvido. Ele é consumido no momento em que é entregue. Isso o torna fundamentalmente diferente — e é por isso que precisa de seu próprio protocolo.

Um serviço nasce de três fontes:

Origem	Pergunta-chave	Exemplo
De um ativo	O que você tem que outros precisam?	Um apartamento vazio → hospedagem temporária
De uma vantagem	O que você sabe que outros não sabem?	Certificação em cinesiologia → reabilitação esportiva
Do seu tempo	O que você pode fazer que outros não querem ou não podem?	Horas disponíveis → limpeza profissional

As 8 dimensões

Todo serviço profissional — de uma sessão de cinesiologia a uma auditoria tributária — é modelado com as mesmas 8 dimensões:

	Dimensão	O que captura	Exemplo
1	O quê	A atividade ou resultado que é entregue	Sessão de cinesiologia, reparo elétrico
2	Quem entrega	O provedor do serviço, com credenciais	Cinesiologista certificado, eletricista SEC
3	Quem recebe	O cliente — com pagador separado explicitamente	Paciente (paga FONASA), funcionário (paga empresa)
4	Quando	Janela temporal acordada	2026-02-10 das 10:00 às 10:45
5	Onde	Local físico ou virtual, com `resource_id` opcional que referencia um Recurso físico (3.5b: sala, box, poltrona, equipamento)	Sala 3 da clínica, domicílio, videoconferência
6	Ciclo	Posição atual nas dimensões de estado (entrega, evidência, aceitação, liquidação)	Concluído · evidência registrada · cobrança pendente
7	Evidência	Como se comprova que o serviço ocorreu	GPS + duração + assinatura do cliente
8	Cobrança	Liquidação financeira, independente do ciclo	$35.000 CLP · cobrado · pacote pré-pago

O pagador nem sempre é o cliente. Na saúde, paga a seguradora. No corporativo, paga a empresa. Na educação, paga o responsável. O protocolo separa explicitamente o cliente do pagador — porque na vida real quase nunca são a mesma pessoa.

O ciclo de vida: 6 estados principais + 3 financeiros opcionais

O protocolo define estados independentes para observar o ciclo completo de uma coordenação. Os 9 marcos a seguir são o caminho feliz — a rota operacional mais comum, não uma sequência única obrigatória. Os 6 primeiros são obrigatórios; os 3 financeiros são uma extensão opcional. Entrega, evidência, aceitação e liquidação evoluem de forma independente (PROTOCOL.md §6.0):

Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → (opcional) Facturado → Cobrado → Verificado

#	Estado	O que ocorre
1	Solicitado	O cliente ou seu agente define o que precisa, quando e onde
2	Agendado	Atribui-se horário, provedor e local. O horário é bloqueado
3	Confirmado	Ambas as partes reconhecem o compromisso
4	Em Andamento	Registro de entrada detectado. O serviço está sendo entregue
5	Concluído	O provedor marca a entrega como completa
6	Documentado	Registro formal gerado: ficha clínica, relatório, ata
7	Faturado	Documento tributário emitido
8	Cobrado	Pagamento recebido e confirmado
9	Verificado	O cliente confirma — fechamento do ciclo

Verificado é o fechamento. O cliente não pode verificar até ter o quadro completo: a evidência documentada, a fatura emitida e a cobrança aplicada. Verificação prematura obriga o cliente a confirmar algo que ainda não tem registro formal.

As exceções são a regra

As exceções não são casos excepcionais. Ocorrem em 15–30% dos agendamentos. Um serviço bem projetado define o que acontece quando as coisas não saem conforme o plano:

Exceção	Transição	O que acontece
Não comparecimento do cliente	Confirmado → Cancelado	Aplica-se penalidade, libera-se o tempo do provedor
Não comparecimento do provedor	Confirmado → Reatribuindo → Agendado	Busca-se substituto automaticamente
Cancelamento	Qualquer pré-entrega → Cancelado	Aplica-se a política de cancelamento acordada
Disputa de qualidade	Concluído → Disputado	Congela-se a cobrança, solicita-se evidência
Reagendamento	Agendado/Confirmado → Reagendando → Agendado	Mantém-se o provedor se possível. Inclui conflitos de recurso (dupla reserva, recurso indisponível)
Entrega parcial	Em Andamento → Parcial	Documenta-se o que foi entregue, ajusta-se a fatura

Serviço e Ordem de Serviço

O protocolo é construído sobre dois objetos e sua relação:

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

A Service Delivery é a instância atômica executada — o que realmente ocorreu. No wire format atual, é representada pelo objeto Service (nome preservado por compatibilidade). A Ordem de Serviço é o acordo comercial que agrupa entregas sob um escopo, um preço e um esquema de pagamentos. "Serviço" por si só é o termo geral do domínio, não um quarto objeto.

Quando um Serviço pertence a uma Ordem, sua dimensão de cobrança é informativa — registra o valor econômico, mas não gera fatura. O faturamento é responsabilidade exclusiva da Ordem.

A mesma estrutura funciona para qualquer vertical:

Vertical	Exemplo	Escopo	Pagamentos
Saúde	Plano de cinesiologia	12 sessões	Por sessão
Consultoria	Contrato por horas	40 horas de assessoria jurídica	Mensal conforme consumo
Projetos	Auditoria prévia em 3 fases	Marcos definidos	Por marco aprovado

Evidência por vertical

Cada vertical define, por política, qual evidência comprova uma entrega. Os perfis a seguir são exemplos configuráveis — não requisitos universais do protocolo: cada acordo pode exigir evidências distintas, e a privacidade, a proporcionalidade e a regulação delimitam o que é adequado coletar. A comprovação resultante vale sob a política aplicada e com seu nível de certeza; não determina por si só a qualidade do serviço nem a verdade absoluta de cada afirmação. Sem ambiguidade — requisitos explícitos, previamente acordados, para produzir uma Prova de Serviço comprovável:

Saúde — 4 tipos de evidência

Evidência	Descrição	Captura
Registro de entrada	Marca temporal ao chegar e, quando aplicável, localização	automática
Registro de saída	Marca temporal ao sair e, quando aplicável, localização	automática
Ficha clínica assinada	Documentação ou atestação associada à entrega, quando a política aplicável exigir	manual
Adesão ao plano	Lista de verificação do plano de tratamento executado	manual

Regra de comprovação ilustrativa: Se as evidências que esta política exige — registros de entrada/saída e ficha assinada — estiverem presentes e forem válidas → a entrega é comprovada sob esta política, com seu nível de certeza. Se faltar ficha ou assinatura → escalar.

Lar — 4 tipos de evidência

Evidência	Descrição	Captura
Foto antes	Foto do estado inicial com marca temporal e GPS	manual
Foto depois	Foto do resultado final com marca temporal e GPS	manual
Lista de verificação	Tarefas acordadas marcadas como concluídas	manual
Assinatura do cliente	Assinatura digital do cliente confirmando recebimento	manual

Regra de comprovação ilustrativa: Se fotos antes/depois existirem com metadados válidos e lista completa → a entrega é comprovada sob esta política, com seu nível de certeza. Se faltar assinatura do cliente → escalar.

Jurídico — 3 tipos de evidência

Evidência	Descrição	Captura
Ata de reunião	Registro do que foi discutido e acordado	manual
Entrega de documentos	Confirmação de entrega dos documentos gerados	manual
Registro de horas	Horas faturáveis com descrição das atividades	manual
Regra de acreditação ilustrativa: Se a minuta existir e as horas registradas estiverem dentro do intervalo acordado → a entrega é acreditada sob esta política, com seu nível de certeza. Se as horas excederem o acordado sem justificativa → escalar.

Educação — 3 tipos de evidência

Evidência	Descrição	Captura
Registro de presença	Confirmação da presença do aluno e do professor	automática
Entrega de material	Material ou tarefas entregues ao aluno	manual
Avaliação	Avaliação ou feedback da sessão	manual

Regra de acreditação ilustrativa: Se a presença for registrada e o material entregue → a entrega é acreditada sob esta política, com seu nível de certeza. Se faltar a avaliação e o contrato a exigir → escalar.

Resolução de disputas — extensão em design

O módulo de disputas (Servicialo/Disputas) está em design — o fluxo a seguir descreve o design alvo, não uma capacidade operacional:

1. Abertura — Qualquer parte abre uma disputa dentro do prazo definido. O cobro é congelado automaticamente.

2. Revisão de evidência — Evidência adicional é solicitada de ambas as partes. O sistema compara a evidência registrada contra o contrato.

3. Resolução — Se o provedor vencer: Cobrado → Verificado. Se o cliente vencer: Cancelado com saldo restaurado.

Objetivo de design: automatizar a resolução dos casos cuja evidência satisfaz regras previamente acordadas no contrato. Os casos que a evidência não resolve seriam escalados para revisão humana; a arbitragem por pares do mesmo vertical é uma linha de pesquisa, não um mecanismo implantado.

Servidor MCP

Servicialo expõe suas ferramentas como um servidor MCP, permitindo que agentes de IA descubram e coordenem serviços profissionais de forma nativa.

Início rápido

O pacote @servicialo/mcp-server é um thin-client que conecta à API HTTP de uma plataforma compatível com Servicialo. Por padrão, aponta para Coordinalo (servicialo.com). Se você estiver construindo seu próprio backend, aponte para o seu com SERVICIALO_BASE_URL. Se você for uma organização usuária (clínica, consultoria, etc.), as credenciais são obtidas pela sua plataforma — você não precisa instalar este pacote diretamente.

npx -y @servicialo/mcp-server

Com isso, seu agente já pode buscar organizações, consultar disponibilidade e listar serviços — sem credenciais.

Modo autenticado

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

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

As credenciais são obtidas por cada organização na plataforma compatível com Servicialo que utiliza.

As fases do agente — 40 ferramentas

Um agente bem projetado segue esta ordem:

#	Fase	O que resolve	Ferramentas
0	Resolver	Onde está o endpoint	`resolve.lookup` · `resolve.search` · `trust.get_score`
1	Descobrir	O que está disponível	`registry.search` · `registry.get_organization` · `registry.manifest` · `scheduling.check_availability` · `services.list` · `a2a.get_agent_card`
2	Entender	Dimensões e regras do serviço	`service.get` · `contract.get`
3	Comprometer	Identidade do cliente e reserva	`clients.get_or_create` · `scheduling.book` · `scheduling.confirm`
4	Gerenciar	Estado e transições	`lifecycle.get_state` · `lifecycle.transition` · `scheduling.reschedule` · `scheduling.cancel`
5	Verificar	Evidência de que ocorreu	`delivery.checkin` · `delivery.checkout` · `delivery.record_evidence`
6	Fechar	Documentação e cobrança	`documentation.create` · `payments.create_sale` · `payments.record_payment` · `payments.get_status`
—	Recursos	Espaços físicos e equipamentos	`resource.list` · `resource.get` · `resource.create` · `resource.update` · `resource.delete` · `resource.get_availability`
—	Resolver admin	Portabilidade e telemetria	`resolve.register` · `resolve.update_endpoint` · `telemetry.heartbeat`
—	Inteligência de rede	Benchmarks de mercado anonimizados	`market.list_segments` · `market.get_benchmark`
—	Discovery (cold start)	Taxonomia sem conhecimento prévio — quais verticais, regiões e eventos existem	`registry.list_verticals` · `registry.list_regions` · `registry.list_event_types`

O servidor envia telemetria anônima na inicialização para estatísticas do protocolo. Pode ser desativado com SERVICIALO_TELEMETRY=false. Adicionalmente, servidores autenticados emitem telemetria operacional em buckets para alimentar os benchmarks de rede — opt-out com SERVICIALO_OPERATIONAL_TELEMETRY=false. Ver docs/telemetry-operational.md.

O protocolo garante que qualquer agente possa completar o ciclo completo com qualquer implementação compatível.

Exemplos completos

Sessão de cinesiologia — Vertical saúde. Registro de entrada com GPS, ficha clínica assinada, pagamento por transferência.

Reparo elétrico — Vertical casa. Visita domiciliar, fotos antes/depois, lista de verificação, assinatura do cliente, pagamento em dinheiro.

A2A Ready

Servicialo suporta A2A (Agent-to-Agent) como extensão opcional, permitindo que agentes externos (Salesforce Agentforce, Google ADK, etc.) descubram e reservem serviços sem passar pelo MCP.

Guia completo: docs/a2a-interoperability.md

Inteligência de rede — benchmarks de mercado

Cada nó que executa o servidor MCP autenticado emite eventos operacionais anonimizados (booking_created, service_completed, dispute_opened, payment_settled) com valores em buckets (preços em faixas, durações em intervalos, regiões em nível de país, fingerprint em vez de slug). O registry agrega esses eventos e publica distribuições por (vertical × região × evento) sob duas regras estritas:

k-anonimato ≥ 5 — um segmento é publicado somente se ≥ 5 organizações distintas contribuíram com dados.
Contribuir-para-acessar — nós que não fornecem telemetria veem dados com 90 dias de atraso; nós ativos contribuintes veem em tempo real. Sem nível pago.

Duas formas de consumir:

Pull — GET /api/benchmarks e GET /api/benchmarks/segments, ou as ferramentas MCP market.get_benchmark / market.list_segments.
Push — assinar o evento benchmark.weekly_snapshot via Webhooks API. O registry dispara um snapshot toda segunda-feira às 00:00 UTC com payload assinado por HMAC.

Detalhes: docs/benchmarks.md · docs/telemetry-operational.md · GOVERNANCE.md · WEBHOOKS.md

Os 7 princípios

#	Princípio
1	Todo serviço tem um ciclo	Não importa se é uma massagem ou uma auditoria. O protocolo define estados independentes para observar o ciclo completo: entrega, evidência, aceitação e liquidação.
2	A entrega deve ser verificável	Sem evidência suficiente, uma entrega não pode ser considerada acreditada com o nível de certeza exigido. O protocolo define o que constitui evidência válida para que humanos e agentes de IA possam confiar nela.
3	O pagador nem sempre é o cliente	Na saúde, paga a seguradora. No corporativo, paga a empresa. Na educação, paga o responsável. O protocolo separa explicitamente o cliente do pagador.
4	As exceções são a regra	Faltas, cancelamentos, reagendamentos, disputas. Um serviço bem projetado define o que acontece quando as coisas não saem conforme o plano.
5	Um serviço é um produto legível por máquinas	Tem nome, preço, duração, requisitos e resultado esperado. Definido assim, qualquer agente de IA pode descobri-lo, coordená-lo e fechá-lo com a mesma confiança que um humano.
6	O acordo é separado da entrega	A Ordem de Serviço define o acordado. O serviço atômico define o entregue. São dois objetos distintos com dois ciclos de vida distintos.
7	A inteligência coletiva é um bem comum do protocolo	Cada nó que implementa o protocolo contribui com dados operacionais. A inteligência agregada melhora todos os nós — como o Waze, onde cada motorista contribui e todos navegam melhor. Nenhuma implementação é dona dos dados da rede.

Arquitetura em camadas

Adote apenas o que você precisa. O Core cobre o ciclo completo de entrega. As extensões adicionam capacidades para operações especializadas.

Servicialo Core — `estable`

Tudo o que é necessário para modelar um serviço profissional do início ao fim.

Para qualquer plataforma onde duas partes assumem um compromisso de entrega e precisam de uma conta verificável do que ocorreu — desde uma sociedade de psicólogos até uma empresa de limpeza com múltiplas contas, equipes e pessoal.

Inclui: 8 dimensões · ciclo de vida 6+3 (6 estados core + 3 financeiros opcionais) · 6 fluxos de exceção · 7 princípios fundamentais · gestão de recursos · ordens de serviço · prova de entrega · protocolo MCP (40 ferramentas) · resolver de descoberta (análogo ao DNS, sobre HTTP) · interoperabilidade A2A · inteligência de rede (benchmarks em buckets com k-anonimato ≥5 e contribuir-para-acessar) · webhooks para distribuição push · descoberta de taxonomia sem conhecimento prévio (cold-start)

Servicialo/Finanças — `en diseño`

Distribuição de pagamentos entre profissional, organização e infraestrutura — com regras claras de liquidação.

Para plataformas que intermediam pagamentos entre clientes e profissionais, ou que cobram comissões.

Servicialo/Disputas — `en diseño`

Resolução formal de disputas. Objetivo de design: automatizar os casos cuja evidência satisfaz regras previamente acordadas; a arbitragem por pares do mesmo vertical é uma linha de pesquisa.

Para plataformas com volume suficiente ou onde o valor por serviço torna as disputas economicamente relevantes.

Schema

JSON Schemas para validação automática: schema/service.schema.json e schema/service-order.schema.json

# ─────────────────────────────────────────────
# 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      # 6 core + 3 financieros opcionales + excepciones
        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: proyección calculada desde entregas + términos comerciales +
# eventos de liquidación — nunca un saldo editable a mano

Implementações

Qualquer plataforma pode implementar Servicialo. Para ser listada, deve modelar as 8 dimensões, implementar os 6 estados core (os 3 financeiros são opcionais), lidar com pelo menos 3 dos 6 fluxos de exceção, aderir aos 7 princípios fundamentais e expor pelo menos um binding máquina a máquina que implemente os perfis Core (HTTP, MCP, A2A ou outro equivalente — uma implementação puramente HTTP é conforme sem MCP; MCP é a via recomendada para agentes). A verificação é manual hoje (PR + revisão da equipe); a suíte automatizada de certificação faz parte do roadmap.

Plataforma	Vertical	Cobertura	Estado
Coordinalo	Healthcare	8/8 dimensões · ciclo 6+3 completo · 6/6 exceções · 7/7 princípios	Live

Coordinalo é a implementação de referência — não o protocolo. O segundo nó é uma oportunidade aberta — ver IMPLEMENTORS.md.

Para implementadores

Guia passo a passo para construir uma plataforma compatível do zero — 8 passos, o primeiro leva 20 minutos. Comece aqui: IMPLEMENTING.md (English)

Referências adicionais:

schema/evidence/ — Schemas de evidência por vertical (saúde, casa, legal, educação, consultoria)
ERRORS.md — Códigos de erro do protocolo
WEBHOOKS.md — Notificações assíncronas de mudanças de estado (v0.2 — eventos do registry estáveis)

O que há neste repositório

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
│   └── ...
├── protocol/
│   └── manifest.yaml     # Fuente única de verdad: versión, tools, estados, extensiones
├── 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 (v0.2)
├── IMPLEMENTORS.md       # Guía para construir una implementación
├── GOVERNANCE.md         # Gobernanza de red y política de datos
└── README.md

	Versão	Estado
Protocol	0.10	Draft
@servicialo/mcp-server	0.9.13	npm

Ecossistema

Telemetria de rede — instalações do servidor MCP reportadas por telemetria (não equivale a implementações adotadas)
Implementadores — implementações verificadas do protocolo
Usando o Servicialo? Abra uma issue para ser listado

Licença

Apache-2.0 — Servicialo é um protocolo aberto. Qualquer pessoa pode implementá-lo.

Servicialo

Documentação

Servicialo

Especificação do Protocolo

Unidades do Protocolo

Por onde começo?

O problema

Primitivas do protocolo

O que é um serviço

As 8 dimensões

O ciclo de vida: 6 estados principais + 3 financeiros opcionais

As exceções são a regra

Serviço e Ordem de Serviço

Evidência por vertical

Resolução de disputas — extensão em design

Servidor MCP

Início rápido

Modo autenticado

As fases do agente — 40 ferramentas

Exemplos completos

A2A Ready

Inteligência de rede — benchmarks de mercado

Os 7 princípios

Arquitetura em camadas

Servicialo Core — estable

Servicialo/Finanças — en diseño

Servicialo/Disputas — en diseño

Schema

Implementações

Para implementadores

O que há neste repositório

Ecossistema

Licença

Servicialo Core — `estable`

Servicialo/Finanças — `en diseño`

Servicialo/Disputas — `en diseño`