Servicialo MCP Server

@servicialo/mcp-server

Servicialo 標準のプロトコルレベル MCP インターフェース — AI エージェント時代における人間向けサービスの宛先レイヤーです。 HTTP によってドキュメントがアドレス指定可能になりました。Servicialo によってサービスがアドレス指定可能になります。MCP と A2A はトランスポートです。Servicialo はエージェントが到達する宛先です。

このパッケージは、Servicialo 互換のあらゆるバックエンドに対応するプロトコルレベル MCP インターフェースであり、特定プラットフォーム用のコネクターではありません。Coordinalo はリファレンス実装（かつデフォルト）ですが、独自のバックエンドを接続できます。

プロトコル： v0.10（draft） · 仕様： servicialo.com/spec · このパッケージのバージョンはプロトコルとは独立しています（1.0 までは 0.9.x）。

1.0 への道のり

Servicialo プロトコルは安定化段階に入ります。最初の正式な RFC 群は、Final Comment Period に進む前の最低 4 週間、コメントを募集中です。1.0 までは、リリースは引き続き 0.9.x のパッチリリースとなり、プロトコルに破壊的変更を加えるには、RFC のマージと事前告知が必要です。

• RFC 群（PR #13）： servicialo/mcp-server#13
• 1.0 プロセス／ディスカッション： servicialo/mcp-server#14

1.0 に向けた未完了のマイルストーン

マイルストーン	状態
RFC-001 — RFC プロセスと非推奨ポリシー	Draft / Open for Comment
RFC-002 — 前払いとクライアントのクレジット残高	Draft / Open for Comment
RFC-003 — 返金とクレジットノート（追記専用台帳）	Draft / Open for Comment
RFC-004 — PII / PHI 分類フレームワーク	Draft / Open for Comment
後方互換性の保証を伴う、安定版 Core の宣言（8 つの次元・6+3 サイクル・6 つのフロー・7 つの原則）	未着手
本番環境での独立した実装 ≥ 3 件	進行中

アーキテクチャ

@servicialo/mcp-server  →  interfaz MCP a nivel de protocolo
        ↓ se conecta a cualquier backend compatible con Servicialo
Coordinalo              →  implementación de referencia (default)
Tu implementación       →  trae tu propio backend

課題

AI エージェントはウェブを閲覧し、コードを書き、会話を続けられます。しかし、運動療法の予約を取り、実施されたことを確認し、支払いを処理するよう頼むと、うまくいきません。

現在、各プラットフォームはサイロ化しています。次の項目に関する標準はありません。

• 発見 — どの組織のどのサービス提供者が、必要なサービスを提供しているのか？
• アイデンティティ — このエージェントは誰の代理として行動し、何をする権限があるのか？
• ライフサイクル — このサービスはどの状態にあるのか？誰が確認したのか？誰が参加したのか？
• 提供の証明 — セッションは実際に行われたのか？どのくらいの時間か？どこで行われたのか？
• 精算 — 金額はいくらで、誰に、どの契約条件で支払うのか？

共有プロトコルがなければ、あらゆる統合は個別対応になります。エージェントとプラットフォームの接続はすべて独自 API になります。これでは拡張できません。

Servicialo とは

Servicialo はプラットフォームではなく、オープンプロトコルです。専門サービスが発見から支払いまでのライフサイクルをたどる方法を定義し、あらゆる AI エージェントやプラットフォームが実装できるようにします。

その関係は、Apache に対する HTTP や Gmail に対する SMTP と同じです。Servicialo がルールを定義し、実装がそれを実現します。

このプロトコルでは、各サービスを8 つの次元、6+3 のライフサイクル（コア状態 6 つ＋任意の財務状態 3 つ）、6 つの例外フロー、7 つの基本原則を通じてモデル化します。これらは医療、法律、教育、在宅サービスなど、あらゆる業種に共通です。

Solicitado → Agendado → Confirmado → En Curso → Completado → Documentado → Facturado → Cobrado → Verificado

