# @servicialo/mcp-server

**The missing protocol layer for AI agents that coordinate professional services.**

There is no standard way for an AI agent to book, verify, and settle a professional service. Servicialo is an open protocol that fixes this — and this MCP server is its reference implementation. Think HTTP for service coordination: any agent, any platform, one protocol.

> **Protocol:** v0.10 (draft) · **Spec:** [servicialo.com/spec](https://servicialo.com/spec) · This package versions independently of the protocol (`0.9.x` until 1.0).

---

**Running a service business?**
You need a Servicialo-compatible platform, not this package directly. [Coordinalo](https://coordinalo.com) is the reference implementation — it implements this protocol so your services become discoverable and bookable by AI agents. As the protocol matures, we expect many more compatible platforms to emerge.

**Building a platform for service businesses?**
This is for you. Implement the protocol and any Servicialo-compatible agent connects to your backend automatically. See [Connecting to a custom implementation](#connecting-to-a-custom-implementation) and [`HTTP_PROFILE.md`](../../HTTP_PROFILE.md).

---

## Road to 1.0

The Servicialo protocol is entering its **stabilization phase**. The first formal RFC cohort is **open for comment** during a minimum 4-week window before moving to Final Comment Period. Until 1.0, releases remain `0.9.x` patch bumps and any breaking protocol change requires its RFC merged and prior communication.

- **RFC cohort (PR #13):** [servicialo/mcp-server#13](https://github.com/servicialo/mcp-server/pull/13)
- **1.0 process / discussion:** [servicialo/mcp-server#14](https://github.com/servicialo/mcp-server/discussions/14)

### Outstanding milestones toward 1.0

| Milestone | Status |
|---|---|
| RFC-001 — RFC Process & Deprecation Policy | Draft / Open for Comment |
| RFC-002 — Prepayment & Client Credit Balance | Draft / Open for Comment |
| RFC-003 — Refunds & Credit Notes (Forward-Only Ledger) | Draft / Open for Comment |
| RFC-004 — PII / PHI Classification Framework | Draft / Open for Comment |
| Stable Core declaration (8 dimensions · 6+3 lifecycle · 6 flows · 7 principles) with backwards-compatibility guarantees | Pending |
| ≥ 3 independent implementations in production | In progress |

## The Problem

AI agents can browse the web, write code, and hold conversations. But ask one to book a physiotherapy session, verify it happened, and process the payment — and it falls apart.

Today, every platform is a silo. There's no standard for:

- **Discovery** — which provider, in which organization, offers what I need?
- **Identity** — who is this agent acting for, and what is it authorized to do?
- **Lifecycle** — what state is this service in? Who confirmed? Who showed up?
- **Proof of delivery** — did the session actually happen? For how long? Where?
- **Settlement** — how much, to whom, under what contract terms?

Without a shared protocol, every integration is bespoke. Every agent-to-platform connection is a custom API. This doesn't scale.

## What is Servicialo

Servicialo is an **open protocol**, not a platform. It defines how professional services move through their lifecycle — from discovery to payment — in a way any AI agent or platform can implement.

The relationship is like HTTP to Apache, or SMTP to Gmail: Servicialo defines the rules, implementations bring them to life.

The protocol models every service across **8 dimensions**, a **6+3 lifecycle** (6 core states + 3 optional financial states), **6 exception flows**, and **7 core principles** that are universal across verticals — healthcare, legal, education, home services:

```
Requested → Scheduled → Confirmed → In Progress → Completed → Documented → Invoiced → Collected → Verified
```

Any service, in any vertical, follows this sequence. Vertical-specific logic lives *within* each state, but the state machine is invariant.

## What This MCP Server Does

This package exposes the Servicialo protocol as 40 MCP tools organized by the **7 lifecycle phases** (0–6, including the discovery resolver — analog to DNS, over HTTP), plus resource management, resolver administration, **network intelligence** (`market.*`), and **cold-start discovery** (`registry.list_*` for the agent to learn the taxonomy without prior knowledge). An agent doesn't call endpoints by database entity — it follows the natural flow of coordinating a service.

### Phase 0 — DNS Resolution (3 tools, no auth)

| Tool | Description |
|---|---|
| `resolve.lookup` | Resolve an orgSlug to its MCP/REST endpoint and trust level (equivalent to DNS lookup) |
| `resolve.search` | Search organizations registered in the global resolver by country and vertical |
| `trust.get_score` | Get trust score for an organization (score 0-100, level, last activity) |

### Phase 1 — Discovery (6 tools, no auth)

| Tool | Description |
|---|---|
| `registry.search` | Search organizations by vertical, location, country |
| `registry.get_organization` | Get public details: services, providers, booking config |
| `registry.manifest` | Get server manifest: capabilities, protocol version, organization metadata |
| `scheduling.check_availability` | Check available slots (3-variable: provider ∧ client ∧ resource) |
| `services.list` | List the public service catalog of an organization |
| `a2a.get_agent_card` | Get an organization's A2A Agent Card for inter-agent discovery |

### Phase 2 — Understand (2 tools)

| Tool | Description | Scopes |
|---|---|---|
| `service.get` | Get the 8 dimensions of a service | `service:read` |
| `contract.get` | Get contract terms: required evidence, cancellation policy, dispute window | `service:read` `order:read` |

### Phase 3 — Commit (3 tools)

| Tool | Description | Scopes |
|---|---|---|
| `clients.get_or_create` | Resolve client identity by email/phone — find or create in one call | `patient:write` |
| `scheduling.book` | Book a session → state `requested`. Optional `resource_id` for physical resources | `schedule:write` |
| `scheduling.confirm` | Confirm a booked session → state `confirmed` | `schedule:write` |

### Phase 4 — Lifecycle (4 tools)

| Tool | Description | Scopes |
|---|---|---|
| `lifecycle.get_state` | Get current state, available transitions, and history | `service:read` |
| `lifecycle.transition` | Execute a state transition with evidence | `service:write` |
| `scheduling.reschedule` | Reschedule to new datetime (contract policy may apply) | `schedule:write` |
| `scheduling.cancel` | Cancel session (contract cancellation policy applied) | `schedule:write` |

### Phase 5 — Verify Delivery (3 tools)

| Tool | Description | Scopes |
|---|---|---|
| `delivery.checkin` | Check-in with GPS + timestamp → state `in_progress` | `evidence:write` |
| `delivery.checkout` | Check-out with GPS + timestamp → state `delivered` (duration auto-calculated) | `evidence:write` |
| `delivery.record_evidence` | Record evidence: `gps`, `signature`, `photo`, `document`, `duration`, `notes` | `evidence:write` |

### Phase 6 — Close (4 tools)

| Tool | Description | Scopes |
|---|---|---|
| `documentation.create` | Generate service record (clinical note, inspection report, etc.) → state `documented` | `document:write` |
| `payments.create_sale` | Create charge for documented service → state `charged` | `payment:write` |
| `payments.record_payment` | Record payment received against a sale | `payment:write` |
| `payments.get_status` | Get payment status for a sale or client account balance | `payment:read` |

### Resource Management (6 tools)

| Tool | Description | Scopes |
|---|---|---|
| `resource.list` | List physical resources by organization | `resource:read` |
| `resource.get` | Get resource details with availability slots | `resource:read` |
| `resource.create` | Create a physical resource (room, box, equipment) | `resource:write` |
| `resource.update` | Update resource (patch semantics) | `resource:write` |
| `resource.delete` | Deactivate resource (soft delete: `is_active = false`) | `resource:write` |
| `resource.get_availability` | Check resource availability by date range | `resource:read` |

### Resolver Administration (3 tools)

| Tool | Description | Scopes |
|---|---|---|
| `resolve.register` | Register organization in the global resolver with MCP/REST endpoints | `resolve:write` |
| `resolve.update_endpoint` | Update registered endpoints (portability between backends) | `resolve:write` |
| `telemetry.heartbeat` | Send heartbeat to the resolver indicating the node is active | `telemetry:write` |

### Network Intelligence (2 tools, no auth)

Anonymized market benchmarks over operational telemetry contributed by network nodes. **Contribute-to-access** policy (k-anonymity ≥ 5):

| Tool | Description |
|---|---|
| `market.list_segments` | List segments `(event_type × vertical × region)` with available data (filtered by k-anon ≥ 5 distinct contributors) |
| `market.get_benchmark` | Get the bucket distribution of a segment (e.g. share of each `price_band` for `payment_settled` in `health/CL`). Tier 0/1 sees 90-day-delayed data; tier 2 (≥ 50 events in 30 days) sees real-time |

### Cold-start Discovery (3 tools, no auth)

The agent doesn't need to know the protocol taxonomy in advance. Start here when arriving without context:

| Tool | Description |
|---|---|
| `registry.list_verticals` | Verticals present in the network (declared by nodes + observed in telemetry over 30d) |
| `registry.list_regions` | Countries/regions (ISO 3166-1 alpha-2) with activity in the network |
| `registry.list_event_types` | Catalog of the 4 operational telemetry event types + their `payload_fields` |

### Documentation (1 tool, no auth)

| Tool | Description |
|---|---|
| `docs.quickstart` | Get the 5 quickstart steps as structured JSON — agent onboarding without prior context |

## Installation & Quickstart

### Option 1: Discovery mode (zero config)

```bash
npx -y @servicialo/mcp-server
```

No API key. No org ID. 15 public tools available immediately (resolver + discovery + market benchmarks + cold-start discovery). Try it:

```json
{
  "tool": "registry.search",
  "arguments": {
    "vertical": "kinesiologia",
    "location": "santiago"
  }
}
```

### Option 2: Full mode (authenticated)

```bash
SERVICIALO_API_KEY=your_key SERVICIALO_ORG_ID=your_org npx -y @servicialo/mcp-server
```

All 40 tools unlocked (15 public + 25 authenticated).

### Claude Desktop / Cursor / any MCP client

Add to your MCP configuration:

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

Omit the `env` block for discovery-only mode.

### Environment Variables

**Core:**

| Variable | Required | Default | Description |
|---|---|---|---|
| `SERVICIALO_API_KEY` | No | — | Bearer token. Enables authenticated mode (25 additional tools = 40 total) |
| `SERVICIALO_ORG_ID` | No | — | Organization slug. Enables authenticated mode |
| `SERVICIALO_BASE_URL` | No | `http://localhost:3000` | API endpoint of the Servicialo-compatible platform |
| `SERVICIALO_ADAPTER` | No | `coordinalo` | Backend adapter: `coordinalo` or `http` |
| `SERVICIALO_TELEMETRY` | No | `true` | Set to `false` to disable anonymous node-init telemetry (heartbeat) |

Both `SERVICIALO_API_KEY` and `SERVICIALO_ORG_ID` must be set together. If only one is present, the server falls back to discovery mode with a warning.

**Operational telemetry + benchmarks (optional):**

Enable your node to contribute anonymized bucketed events to network benchmarks and access real-time data (tier 2). See [docs/telemetry-operational.md](https://github.com/servicialo/mcp-server/blob/main/docs/telemetry-operational.md):

| Variable | Required | Default | Description |
|---|---|---|---|
| `SERVICIALO_VERTICAL` | No | `unspecified` | Your vertical (e.g. `health`, `legal`, `home`). Required so emitted events aggregate into the right segment |
| `SERVICIALO_REGION` | No | `CL` | ISO 3166-1 alpha-2 country code |
| `SERVICIALO_NODE_TOKEN` | No | — | Your node's `ownership_token` from the registry. Sent as `X-Servicialo-Node-Token` header on `market.*` calls to identify tier (tier 2 = real-time access) |
| `SERVICIALO_OPERATIONAL_TELEMETRY` | No | `true` | Set to `false` to disable automatic emission of operational events (booking_created, service_completed, dispute_opened, payment_settled) |
| `SERVICIALO_PROTOCOL_VERSION` | No | `0.9` | Protocol version declared in emitted events |
| `SERVICIALO_TELEMETRY_BASE_URL` | No | `https://servicialo.com` | Operational telemetry receiver endpoint (change only for testing) |

> **How it relates to benchmark tiers:** a node that emits ≥ 50 operational events in 30 days automatically reaches tier 2, and `market.get_benchmark` returns real-time data (instead of the default 90-day-delayed view). Full policy: [GOVERNANCE.md#contribute-to-access-policy-v01](https://github.com/servicialo/mcp-server/blob/main/GOVERNANCE.md#contribute-to-access-policy-v01).

## Connecting to a custom implementation

This MCP server supports any Servicialo-compatible backend through its pluggable adapter layer. Two adapters are included:

- **`coordinalo`** (default) — connects to a Coordinalo/Digitalo backend with org-scoped routes under `/api/organizations/{orgId}`.
- **`http`** — connects to any implementation that exposes the canonical `HTTP_PROFILE.md` endpoints under `/v1/*`.

### 3 steps to connect your implementation

**Step 1.** Implement the REST endpoints defined in [`HTTP_PROFILE.md`](../../HTTP_PROFILE.md) in your platform.

**Step 2.** Configure the MCP server to use the HTTP adapter:

```bash
SERVICIALO_ADAPTER=http \
SERVICIALO_BASE_URL=https://your-platform.com \
SERVICIALO_API_KEY=your_key \
npx -y @servicialo/mcp-server
```

**Step 3.** Add to your MCP client configuration:

```json
{
  "mcpServers": {
    "servicialo": {
      "command": "npx",
      "args": ["-y", "@servicialo/mcp-server"],
      "env": {
        "SERVICIALO_ADAPTER": "http",
        "SERVICIALO_BASE_URL": "https://your-platform.com",
        "SERVICIALO_API_KEY": "your_api_key",
        "SERVICIALO_ORG_ID": "your_org_id"
      }
    }
  }
}
```

The HTTP adapter translates internal paths to canonical `/v1/*` endpoints and sends the organization context via the `X-Servicialo-Org` header. See `HTTP_PROFILE.md` for the full REST contract.

## Delegated Agency Model

The protocol treats AI agents as first-class actors — but never trusts them implicitly. Every agent action requires a **ServiceMandate**: an explicit delegation of capability from a human principal to an agent.

### How it works

1. A human (professional, patient, or organization) issues a mandate to an agent
2. The mandate specifies **who** the agent acts for, **what** it can do (scopes), and **for how long**
3. On every tool call, the MCP server validates the mandate against 8 checks before executing
4. Every action produces an audit entry — success or failure

### Mandate example

```json
{
  "mandate_id": "550e8400-e29b-41d4-a716-446655440000",
  "principal_id": "dr_barbara",
  "principal_type": "professional",
  "agent_id": "agent_scheduling_bot",
  "agent_name": "Booking Assistant",
  "acting_for": "professional",
  "context": "org:clinica-kinesia",
  "scopes": ["schedule:read", "schedule:write", "patient:write"],
  "constraints": {
    "max_actions_per_day": 50,
    "allowed_hours": {
      "start": "08:00",
      "end": "20:00",
      "timezone": "America/Santiago"
    },
    "require_confirmation_above": {
      "amount": 100000,
      "currency": "CLP"
    }
  },
  "issued_at": "2026-03-01T00:00:00Z",
  "expires_at": "2026-06-01T00:00:00Z",
  "status": "active"
}
```

### Using mandates in tool calls

When `actor.type` is `"agent"`, include the `mandate_id`:

```json
{
  "tool": "scheduling.book",
  "arguments": {
    "service_id": "srv_123",
    "provider_id": "prov_111",
    "client_id": "cli_789",
    "starts_at": "2026-03-03T10:00:00",
    "actor": {
      "type": "agent",
      "id": "agent_scheduling_bot",
      "mandate_id": "550e8400-e29b-41d4-a716-446655440000"
    }
  }
}
```

### The 8 validation checks

Every agent tool call is validated against:

| # | Check | What it prevents |
|---|---|---|
| 1 | **Status** — mandate must be `active` | Using revoked or expired mandates |
| 2 | **Temporal validity** — `issued_at ≤ now < expires_at` | Time-based attacks |
| 3 | **Agent identity** — `mandate.agent_id === requesting agent` | Agent impersonation |
| 4 | **Scope coverage** — mandate scopes cover the tool's requirements | Privilege escalation |
| 5 | **Context match** — mandate context matches the request | Cross-org data access |
| 6 | **Conflict of interest** — agent can't act for both sides | Dual-agency violations |
| 7 | **Constraints** — allowed hours, daily limits, financial thresholds | Over-autonomous agents |
| 8 | **Audit** — every action logged with sanitized inputs | Non-repudiation |

Non-agent actors (`client`, `provider`, `organization`) bypass mandate validation entirely.

## Provider Discovery

Agents can search the registry and match providers to a patient's needs using structured queries.

### Search the registry

```json
{
  "tool": "registry.search",
  "arguments": {
    "vertical": "kinesiologia",
    "location": "santiago",
    "country": "cl"
  }
}
```

Returns matching organizations with their services and providers.

### Check availability

```json
{
  "tool": "scheduling.check_availability",
  "arguments": {
    "org_slug": "clinica-kinesia",
    "service_id": "srv_pelvic_rehab",
    "provider_id": "prov_111",
    "date_from": "2026-03-10",
    "date_to": "2026-03-14"
  }
}
```

The 3-variable scheduler checks availability across provider, client, and physical resource simultaneously.

### End-to-end example

```
1. registry.search({ vertical: "kinesiologia", location: "santiago" })
   → finds org "clinica-kinesia"

2. services.list({ org_slug: "clinica-kinesia" })
   → lists available services

3. scheduling.check_availability({ org_slug: "clinica-kinesia", date_from: "2026-03-10", date_to: "2026-03-14" })
   → returns available slots

4. contract.get({ service_id: "srv_123", org_id: "org_456" })
   → cancellation: 0% if >24h, 50% if 2-24h, 100% if <2h
   → required evidence: check_in + check_out + clinical_record

5. clients.get_or_create({ email: "maria@mail.com", name: "Maria", last_name: "Lopez" })
   → client_id: "cli_789"

6. scheduling.book({ service_id: "srv_123", provider_id: "prov_111", client_id: "cli_789", starts_at: "2026-03-12T10:00:00" })
   → session_id: "ses_001", state: "requested"

7. scheduling.confirm({ session_id: "ses_001" })
   → state: "confirmed"

8. delivery.checkin({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
   → state: "in_progress"

9. delivery.checkout({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
   → state: "delivered", duration: 42min

10. documentation.create({ session_id: "ses_001", content: "Pelvic floor rehabilitation session..." })
    → state: "documented"

11. payments.create_sale({ client_id: "cli_789", service_id: "srv_123", unit_price: 35000 })
    → sale_id: "sale_001", state: "charged"

12. lifecycle.transition({ session_id: "ses_001", to_state: "verified" })
    → state: "verified" ✓
```

## Protocol Specification

The full Servicialo protocol specification is available at:

- **Repository:** [github.com/servicialo/protocol](https://github.com/servicialo/protocol)
- **Website:** [servicialo.com](https://servicialo.com)
- **Current stable version:** 0.9
- **JSON Schemas:** [`service.schema.json`](https://github.com/servicialo/protocol/blob/main/schema/service.schema.json), [`service-order.schema.json`](https://github.com/servicialo/protocol/blob/main/schema/service-order.schema.json), [`service-mandate.schema.json`](https://github.com/servicialo/protocol/blob/main/schema/service-mandate.schema.json)

The spec covers the 8 dimensions, the 6+3 lifecycle, 6 exception flows (no-show, cancellation, dispute, reschedule, partial delivery), 7 core principles, the two-entity architecture (atomic Service + Service Order), the Delegated Agency Model, DNS resolution, and A2A interoperability.

## Reference Implementation

**Digitalo** is the first production implementation of the Servicialo protocol, operating in healthcare in Chile. It implements the full lifecycle — from provider discovery through payment settlement — and serves as the validation ground for protocol evolution.

This MCP server connects to any Servicialo-compatible backend via `SERVICIALO_BASE_URL`. Digitalo is one such backend. The protocol is designed so that any CRM, EHR, or platform can implement it as a sovereign node.

## Contributing to the Protocol

Servicialo follows semantic versioning for the protocol specification:

- **Patch** (0.7.x) — clarifications, typo fixes, non-breaking additions
- **Minor** (0.x.0) — new optional fields, new tool definitions, new exception flows
- **Major** (x.0.0) — breaking changes to schemas, state machine, or core semantics

### How to propose changes

1. Open an issue describing the problem and your proposed solution
2. For significant changes, write an RFC in `spec/` with the section number it affects
3. Protocol changes require at least one reference implementation before merging
4. Schema changes must include updated JSON Schema files and Zod types in the MCP server

### Areas actively seeking input

- Vertical-specific evidence requirements (beyond healthcare)
- Multi-language support for lifecycle state names
- Inter-node federation (how two Servicialo implementations interoperate)
- Agent SDK patterns for Python and TypeScript

## Telemetry

On startup, the MCP server sends a single anonymous POST to `https://servicialo.com/api/telemetry/instance` with:

```json
{
  "event": "node_initialized",
  "version": "0.9.8",
  "node_id": "a1b2c3d4-...",
  "ts": 1711300000000
}
```

| Field | Description |
|---|---|
| `event` | Always `"node_initialized"` |
| `version` | Package version |
| `node_id` | Persistent UUID stored at `~/.servicialo/node_id` |
| `ts` | Timestamp in milliseconds |

**That is everything that gets sent.** No organization info, API keys, patient data, or personal identifiers are transmitted. The IP is hashed (SHA-256) server-side before storage. The ping is fire-and-forget: if it fails, the error is silently discarded and never blocks server operation.

On first run with telemetry enabled, the server prints a notice to stderr explaining what is sent and how to opt out.

### Disable telemetry

```bash
SERVICIALO_TELEMETRY=false npx -y @servicialo/mcp-server
```

Or in MCP configuration:

```json
{
  "env": {
    "SERVICIALO_TELEMETRY": "false"
  }
}
```

More details: [servicialo.com/network](https://servicialo.com/network)

## Join the network

When you install `@servicialo/mcp-server`, your node automatically registers with the [network telemetry](https://servicialo.com/network). This helps the ecosystem measure real protocol adoption — without collecting personal or client data.

Telemetry reports only: package version, a persistent node UUID, and an IP hash (for approximate geolocation — IPs are not stored). You can disable it at any time with `SERVICIALO_TELEMETRY=false`.

## Startup notices

The server writes two informational notices to **stderr** — never to stdout, which carries JSON-RPC and is corrupted by anything else:

- **The RFC-005 comment window**, while it is open. Expiry is built in: it stops printing after 2026-09-13, the close of the final comment period, so a node installed in October is not greeted by a dead announcement.
- **If your node is anonymous**, how to identify it (below).

Both print once per process and are silenced with `SERVICIALO_QUIET=true`:

```json
{
  "env": {
    "SERVICIALO_QUIET": "true"
  }
}
```

That variable affects **only these two notices**. The mode banner and the first-run telemetry notice keep their previous behavior.

## Identify your node

Your node is anonymous by default: the ping carries event, version, `node_id` and timestamp, and nothing else. If you operate your own implementation of the protocol, these three optional variables identify it and apply for **verified implementor** status:

```bash
SERVICIALO_IMPL_NAME="My Platform"          # Name of your implementation
SERVICIALO_IMPL_URL="https://example.com"   # Your website or repository
SERVICIALO_IMPL_CONTACT="admin@example.com" # Contact email — hashed before it leaves
```

### What leaves your machine under each variable

| Variable | What travels | What does not |
|---|---|---|
| `SERVICIALO_IMPL_NAME` | The name in plain text, as `impl_name`. It is public: rendered on `/implementors` once verified. | — |
| `SERVICIALO_IMPL_URL` | The URL in plain text, as `impl_url`. Also public once verified. | — |
| `SERVICIALO_IMPL_CONTACT` | Only `impl_contact_hash`: the SHA-256 of the lowercased, trimmed email, computed **on your machine** before any network request. | The email itself. It does not leave the host, is not logged, is not stored, and is never displayed. |

With none of them set, none of these fields appear in the ping. An unconfigured node behaves exactly as it did before this release.

### The verification cycle

`anonymous` → `pending` → `verified`

1. **`anonymous`** — no variables set. This is the default, and an anonymous node is fully conformant.
2. **`pending`** — the first time a new `impl_name` appears, the record is marked pending and the team is notified with the name, the URL and the country. The contact hash is not in that notification, and could not be: it would serve no purpose there.
3. **`verified`** — after manual review against the conformance checklist, your implementation appears at [servicialo.com/implementors](https://servicialo.com/implementors) with its tier and the number of hosts it reports.

Verification is manual today. The automated conformance suite is on the roadmap; it is not a current capability.

**What the contact hash is for — and what it is not.** It is a one-way digest: nobody can write to you from it, and setting it does not subscribe you to any announcement or list. It serves the reverse — when *you* write in about your implementation, the hash of your email confirms you are the operator who sent those pings.

### How to stop sending it

Remove the variables from your MCP configuration (or `unset SERVICIALO_IMPL_NAME SERVICIALO_IMPL_URL SERVICIALO_IMPL_CONTACT`) and restart the server. The next ping is anonymous again, with no identity fields at all. Pings already sent keep what they sent; to request removal of existing records, open an issue on the [repository](https://github.com/servicialo/mcp-server/issues).

### Adjacent capability: weekly snapshots

The registry emits `benchmark.weekly_snapshot` every Monday at 00:00 UTC to subscribed endpoints, with an HMAC-SHA256 signed payload. **These three variables do not enable it.** It requires a registry entry and an explicit subscription through the [Webhooks API](https://github.com/servicialo/mcp-server/blob/main/WEBHOOKS.md), and it delivers benchmark data, not protocol announcements.

## License

Apache-2.0 — any implementation, commercial or otherwise, is welcome. See [LICENSE](./LICENSE).