概要: MCP エコシステム用の 8 つの高度なサーバー
以前の記事では、プロジェクト管理、生産性、DevOps 専用の MCP サーバーを分析しました。 このシリーズの 11 回目の記事では、 8 つの高度なサーバー どれが完了するか プロジェクトのアーキテクチャ テックMCP: インシデント管理、品質ゲート、ワークフローオーケストレーション、アクセス制御、意思決定ログ、 クロスサーバー分析、サービス レジストリ、集約ダッシュボード。
これらのサーバーは、エコシステムの最も洗練されたレベルを表します。これらは単独で動作するわけではありませんが、 のために設計された お互いに協力し合う EventBus と クライアントマネージャー、 イベントに自動的に反応し、セキュリティ ポリシーを適用できる統合システムを作成し、 コードの品質を検証し、複雑なワークフローを調整します。
この記事で学べること
- 6 つの専用ツールを使用してインシデントのライフサイクル全体を管理する方法
- ステータスとリンクを使用してアーキテクチャ決定記録 (ADR) を記録および追跡する方法
- 許可/拒否ポリシーを使用して RBAC アクセス制御を実装する方法
- 比較演算子を使用してメトリクスベースの品質ゲートを定義および評価する方法
- ClientManager を介してクロスサーバー実行でイベント駆動型のワークフローを調整する方法
- インサイト エンジンを使用してすべてのサーバーからの分析とメトリクスを集約する方法
- レジストリを使用してサービス検出とヘルスモニタリングを実装する方法
- 複数のソースからのキャッシュとデータを使用して集約ダッシュボードを公開する方法
高度なサーバーマップ
各サーバーを詳細に分析する前に、役割の概要を説明します。 および 8 つの高度なサーバー間の関係:
8 つのアドバンスト サーバーの概要
| サーバ | 役割 | ツール | イベントバス | クライアントマネージャー |
|---|---|---|---|---|
| インシデントマネージャー | インシデントのライフサイクル管理 | 6 | イベントプロデュース | No |
| 決定ログ | アーキテクチャの決定記録 | 5 | イベントプロデュース | No |
| アクセスポリシー | RBAC/ABACアクセス制御 | 5 | イベントプロデュース | No |
| クオリティゲート | メトリクスベースの品質ゲート | 4 | イベントプロデュース | No |
| ワークフローオーケストレーター | イベント駆動型のワークフロー オーケストレーション | 5 | 生産+消費 | Si |
| インサイトエンジン | 分析とサーバー間の相関関係 | 4 | No | Si |
| mcp-レジストリ | サービスの検出とヘルスチェック | 4 | イベントプロデュース | No |
| ダッシュボード API | マルチサーバー集約ダッシュボード | 4 | No | Si |
1. インシデントマネージャー: インシデントのライフサイクル管理
サーバー インシデントマネージャー インシデントのライフサイクル全体を開始から管理します。 調査、軽減、自動事後生成を通じて解決まで導きます。 各状態遷移は詳細なタイムラインで追跡され、重要なイベントが公開されます。 EventBus 上で他のサーバーからの自動反応を可能にします。
事故のライフサイクル
インシデントは 5 つの異なる状態を経て、それぞれが管理プロセスにおいて正確な意味を持ちます。
[open] ──────> [investigating] ──────> [mitigating] ──────> [resolved] ──────> [postmortem]
│ │ │ │
│ │ │ └── Genera report
│ │ └── Impatto ridotto post-mortem
│ └── Root cause in analisi
└── Incidente appena aperto
Eventi pubblicati:
incident:opened → Quando un incidente viene aperto
incident:escalated → Quando la severity cambia
incident:resolved → Quando l'incidente viene risolto
6 つのインシデント マネージャー ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
open-incident |
新たな事件が幕を開ける | title, severity, description, affectedSystems |
update-incident |
ステータスを更新したりメモを追加したりする | id, status, note |
add-timeline-entry |
タイムラインにエントリを追加します | incidentId, description, source |
resolve-incident |
概要と根本原因を明らかにして解決する | id, resolution, rootCause |
generate-postmortem |
書式設定された事後レポートを生成する | id |
list-incidents |
フィルターを使用してインシデントをリストする | status, severity, limit |
例: インシデントの開始と解決
重大インシデントの発生から解決までの完全なフローは次のとおりです。 EventBus でのイベントの公開:
// 1. Apertura dell'incidente
server.tool('open-incident', 'Open a new incident...', {
title: z.string().describe('Short title of the incident'),
severity: z.enum(['critical', 'high', 'medium', 'low'])
.describe('Incident severity level'),
description: z.string().describe('Detailed description'),
affectedSystems: z.array(z.string()).optional()
.describe('List of affected systems or services'),
}, async ({ title, severity, description, affectedSystems }) => {
const incident = store.openIncident({
title, severity, description, affectedSystems
});
// Pubblicazione evento sull'EventBus
eventBus?.publish('incident:opened', {
incidentId: String(incident.id),
title: incident.title,
severity: incident.severity,
affectedSystems: incident.affectedSystems,
});
return {
content: [{ type: 'text', text: JSON.stringify(incident, null, 2) }]
};
});
インシデントが解決されると、ツールは resolve-incident 自動的に計算する
事故の継続期間を追跡し、事後分析のためのデータを生成します。
// 2. Risoluzione con root cause analysis
server.tool('resolve-incident', '...', {
id: z.number().int().positive(),
resolution: z.string().describe('Summary of how it was resolved'),
rootCause: z.string().optional().describe('Root cause analysis'),
}, async ({ id, resolution, rootCause }) => {
const resolved = store.resolveIncident(id, resolution, rootCause);
const postmortem = store.generatePostmortemData(id);
const durationMinutes = postmortem?.durationMinutes ?? 0;
eventBus?.publish('incident:resolved', {
incidentId: String(id),
title: resolved.title,
resolution,
durationMinutes,
});
return {
content: [{ type: 'text', text: JSON.stringify(resolved, null, 2) }]
};
});
データ モデル: インシデントとタイムライン
SQLite ストアは 2 つのテーブルを管理します。 incidents メインデータ用 e
incident_timeline ライフサイクル中の各イベントを追跡するには:
interface Incident {
id: number;
title: string;
severity: string; // 'critical' | 'high' | 'medium' | 'low'
description: string;
status: string; // 'open' | 'investigating' | 'mitigating' | 'resolved' | 'postmortem'
affectedSystems: string[];
resolution: string | null;
rootCause: string | null;
createdAt: string;
resolvedAt: string | null;
}
interface TimelineEntry {
id: number;
incidentId: number;
description: string;
source: string | null; // es. 'monitoring', 'engineer', 'automated'
timestamp: string;
}
他のサーバーとの連携
インシデント マネージャーは、コラボレーション ハンドラーを介して他のサーバーからのイベントもリッスンします。
たとえば、イベント perf:bottleneck-found パフォーマンス プロファイラーまたはイベントから
cicd:build-failed CI/CD モニターからエントリを自動的に追加できます
関連するインシデントのタイムラインに移動します。
2. 意思決定ログ: アーキテクチャに関する意思決定の記録
サーバー 決定ログ の管理を実装します アーキテクチャ決定記録 (ADR)、 プロジェクトのアーキテクチャ上の決定を文書化するための統合パターン。あらゆる決断 コンテキスト、検討された代替案、予想される結果とともに記録されます。 そして現在の状態。
意思決定の状態
決定はライフサイクルを経て、次の 4 つの状態が考えられます。
[proposed] ──────> [accepted] ──────> [deprecated]
│
└──────> [superseded] ← (sostituita da una nuova decisione)
Eventi pubblicati:
decision:created → Quando una nuova decisione viene registrata
decision:superseded → Quando una decisione viene sostituita
5 つの意思決定ログ ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
record-decision |
新しいADRを登録する | title, context, decision, alternatives, status |
list-decisions |
記録された決定事項をリストします | オプションのフィルター |
get-decision |
ID による決定の取得 | id |
supersede-decision |
1 つの決定を新しい決定に置き換えます | id, supersededBy |
link-decision |
チケット、コミット、または影響へのリンク | decisionId, linkType, targetId |
例: ADR の登録と接続
アーキテクチャ上の決定は、コンテキスト、代替案、結果とともに記録されます。 次に、関連するチケットとコミットにリンクします。
// Registrazione di una decisione
server.tool('record-decision', '...', {
title: z.string().describe('Short title, e.g. "Use PostgreSQL for analytics"'),
context: z.string().describe('Context and problem statement'),
decision: z.string().describe('The decision that was made'),
alternatives: z.array(z.string()).optional()
.describe('Alternative options considered'),
consequences: z.string().optional()
.describe('Expected consequences'),
status: z.enum(['proposed', 'accepted', 'deprecated', 'superseded'])
.optional().default('proposed'),
relatedTickets: z.array(z.string()).optional()
.describe('Related ticket IDs, e.g. ["PROJ-123"]'),
}, async (args) => {
const record = store.recordDecision(args);
eventBus?.publish('decision:created', {
decisionId: String(record.id),
title: record.title,
status: record.status,
});
return { content: [{ type: 'text', text: JSON.stringify(record, null, 2) }] };
});
// Collegamento a ticket e commit
server.tool('link-decision', '...', {
decisionId: z.number().int().positive(),
linkType: z.enum(['ticket', 'commit', 'impact', 'related']),
targetId: z.string().describe('Ticket ID, commit hash, etc.'),
description: z.string().optional(),
}, async ({ decisionId, linkType, targetId, description }) => {
const link = store.linkDecision({ decisionId, linkType, targetId, description });
return { content: [{ type: 'text', text: JSON.stringify(link, null, 2) }] };
});
データモデル: 決定とリンク
interface Decision {
id: number;
title: string;
context: string;
decision: string;
alternatives: string[];
consequences: string;
status: string; // 'proposed' | 'accepted' | 'deprecated' | 'superseded'
relatedTickets: string[];
supersededBy: number | null;
createdAt: string;
updatedAt: string;
}
interface DecisionLink {
id: number;
decisionId: number;
linkType: string; // 'ticket' | 'commit' | 'impact' | 'related'
targetId: string;
description: string | null;
createdAt: string;
}
3. アクセス ポリシー: RBAC アクセス制御
サーバー アクセスポリシー アクセス制御システムを実装します
RBAC/ABAC 横断的に動作する（ロールベース/属性ベースのアクセス制御）
MCP エコシステム内のすべてのサーバーとツール上で。アクセスポリシーを定義できます
効果あり allow o deny、ユーザーにロールを割り当てて確認します
ツールを実行する前に権限を付与します。各検証は監査ログに記録されます。
5 つのアクセス ポリシー ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
create-policy |
新しいアクセス ポリシーを作成する | name, effect, rules[] |
check-access |
ユーザーがアクセス権を持っているかどうかを確認する | userId, server, tool |
list-policies |
アクティブなポリシーをリストします | 誰でもない |
assign-role |
ユーザーに役割を割り当てる | userId, roleName |
audit-access |
監査ログを取得する | userId, server, limit |
例: RBAC ポリシーの定義
ポリシーは、どの役割が特定のサーバーおよびツールにアクセスできるかを定義します。
その効果は次のとおりです。 allow (許可する) または deny （拒否）。
ルールではワイルドカードを使用します * すべてのサーバーまたはツールを示すには:
// Creazione di una policy: solo gli admin possono aprire incidenti
server.tool('create-policy', '...', {
name: z.string().describe('Unique name for the policy'),
effect: z.enum(['allow', 'deny']),
rules: z.array(z.object({
server: z.string().describe('Server name or "*" for all'),
tool: z.string().optional().describe('Tool name, omit for all'),
roles: z.array(z.string()).describe('Roles this rule applies to'),
})),
}, async ({ name, effect, rules }) => {
const policy = store.createPolicy({ name, effect, rules });
eventBus?.publish('access:policy-updated', {
policyId: String(policy.id),
name: policy.name,
effect: policy.effect,
});
return { content: [{ type: 'text', text: JSON.stringify(policy, null, 2) }] };
});
ポリシーの例
上級開発者にアクセスを許可するポリシーがどのように構成されているかは次のとおりです。 特定のサーバーとツールの場合:
{
"name": "senior-dev-policy",
"effect": "allow",
"rules": [
{
"server": "scrum-board",
"roles": ["senior-dev", "tech-lead"]
},
{
"server": "incident-manager",
"tool": "open-incident",
"roles": ["senior-dev", "tech-lead", "ops"]
},
{
"server": "quality-gate",
"tool": "evaluate-gate",
"roles": ["senior-dev"]
}
]
}
アクセス検証と監査ログ
ツール check-access 権限をチェックし、それぞれを自動的に記録します
監査ログに記録されます。アクセスが拒否された場合、イベントが発行されます
access:denied イベントバス上:
// Verifica accesso con audit automatico
server.tool('check-access', '...', {
userId: z.string(),
server: z.string(),
tool: z.string().optional(),
}, async ({ userId, server: targetServer, tool }) => {
const result = store.checkAccess(userId, targetServer, tool);
// Log automatico nell'audit log
store.logAccess(userId, targetServer, tool ?? '*',
result.allowed ? 'allowed' : 'denied', result.reason);
// Evento per accessi negati
if (!result.allowed) {
eventBus?.publish('access:denied', {
userId, server: targetServer,
tool: tool ?? '*', reason: result.reason,
});
}
return { content: [{ type: 'text', text: JSON.stringify(result, null, 2) }] };
});
データ モデル: ポリシー、役割、監査
SQLite ストアは 4 つのテーブルを管理します。 policies アクセスポリシーについては、
roles 役割の定義については、 role_assignments 協会のために
ユーザーロール e audit_log 各アクセスチェックを追跡するため。
この構造により、コンプライアンスとデバッグのためにアクセス履歴全体を再構築できます。
4. 品質ゲート: 指標に基づく品質チェック
サーバー クオリティゲート 定義と評価が可能 品質ゲート 定量的な指標に基づいています。各ゲートには、メトリック、比較演算子を含むチェックリストが含まれています そして閾値。ゲートが評価されると、結果 (合格/失敗) が EventBus にパブリッシュされます。 自動ワークフローをアクティブ化します。
4 つの品質ゲート ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
define-gate |
新しい品質ゲートを定義します | name, projectName, checks[] |
evaluate-gate |
実際のメトリクスを使用してゲートを評価する | gateId, metrics |
list-gates |
定義されたゲートをリストします | 誰でもない |
get-gate-history |
評価履歴 | gateId |
ルールを使用した品質ゲートの定義
品質ゲートは一連のチェックを定義し、それぞれのチェックにメトリックと演算子を付けます。
比較としきい値。サポートされている演算子は次のとおりです。 >=, <=,
>, <, == e !=.
// Definizione di un quality gate
server.tool('define-gate', '...', {
name: z.string().describe('Name of the quality gate'),
projectName: z.string().optional(),
checks: z.array(z.object({
metric: z.string().describe('Metric name, e.g. "coverage"'),
operator: z.enum(['>=', '<=', '>', '<', '==', '!=']),
threshold: z.number().describe('Threshold value'),
})),
}, async ({ name, projectName, checks }) => {
const gate = store.defineGate({ name, projectName, checks });
return { content: [{ type: 'text', text: JSON.stringify(gate, null, 2) }] };
});
例: 導入用のクオリティ ゲートの構成
{
"name": "deploy-readiness",
"projectName": "Tech-MCP",
"checks": [
{ "metric": "coverage", "operator": ">=", "threshold": 80 },
{ "metric": "complexity", "operator": "<=", "threshold": 15 },
{ "metric": "bugs", "operator": "==", "threshold": 0 },
{ "metric": "duplication", "operator": "<=", "threshold": 3 },
{ "metric": "buildTime", "operator": "<", "threshold": 300 }
]
}
評価とイベント
プロジェクトの実際の指標を使用してゲートが評価されると、その結果によって次のことが決まります。
どのイベントが公開されるか。すべてのメトリクスがチェックを満たしている場合、発行されます
quality:gate-passed;さもないと quality:gate-failed 失敗の詳細:
// Valutazione del gate
server.tool('evaluate-gate', '...', {
gateId: z.number().int().positive(),
metrics: z.record(z.string(), z.number())
.describe('Map of metric names to current values'),
}, async ({ gateId, metrics }) => {
const evaluation = store.evaluateGate(gateId, metrics);
const gate = store.getGate(gateId);
if (evaluation.passed) {
eventBus?.publish('quality:gate-passed', {
gateName: gate?.name ?? String(gateId),
project: gate?.projectName ?? '',
results: evaluation.results,
});
} else {
eventBus?.publish('quality:gate-failed', {
gateName: gate?.name ?? String(gateId),
project: gate?.projectName ?? '',
failures: evaluation.failures,
});
}
return { content: [{ type: 'text', text: JSON.stringify(evaluation, null, 2) }] };
});
CI/CDとの連携
品質ゲートは、CI/CD モニターからのイベントをリッスンします。イベント時 cicd:pipeline-completed
が公開されると、サーバーはプロジェクトに関連付けられた品質ゲートを自動的に評価できます。
同じくイベント test:coverage-report 検証を有効にすることができます
コードカバレッジに関連するゲート。
5. ワークフロー オーケストレーター: イベント駆動型の自動化
Il ワークフローオーケストレーター エコシステム全体の中で最も洗練されたサーバーです。
オーケストレーション エンジンを実装する イベント駆動型 これにより、定義することができます
一連のステップで構成されたワークフロー。各ステップが MCP サーバー上のツールを呼び出します。
全体的に異なる クライアントマネージャー。ワークフローは自動的にアクティブ化されます
EventBus で公開されたイベントから、またはツールを介して手動で trigger-workflow.
5 つのワークフロー オーケストレーター ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
create-workflow |
イベント駆動型のワークフローを作成する | name, triggerEvent, steps[] |
list-workflows |
定義されたワークフローをリストします。 | 誰でもない |
trigger-workflow |
ワークフローを手動で開始する | workflowId, payload |
get-workflow-run |
処刑の詳細 | runId |
toggle-workflow |
ワークフローを有効/無効にする | workflowId, active |
Step Cross-Server を使用したワークフローの定義
ワークフローは、トリガー イベント、オプションの条件、および順序付けられたシーケンスを定義します。
ステップの。各ステップでは、ターゲット サーバー、呼び出すツール、および引数を指定します。
引数サポートテンプレート {{payload.field}} e
{{steps[N].result.field}} ステップ間でデータを渡すには:
// Creazione di un workflow
server.tool('create-workflow', '...', {
name: z.string(),
description: z.string().optional(),
triggerEvent: z.string()
.describe('Event that triggers this workflow, e.g. "incident:opened"'),
triggerConditions: z.record(z.unknown()).optional()
.describe('Conditions to match against the event payload'),
steps: z.array(z.object({
server: z.string().describe('Target MCP server name'),
tool: z.string().describe('Tool to invoke'),
arguments: z.record(z.unknown()).optional()
.describe('Arguments with { {payload.field} } template support'),
})),
}, async (args) => {
const workflow = store.createWorkflow(args);
return { content: [{ type: 'text', text: JSON.stringify(workflow, null, 2) }] };
});
例: 重大なインシデントの自動ワークフロー
重大度のインシデントがオープンされたときにアクティブ化される完全なワークフローは次のとおりです。
critical。ワークフローは、3 つの異なるサーバー上で 3 つのステップを実行します。
{
"name": "critical-incident-response",
"description": "Automated response for critical incidents",
"triggerEvent": "incident:opened",
"triggerConditions": {
"severity": "critical"
},
"steps": [
{
"server": "decision-log",
"tool": "record-decision",
"arguments": {
"title": "Emergency: {{payload.title}}",
"context": "Critical incident opened affecting {{payload.affectedSystems}}",
"decision": "Activating emergency response protocol",
"status": "accepted"
}
},
{
"server": "quality-gate",
"tool": "evaluate-gate",
"arguments": {
"gateId": 1,
"metrics": {
"activeIncidents": 1,
"severity": 4
}
}
},
{
"server": "incident-manager",
"tool": "add-timeline-entry",
"arguments": {
"incidentId": "{{payload.incidentId}}",
"description": "Automated response workflow triggered",
"source": "workflow-orchestrator"
}
}
]
}
ワークフロー エンジン: 実行とテンプレートの解決
ワークフロー オーケストレーターの中心となるのは、 ワークフローエンジン、解像度を処理します テンプレートの評価、トリガー条件の評価、およびステップの順次実行 ClientManager経由:
class WorkflowEngine {
constructor(
private store: WorkflowStore,
private clientManager?: McpClientManager,
private eventBus?: EventBus,
) {}
// Risolve template come {{payload.title}} e {{steps[0].result.id}}
resolveTemplates(
template: Record<string, unknown>,
context: {
payload: Record<string, unknown>;
steps: Array<{ result: Record<string, unknown> | null }>;
}
): Record<string, unknown>;
// Valuta condizioni trigger: ogni chiave deve matchare il payload
evaluateTrigger(
conditions: Record<string, unknown>,
payload: Record<string, unknown>
): boolean;
// Esegue il workflow step per step via ClientManager
async executeWorkflow(
workflow: Workflow,
triggerPayload: Record<string, unknown>
): Promise<WorkflowRunRecord>;
// Gestisce eventi: trova workflow attivi e li esegue
async handleEvent(event: string, payload: unknown): Promise<void>;
}
EventBus ワイルドカード パターン
ワークフロー オーケストレーターのコラボレーション ハンドラーはパターンを使用します。 * のために
購読する すべてのイベント イベントバスの。受信したイベントごとに、
エンジンはアクティブなワークフローを検索します。 triggerEvent イベントに対応する
そして誰の triggerConditions 積載量には満足しています。これにより、
サーバーコードを変更せずにリアクティブオートメーションを作成します。
データ モデル: ワークフロー、実行、ステップ
interface Workflow {
id: number;
name: string;
description: string | null;
triggerEvent: string;
triggerConditions: Record<string, unknown>;
steps: {
server: string;
tool: string;
arguments: Record<string, unknown>;
}[];
active: boolean;
createdAt: string;
updatedAt: string;
}
interface WorkflowRunRecord {
id: number;
workflowId: number;
status: string; // 'running' | 'completed' | 'failed'
triggerPayload: Record<string, unknown>;
error: string | null;
startedAt: string;
completedAt: string | null;
durationMs: number | null;
}
6. インサイト エンジン: クロスサーバー分析
サーバー インサイトエンジン 生態系の知能レベルを表します。 を使用します。 クライアントマネージャー 利用可能なすべてのサーバーからデータを収集するには、 さまざまなソースからのメトリクスを相関させ、プロジェクトのステータスの集約ビューを公開します。 の 相関エンジン 内部でメトリクスをソースサーバーにマッピングし、管理します サーバーが利用できない場合の正常な機能低下。
4 つのインサイト エンジン ツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
query-insight |
自然言語クエリ | question, forceRefresh |
correlate-metrics |
さまざまなサーバーからのメトリクスを相関させる | metrics[], period |
explain-trend |
指標の傾向を説明する | metric, direction |
health-dashboard |
プロジェクト健全性ダッシュボード | forceRefresh |
CorrelationEngine: メトリクスとサーバーのマッピング
インサイト エンジンの中心となるのは、 CorrelationEngine, which maintains a map
利用可能なメトリックとそれらを提供するサーバーの内部。 When requested
相関関係により、エンジンは ClientManager 経由で適切なサーバーを呼び出します。
そして結果を集計します。
class CorrelationEngine {
// Mappatura metrica -> server/tool
private metricMap = {
'velocity': { server: 'agile-metrics', tool: 'calculate-velocity' },
'time-logged': { server: 'time-tracking', tool: 'get-timesheet' },
'budget-spent': { server: 'project-economics', tool: 'get-budget-status' },
};
// Chiamata sicura: ritorna null se il server non e disponibile
async safeCall(server: string, tool: string, args = {})
: Promise<Record<string, unknown> | null>;
// Correlazione di metriche multiple
async correlateMetrics(metrics: string[])
: Promise<{ metrics: Record; dataSources: Record; analyzedAt: string }>;
// Dashboard salute del progetto con health score
async getProjectHealth()
: Promise<{ healthScore: number; velocity; timeTracking; budget; dataSources }>;
// Query basata su keyword matching
async queryInsight(question: string)
: Promise<{ question; relevantMetrics; data; generatedAt }>;
}
インテリジェントなキャッシュ
インサイト エンジンは、InsightStore。
応答は、分析タイプとクエリで構成されるキーとともに保存されます。
パラメータ forceRefresh 必要に応じてキャッシュをバイパスできます。
ツール health-dashboard バランスをとるために 300 秒の TTL を使用します
データの鮮度とパフォーマンス。
7. MCP レジストリ: サービス検出とヘルスモニタリング
サーバー mcp-レジストリ それはのように機能します サービスレジストリ MCP エコシステム向け。各サーバーは独自の URL、トランスポート プロトコルを使用して登録できます。 そして機能のリスト。レジストリは定期的なヘルスチェックをサポートし、イベントを発行します。 サーバーが利用できなくなったとき。
MCP レジストリの 4 つのツール
利用可能なツール
| ツール | 説明 | 主なパラメータ |
|---|---|---|
register-server |
新しいサーバーを登録する | name, url, transport, capabilities |
discover-servers |
登録されたサーバーを検出します | status, transport |
health-check |
ヘルスチェックを実行します | serverId |
get-capabilities |
サーバーの機能を取得します | serverId |
サーバーの登録と検出
// Registrazione di un server nell'ecosistema
server.tool('register-server', '...', {
name: z.string().describe('Unique name of the MCP server'),
url: z.string().describe('URL or endpoint'),
transport: z.enum(['stdio', 'http', 'in-memory'])
.optional().default('stdio'),
capabilities: z.array(z.string()).optional()
.describe('List of capabilities'),
}, async ({ name, url, transport, capabilities }) => {
const record = store.registerServer({ name, url, transport, capabilities });
eventBus?.publish('registry:server-registered', {
serverName: record.name,
url: record.url,
capabilities: record.capabilities,
});
return { content: [{ type: 'text', text: JSON.stringify(record, null, 2) }] };
});
// Discovery con filtri per stato e trasporto
server.tool('discover-servers', '...', {
status: z.enum(['healthy', 'unhealthy', 'unknown']).optional(),
transport: z.enum(['stdio', 'http', 'in-memory']).optional(),
}, async ({ status, transport }) => {
const servers = store.listServers({ status, transport });
return { content: [{ type: 'text', text: JSON.stringify(servers, null, 2) }] };
});
ヘルスチェックとモニタリング
ツール health-check 登録されたサーバーのステータスチェックを実行します。
サーバーが利用できない場合、イベントは公開されます registry:server-unhealthy
イベントバス上:
// Health check con pubblicazione eventi
server.tool('health-check', '...', {
serverId: z.number().int().positive(),
}, async ({ serverId }) => {
const srv = store.getServer(serverId);
const responseTimeMs = /* misurazione tempo risposta */;
const status = responseTimeMs > 450 ? 'unhealthy' : 'healthy';
const healthCheck = store.recordHealthCheck({
serverId, status, responseTimeMs,
error: status === 'unhealthy' ? 'Timeout' : undefined,
});
if (status === 'unhealthy') {
eventBus?.publish('registry:server-unhealthy', {
serverName: srv.name,
lastHealthy: srv.lastHealthCheck ?? srv.createdAt,
error: 'Health check failed',
});
}
return { content: [{ type: 'text', text: JSON.stringify(healthCheck, null, 2) }] };
});
8. API ダッシュボード: マルチサーバーの集約
サーバー ダッシュボード API を取得するための統合アクセス ポイントとして機能します。 エコシステム全体の総合的なビュー。を使用します。 クライアントマネージャー 複数のサーバーに同時にクエリを実行する (スクラムボード、アジャイルメトリクス、時間追跡、 プロジェクト経済、意思決定ログ、インシデントマネージャー、品質ゲート、レトロスペクティブマネージャー) 組み込みのキャッシュを使用して、一貫した形式でデータを表示します。
API ダッシュボードの 4 つのツール
利用可能なツール
| ツール | 説明 | クエリされたサーバー |
|---|---|---|
get-overview |
集約プロジェクトの概要 | スクラムボード、アジャイルメトリクス、時間追跡、プロジェクト経済学 |
get-server-status |
登録されているサーバーのステータス | mcp-レジストリ |
get-recent-activity |
最近のアクティビティの集計 | 意思決定ログ、インシデントマネージャー、レトロスペクティブマネージャー |
get-project-summary |
プロジェクトの完全な概要 | すべてのサーバーが利用可能 (7 台以上) |
例: 集計の概要
ツール get-overview 4 つのサーバーから同時にデータを収集します
使用して Promise.all パフォーマンスを最大化するために。サーバーごとに、
データが利用可能かどうかが示され、保証されます。
優雅な劣化:
server.tool('get-overview', '...', {
forceRefresh: z.boolean().optional(),
}, async ({ forceRefresh }) => {
// Check cache (TTL 120 secondi)
if (!forceRefresh) {
const cached = store.getCached('overview', 'main');
if (cached) return { content: [{ type: 'text',
text: JSON.stringify({ ...cached, fromCache: true }, null, 2) }] };
}
// Aggregazione parallela da 4 server
const [scrumBoard, velocity, timesheet, budget] = await Promise.all([
safeCall(clientManager, 'scrum-board', 'list-sprints', {}),
safeCall(clientManager, 'agile-metrics', 'calculate-velocity', {...}),
safeCall(clientManager, 'time-tracking', 'get-timesheet', {}),
safeCall(clientManager, 'project-economics', 'get-budget-status', {...}),
]);
const overview = {
velocity: velocity ?? { status: 'unavailable' },
scrumBoard: scrumBoard ?? { status: 'unavailable' },
timeTracking: timesheet ?? { status: 'unavailable' },
budget: budget ?? { status: 'unavailable' },
dataSources: {
scrumBoard: scrumBoard ? 'available' : 'unavailable',
velocity: velocity ? 'available' : 'unavailable',
timeTracking: timesheet ? 'available' : 'unavailable',
budget: budget ? 'available' : 'unavailable',
},
generatedAt: new Date().toISOString(),
};
store.setCache('overview', 'main', overview, 120);
return { content: [{ type: 'text', text: JSON.stringify(overview, null, 2) }] };
});
プロジェクトの概要: 完全なビジョン
ツール get-project-summary 最も完全な集計を表します。
利用可能なすべてのサーバーに同時にクエリを実行してビジョンを生成する
プロジェクトの 360 度:
// Aggregazione parallela da 7 server
const [velocity, timesheet, budget, decisions,
incidents, qualityGates, retros] = await Promise.all([
safeCall(clientManager, 'agile-metrics', 'calculate-velocity', {...}),
safeCall(clientManager, 'time-tracking', 'get-timesheet', {}),
safeCall(clientManager, 'project-economics', 'get-budget-status', {...}),
safeCall(clientManager, 'decision-log', 'list-decisions', {}),
safeCall(clientManager, 'incident-manager', 'list-incidents', {}),
safeCall(clientManager, 'quality-gate', 'list-gates', {}),
safeCall(clientManager, 'retrospective-manager', 'list-retros', {}),
]);
パターンセーフコールとグレースフルデグラデーション
ダッシュボード API とインサイト エンジンの両方がパターンを使用します safeCall
クロスサーバー通信を管理します。サーバーが利用できない場合、呼び出しは
返品 null 例外をスローする代わりに。フィールド dataSources
応答内の各サーバーの可用性ステータスを示し、クライアントが
どのデータが本物で、どのデータが欠落しているかを知るためです。
生態系イベントマップ
8 つの高度なサーバーは、EventBus 経由でイベントを生成および消費します。 これらのサーバーによって生成されるイベントの完全なマップは次のとおりです。
Advanced Servers によって発行されたイベント
| イベント | ソースサーバー | メインペイロード |
|---|---|---|
incident:opened |
インシデントマネージャー | インシデント ID、タイトル、重大度、影響を受けるシステム |
incident:escalated |
インシデントマネージャー | インシデント ID、前の重大度、新しい重大度 |
incident:resolved |
インシデントマネージャー | IncidentId、タイトル、解決策、継続時間分 |
decision:created |
決定ログ | 決定ID、タイトル、ステータス |
decision:superseded |
決定ログ | DecisionId、supersededBy、タイトル |
access:policy-updated |
アクセスポリシー | ポリシーID、名前、効果 |
access:denied |
アクセスポリシー | ユーザーID、サーバー、ツール、理由 |
quality:gate-passed |
クオリティゲート | ゲート名、プロジェクト、結果 |
quality:gate-failed |
クオリティゲート | ゲート名、プロジェクト、失敗 |
workflow:triggered |
ワークフローオーケストレーター | workflowId、名前、triggeredBy |
workflow:completed |
ワークフローオーケストレーター | workflowId、runId、name、durationMs |
workflow:failed |
ワークフローオーケストレーター | workflowId、runId、名前、エラー |
registry:server-registered |
mcp-レジストリ | サーバー名、URL、機能 |
registry:server-unhealthy |
mcp-レジストリ | サーバー名、lastHealthy、エラー |
アーキテクチャ: 自律サーバーと統合サーバー
8 つの高度なサーバーは 2 つの異なるアーキテクチャ カテゴリに分類されます エコシステムの他の部分とどのように相互作用するかに基づきます。
アーキテクチャの比較
| カテゴリ | サーバ | 特性 |
|---|---|---|
| 自律型 | インシデントマネージャー、意思決定ログ、アクセスポリシー、クオリティゲート | 独自のドメインを管理し、イベントを生成し、ClientManager を必要としません。 |
| 統合 | ワークフロー オーケストレーター、インサイト エンジン、ダッシュボード API、mcp レジストリ | 他のサーバーからのデータを集約します。サーバー間通信には ClientManager が必要です |
サーバー 自律的 単独で機能することもできます。独自の管理を行います。 SQLite データベースを使用し、他のサーバーに依存せずに EventBus にイベントを発行します。 のサーバー 統合 エコシステムのコンテキスト内で動作するように設計されています ClientManager を使用して他のサーバーにクエリを実行し、データを集約して完了です。
結論
8 台の先進的なサーバーがプロジェクトのアーキテクチャを完成させます テックMCP、 エコシステムをエンタープライズレベルの洗練度に引き上げます。インシデント管理から 品質保証、アクセス制御からワークフロー オーケストレーションまで、すべてのサーバー 特定のドメインをプラットフォーム全体に貢献します。
浮かび上がってくるパターンは、 イベント駆動型分散システム: 自律サーバーは独自のドメインを管理し、イベント、ワークフロー オーケストレーターを発行します。 クロスサーバー自動化と集約サーバーを実行することでイベントに反応します。 (insight-engine、dashboard-api) は、エコシステム全体の統一されたビューを提供します。
次回の記事ではさらに詳しく掘り下げていきます サーバー間のコラボレーション: エコシステムの 31 台の MCP サーバーが EventBus を介して相互に通信する方法、 ClientManager がサーバー間通話を可能にする方法とコラボレーション パターンの方法 これらを使用すると、単純なコンポーネントから始めて複雑な自動化を構築できます。
すべてのサーバーの完全なコードはリポジトリで入手できます GitHub 上の Tech-MCP.