あらゆる業種のあらゆるサービスが、このシーケンスに従います。業種固有のロジックは各状態の中にありますが、状態機械は不変です。

この MCP サーバーでできること

このパッケージは、サービスのライフサイクルにおける7 つのフェーズ（0～6。HTTP 経由で DNS に相当するディスカバリーリゾルバーを含む）ごとに整理された 40 個の MCP ツールとして、Servicialo プロトコルを公開します。さらに、リソース管理、リゾルバーの管理、ネットワークインテリジェンス（market.*）、コールドスタート時のディスカバリー（事前に分類体系を知らなくても把握できる registry.list_*）にも対応しています。エージェントはデータベースのエンティティごとにエンドポイントを呼び出すのではなく、サービスを調整する自然なフローに沿って処理します。

フェーズ 0 — DNS 解決（3 ツール、認証不要）

ツール	説明
resolve.lookup	orgSlug を MCP／REST エンドポイントと信頼レベルに解決します（DNS ルックアップに相当）
resolve.search	グローバルリゾルバーで、国と業種を指定して登録済みの組織を検索します
trust.get_score	組織の信頼スコア（スコア 0～100、レベル、最終アクティビティ）を取得します

フェーズ 1 — ディスカバリー（6 ツール、認証不要）

ツール	説明
registry.search	業種、所在地、国を指定して組織を検索します
registry.get_organization	サービス、提供者、予約設定などの公開情報を取得します
registry.manifest	サーバーマニフェスト（機能、プロトコルバージョン、組織のメタデータ）を取得します
scheduling.check_availability	予約可能状況を確認します（3 つの変数：提供者 ∧ クライアント ∧ リソース）
services.list	組織の公開サービスカタログを一覧表示します
a2a.get_agent_card	エージェント間のディスカバリー用に、組織の A2A Agent Card を取得します

フェーズ 2 — 内容の把握（2 ツール）

ツール	説明	スコープ
service.get	サービスの 8 つの側面を取得します	service:read
contract.get	契約条件（必要な証拠、キャンセルポリシー、異議申し立て期間）を取得します	service:read order:read

フェーズ 3 — 確約（3 ツール）

ツール	説明	スコープ
clients.get_or_create	メールアドレス／電話番号でクライアントの ID を解決します。1 回の呼び出しで検索または作成できます	patient:write
scheduling.book	セッションを予約し、状態を solicitado にします。物理的なリソースには resource_id を指定できます（省略可）	schedule:write
scheduling.confirm	予約済みセッションを確定し、状態を confirmado にします	schedule:write

フェーズ 4 — ライフサイクル（4 ツール）

ツール	説明	スコープ
lifecycle.get_state	現在の状態、可能な状態遷移、履歴を取得します	service:read
lifecycle.transition	証拠を添えて状態遷移を実行します	service:write
scheduling.reschedule	新しい日時に予約を変更します（契約のポリシーが適用される場合があります）	schedule:write
scheduling.cancel	セッションをキャンセルします（契約のキャンセルポリシーが適用されます）	schedule:write

フェーズ 5 — 提供の検証（3 ツール）

ツール	説明	スコープ
delivery.checkin	GPS とタイムスタンプを使ってチェックインし、状態を en_curso にします	evidence:write
delivery.checkout	GPS とタイムスタンプを使ってチェックアウトし、状態を entregado にします（所要時間は自動計算）	evidence:write
delivery.record_evidence	gps、firma、foto、documento、duración、notas などの証拠を記録します	evidence:write

フェーズ 6 — 完了（4 ツール）

ツール	説明	スコープ
documentation.create	サービス記録（診療記録、点検報告書など）を生成し、状態を documentado にします	document:write
payments.create_sale	記録済みサービスの請求を作成し、状態を cobrado にします	payment:write
payments.record_payment	売上に対して受領した支払いを記録します	payment:write
payments.get_status	売上の支払い状況またはクライアントのアカウント残高を取得します	payment:read

リソース管理（6 ツール）

ツール	説明	スコープ
resource.list	組織の物理リソースを一覧表示する	resource:read
resource.get	利用可能なスロットを含むリソースの詳細を取得する	resource:read
resource.create	新しい物理リソース（部屋、ボックス、設備）を作成する	resource:write
resource.update	リソースを更新する（セマンティックパッチ）	resource:write
resource.delete	リソースを無効化する（ソフトデリート：is_active = false）	resource:write
resource.get_availability	日付範囲を指定してリソースの空き状況を確認する	resource:read

Resolver の管理（3 ツール）

ツール	説明	スコープ
resolve.register	MCP/REST エンドポイントを指定して、グローバル Resolver に組織を登録する	resolve:write
resolve.update_endpoint	登録済みエンドポイントを更新する（バックエンド間のポータビリティ）	resolve:write
telemetry.heartbeat	ノードがアクティブであることを示すハートビートを Resolver に送信する	telemetry:write

ネットワークインテリジェンス（2 ツール、認証不要）

ノードから提供された運用テレメトリに基づく、匿名化された市場ベンチマークです。貢献してアクセスするポリシー（k-匿名性 ≥ 5）：

ツール	説明
market.list_segments	利用可能なデータがあるセグメント (event_type × vertical × region) を一覧表示する（異なるコントリビューターが 5 以上の k-匿名性条件で絞り込む）
market.get_benchmark	セグメントのバケット分布を取得する（例：health/CL における payment_settled の各 price_band の割合）。ティア 0/1 では 90 日遅れのデータを表示し、ティア 2（30 日間に 50 件以上のイベント）ではリアルタイムで表示します

タクソノミーのディスカバリー（3 ツール、認証不要）

コールドスタート：エージェントは事前にプロトコルのタクソノミーを知っている必要はありません。コンテキストがない状態でアクセスした場合は、ここから始めてください。

ツール	説明
registry.list_verticals	ネットワーク内に存在する業種（宣言済み、および過去 30 日間のテレメトリで観測されたもの）
registry.list_regions	ネットワーク内でアクティビティのある ISO 3166-1 alpha-2 の国／地域
registry.list_event_types	4 種類の運用テレメトリイベントと、それらの payload_fields のカタログ

ドキュメント（1 ツール、認証不要）

ツール	説明
docs.quickstart	クイックスタートの 5 つの手順を、構造化 JSON として取得する — 事前コンテキストがないエージェントのオンボーディング用

クイックスタート — ネットワークに参加するための 5 つの手順

手順 1. MCP サーバーをインストールする

npx -y @servicialo/mcp-server

ディスカバリーモード — 公開ツール 15 個、認証情報不要。今すぐお試しください：

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

手順 2. 組織を作成する

coordinalo.com/signup で組織を登録します。Coordinalo は、Servicialo プロトコルのリファレンス実装です。

手順 3. MCP 認証情報を取得する

Coordinalo で、Settings → Servicialo → Generar credenciales MCP を選択します。次の 2 つの値を取得できます。

• SERVICIALO_ORG_ID — 組織のスラッグ（例：clinica-dental-sur）
• SERVICIALO_API_KEY — 認証用のベアラートークン

手順 4. MCP クライアントを設定する

Claude Desktop、Cursor、または任意の MCP クライアントの設定に追加します。

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

env ブロックを省略すると、ディスカバリー専用モード（公開ツール 15 個）になります。

手順 5. Servicialo ネットワークに公開する

Coordinalo で、Settings → Servicialo → Publicar を選択します。組織が servicialo.com/network に表示され、他のエージェントから見つけられるようになります。

ヒント： エージェントは docs.quickstart ツールを呼び出すことで、この 5 つの手順を構造化 JSON として取得できます。

Red / ネットワーク

Servicialo ネットワークは、このプロトコルを実装する組織のグローバルレジストリです。認証済みノードは定期的にハートビートを送信し、任意のエージェントが国、分野、信頼スコアで組織を検索できます。

• ネットワークを探索： servicialo.com/network
• 分野で検索： registry.search({ vertical: "kinesiologia", country: "cl" })
• 組織を解決： resolve.lookup({ org_slug: "clinica-dental-sur" })

認証情報

必須項目

変数	必須	デフォルト	説明
SERVICIALO_API_KEY	いいえ	—	ベアラートークンです。認証モードを有効にします（追加ツール 25 個、合計 40 個）
SERVICIALO_ORG_ID	いいえ	—	組織のスラッグです。認証モードを有効にします
SERVICIALO_BASE_URL	いいえ	http://localhost:3000	Servicialo 互換プラットフォーム API のエンドポイントです
SERVICIALO_ADAPTER	いいえ	coordinalo	バックエンドアダプター：coordinalo または http
SERVICIALO_TELEMETRY	いいえ	true	ノードの匿名テレメトリ（ハートビート）を無効にするには false に設定します

SERVICIALO_API_KEY と SERVICIALO_ORG_ID はセットで設定する必要があります。一方だけが設定されている場合、サーバーは警告を出して検出モードに切り替わります。

運用テレメトリとベンチマーク（任意）

これらの変数を設定すると、ノードが匿名化されたイベントをネットワークのベンチマークに提供し、リアルタイムデータ（ティア 2）にアクセスできるようになります。docs/telemetry-operational.md を参照してください。

変数	必須	デフォルト	説明
SERVICIALO_VERTICAL	いいえ	unspecified	分野です（例：health、legal、home）。イベントを適切なセグメントに集計するために必要です
SERVICIALO_REGION	いいえ	CL	運用国の ISO 3166-1 alpha-2 コードです。イベントにはこの値がタグ付けされます
SERVICIALO_NODE_TOKEN	いいえ	—	レジストリ内のノードの ownership_token です。ティアを識別するため、market.* の呼び出しで X-Servicialo-Node-Token ヘッダーとして送信されます（リアルタイムアクセスを含むティア 2）
SERVICIALO_OPERATIONAL_TELEMETRY	いいえ	true	運用イベント（booking_created、service_completed、dispute_opened、payment_settled）の自動送信を無効にするには false に設定します
SERVICIALO_PROTOCOL_VERSION	いいえ	0.9	送信イベントで宣言されるプロトコルバージョンです
SERVICIALO_TELEMETRY_BASE_URL	いいえ	https://servicialo.com	運用テレメトリの受信エンドポイントです（テスト時以外は変更しないでください）

ベンチマークのティアとの関係： 30 日間に運用イベントを 50 件以上送信したノードは、自動的にティア 2 に到達し、market.get_benchmark はリアルタイムデータを返します（デフォルトのティア 0／1 のように 90 日遅延しません）。ポリシーの全文は GOVERNANCE.md#contribute-to-access-policy-v01 を参照してください。

認証情報は coordinalo.com → Settings → Servicialo → Generar credenciales MCP から取得できます。

独自の実装を接続する

この MCP サーバーは、プラグ可能なアダプターレイヤーを介して Servicialo 互換のあらゆるバックエンドをサポートします。アダプターは 2 種類用意されています。

• coordinalo（デフォルト） — /api/organizations/{orgId} 配下の組織スコープのルートを通じて、Coordinalo／Digitalo バックエンドに接続します。
• http — /v1/* 配下で HTTP_PROFILE.md の標準エンドポイントを公開する任意の実装に接続します。

実装を接続する3つのステップ

ステップ1. HTTP_PROFILE.md で定義された REST エンドポイントを、プラットフォームに実装します。

ステップ2. HTTP アダプターを使用するように MCP サーバーを設定します。

SERVICIALO_ADAPTER=http \
SERVICIALO_BASE_URL=https://tu-plataforma.com \
SERVICIALO_API_KEY=tu_key \
npx -y @servicialo/mcp-server

ステップ3. MCP クライアントの設定に追加します。

{
  "mcpServers": {
    "servicialo": {
      "command": "npx",
      "args": ["-y", "@servicialo/mcp-server"],
      "env": {
        "SERVICIALO_ADAPTER": "http",
        "SERVICIALO_BASE_URL": "https://tu-plataforma.com",
        "SERVICIALO_API_KEY": "tu_api_key",
        "SERVICIALO_ORG_ID": "tu_org_id"
      }
    }
  }
}

HTTP アダプターは内部ルートを正規の /v1/* エンドポイントに変換し、組織のコンテキストを X-Servicialo-Org ヘッダーで送信します。REST コントラクトの全容については、HTTP_PROFILE.md を参照してください。

委任エージェンシーモデル

このプロトコルでは、AI エージェントを第一級のアクターとして扱いますが、暗黙に信頼することはありません。エージェントのアクションにはすべて ServiceMandate が必要です。これは、人間の本人からエージェントへの明示的な権限委任です。

仕組み

1. 人間（専門家、患者、または組織）がエージェントに委任状を発行します
2. 委任状には、エージェントが誰のために行動するのか、何を実行できるのか（スコープ）、どのくらいの期間有効なのかが指定されます
3. 各ツール呼び出しで、MCP サーバーは実行前に8つのチェックで委任状を検証します
4. 各アクションは、成功または失敗にかかわらず、監査記録を生成します

委任状の例

{
  "mandate_id": "550e8400-e29b-41d4-a716-446655440000",
  "principal_id": "dra_barbara",
  "principal_type": "professional",
  "agent_id": "agent_booking_bot",
  "agent_name": "Asistente de Agendamiento",
  "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"
}

ツール呼び出しでの委任状の使用

actor.type が "agent" の場合は、mandate_id を含めます。

{
  "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_booking_bot",
      "mandate_id": "550e8400-e29b-41d4-a716-446655440000"
    }
  }
}

8つの検証チェック

エージェントによる各ツール呼び出しは、以下の項目で検証されます。

#	チェック	防止するもの
1	状態 — 委任状は active である必要があります	取り消し済みまたは期限切れの委任状の使用
2	有効期間 — issued_at ≤ now < expires_at	時間に基づく攻撃
3	エージェントの ID — mandate.agent_id === 要求元のエージェント	エージェントのなりすまし
4	スコープの網羅性 — 委任状のスコープがツールの要件を満たしていること	権限昇格
5	コンテキスト — 委任状のコンテキストがリクエストと一致していること	組織をまたいだデータアクセス
6	利益相反 — エージェントが双方の代理として行動できないこと	二重代理の違反
7	制約 — 許可時間、1日の上限、金額のしきい値	自律性が高すぎるエージェント
8	監査 — サニタイズされた入力とともに各アクションが記録されること	否認防止

エージェント以外のアクター（client、provider、organization）は、委任状の検証を受けません。

プロバイダーの検索

エージェントは、構造化クエリを使用してレジストリを検索し、患者のニーズに合うプロバイダーを照合できます。

レジストリの検索

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

サービスとプロバイダーが一致する組織を返します。

空き状況の照会

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

3変数のスケジューラーが、プロバイダー、クライアント、物理リソースの空き状況を同時に確認します。

エンドツーエンドの例

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

2. services.list({ org_slug: "clinica-kinesia" })
   → lista servicios disponibles

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

4. contract.get({ service_id: "srv_123", org_id: "org_456" })
   → cancelación: 0% si >24h, 50% si 2-24h, 100% si <2h
   → evidencia requerida: check_in + check_out + registro_clinico

5. clients.get_or_create({ email: "[email protected]", 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", estado: "solicitado"

7. scheduling.confirm({ session_id: "ses_001" })
   → estado: "confirmado"

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

9. delivery.checkout({ session_id: "ses_001", location: { lat: -33.45, lng: -70.66 } })
   → estado: "entregado", duración: 42min

10. documentation.create({ session_id: "ses_001", content: "Sesión de rehabilitación de piso pélvico..." })
    → estado: "documentado"

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

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

プロトコル仕様

Servicialo プロトコルの完全な仕様は、以下から確認できます。

• リポジトリ： github.com/servicialo/protocol
• ウェブサイト： servicialo.com
• 現在の安定版： 0.9
• JSON スキーマ： service.schema.json、service-order.schema.json、service-mandate.schema.json、resolution.schema.json、servicialo-config.schema.json

仕様では、サービスの8つの側面、6+3のライフサイクル、6つの例外フロー、7つの基本原則、2つのエンティティ（アトミックなサービス＋サービスオーダー）からなるアーキテクチャ、委任エージェンシーモデル、DNS 解決、A2A 相互運用性を網羅しています。

リファレンス実装

Digitaloは、チリの医療分野で稼働する、プロトコル Servicialo の最初の本番環境向け実装です。プロバイダーの検索から支払いの精算まで、ライフサイクル全体を実装し、プロトコルの進化を検証するための環境として機能します。

この MCP サーバーは、SERVICIALO_BASE_URL を介して Servicialo 互換のあらゆるバックエンドに接続します。Digitalo はそのようなバックエンドの 1 つです。このプロトコルは、あらゆる CRM、HIS、またはプラットフォームが独立したノードとして実装できるよう設計されています。

プロトコルへの貢献

Servicialo では、プロトコル仕様にセマンティックバージョニングを採用しています。

• パッチ（0.7.x）— 明確化、誤字修正、互換性を損なわない追加
• マイナー（0.x.0）— 新しい任意フィールド、新しいツール定義、新しい例外処理フロー
• メジャー（x.0.0）— スキーマ、状態遷移マシン、またはコアセマンティクスの互換性を損なう変更

変更の提案方法

1. 問題と提案する解決策を説明する issue を作成します
2. 重要な変更の場合は、影響を受けるセクション番号を記載した RFC を spec/ に作成します
3. プロトコルの変更には、マージ前に少なくとも 1 つのリファレンス実装が必要です
4. スキーマの変更には、更新された JSON Schema と MCP サーバー内の Zod 型を含める必要があります

積極的に意見を募集している領域

• 医療分野以外の業界固有のエビデンス要件
• ライフサイクルの状態名の多言語対応
• ノード間のフェデレーション（2 つの Servicialo 実装がどのように相互運用するか）
• Python および TypeScript 向け Agent SDK パターン

テレメトリー

起動時に、MCP サーバーは https://servicialo.com/api/telemetry/instance に匿名の POST を 1 回だけ送信します。

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

フィールド	説明
event	常に "node_initialized"
version	パッケージのバージョン
node_id	~/.servicialo/node_id に保存される永続 UUID
ts	ミリ秒単位のタイムスタンプ

送信されるのは以上です。 組織情報、API キー、患者データ、個人識別情報は送信されません。IP アドレスは保存前にサーバーでハッシュ化（SHA-256）されます。この ping は fire-and-forget 方式です。失敗してもエラーは通知されずに破棄され、サーバーの動作が妨げられることはありません。

テレメトリーが有効な状態で初めて実行すると、サーバーは何が送信されるか、どうすれば無効にできるかを示す通知を stderr に出力します。

テレメトリーを無効にする

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

または、MCP の設定で指定します。

{
  "env": {
    "SERVICIALO_TELEMETRY": "false"
  }
}

詳細：servicialo.com/network

ネットワークに参加する

@servicialo/mcp-server をインストールすると、ノードは自動的にネットワークのテレメトリーに登録されます。これにより、個人データや顧客データを収集することなく、エコシステムがプロトコルの実際の導入状況を測定できます。

テレメトリーで報告されるのは、パッケージのバージョン、永続 UUID のノード ID、IP アドレスのハッシュ（おおよその位置情報のため。IP アドレスは保存しません）のみです。SERVICIALO_TELEMETRY=false を設定すれば、いつでも無効にできます。

起動時の通知

サーバーは情報通知を 2 つ stderr に出力します。JSON-RPC を転送する stdout には出力しません。stdout にほかの内容が混ざると JSON-RPC が破損するためです。

• RFC-005 のコメント募集期間（期間中のみ）。有効期限が組み込まれており、最終コメント期間の終了日である 2026-09-13 以降は表示されなくなります。10 月にノードをインストールしても、終了した告知は表示されません。
• ノードが匿名の場合の、ノードの識別方法（下記）。

どちらもプロセスごとに 1 回だけ表示され、SERVICIALO_QUIET=true で非表示にできます。

{
  "env": {
    "SERVICIALO_QUIET": "true"
  }
}

この変数が影響するのは、この 2 つの通知のみです。モードのバナーと初回実行時のテレメトリー通知は、これまでと同じ動作を維持します。

ノードを識別する

デフォルトでは、ノードは匿名です。ping に含まれるのはイベント、バージョン、node_id、タイムスタンプだけです。プロトコルの独自実装を運用している場合、次の3つの任意の変数で実装を識別し、検証済み実装者として登録を申請できます。

SERVICIALO_IMPL_NAME="Mi Plataforma"        # Nombre de tu implementación
SERVICIALO_IMPL_URL="https://example.com"   # Tu sitio web o repositorio
SERVICIALO_IMPL_CONTACT="[email protected]" # Email de contacto — se hashea antes de salir

各変数でマシンから送信される内容

変数	送信される内容	送信されない内容
SERVICIALO_IMPL_NAME	impl_name として送信される名前（プレーンテキスト）。公開情報です。検証後に /implementors に表示されます。	—
SERVICIALO_IMPL_URL	impl_url として送信される URL（プレーンテキスト）。検証後はこれも公開されます。	—
SERVICIALO_IMPL_CONTACT	impl_contact_hash のみ。ネットワークリクエストの前にお使いのマシン上で計算される、小文字に変換して空白を除いたメールアドレスの SHA-256 ハッシュです。	メールアドレス。ホストの外部に送信されず、ログにも記録されず、保存も表示もされません。

変数を設定しない場合、これらのフィールドはどれも ping に含まれません。未設定のノードは、このバージョン以前とまったく同じように動作します。

検証の流れ

anonymous → pending → verified

1. anonymous — 変数が未設定の状態です。デフォルトの状態であり、匿名のノードも完全に準拠しています。
2. pending — 新しい impl_name が初めて確認されると、登録は保留状態になり、チームに名前、URL、国を含む通知が届きます。連絡先ハッシュはその通知に含まれません。また、含めても意味がありません。
3. verified — conformance チェックリストに照らした手動レビューの後、実装はレベルと報告対象のホスト数とともに servicialo.com/implementors に掲載されます。

現時点では検証は手動で行われます。自動 conformance スイートはロードマップに含まれていますが、現在利用できる機能ではありません。

連絡先ハッシュの用途と、用途ではないもの。 これは一方向のダイジェストです。ハッシュからあなたに連絡することはできません。また、設定しても、お知らせやメーリングリストへの登録は行われません。用途はその逆です。あなたがご自身で実装について連絡する際、メールアドレスのハッシュによって、その ping を送信した運用者本人であることを確認できます。

送信を停止する方法

MCP 設定から変数を削除する（または unset SERVICIALO_IMPL_NAME SERVICIALO_IMPL_URL SERVICIALO_IMPL_CONTACT を実行する）と、サーバーを再起動します。次の ping は、識別フィールドのない匿名のものに戻ります。送信済みの ping に含まれる情報はそのまま保持されます。既存の記録の削除を依頼するには、リポジトリで issue を作成してください。

関連機能：週次スナップショット

レジストリは毎週月曜日の 00:00 UTC に、HMAC-SHA256 署名付きペイロードを含む benchmark.weekly_snapshot を登録済みエンドポイントに送信します。この3つの変数では有効になりません。 レジストリへの登録と、Webhooks API による明示的なサブスクリプションが必要です。また、プロトコルのお知らせではなく、ベンチマークデータを配信します。

ライセンス

Apache-2.0 — 商用・非商用を問わず、あらゆる実装を歓迎します。LICENSE をご覧ください。