Rfcxml Mcp

RFCXML MCP サーバー

日本語版 README · ドキュメント

RFC ドキュメントを構造的に理解するための Model Context Protocol（MCP）サーバーです。

目的

既存のテキストベースの RFC MCP サーバーとは異なり、このサーバーは RFCXML の意味的な構造を活用して、次のことを可能にします。

• 規範要件（MUST／SHOULD／MAY）の抽出と構造化された出力
• RFC 依存関係グラフの構築
• 定義のスコープ管理
• 実装チェックリストの生成

アーキテクチャ

┌─────────────────────────┐
│  Markdown / PDF         │  Display & Sharing
├─────────────────────────┤
│  Translation            │  Explanation & Verification
├─────────────────────────┤
│  RFCXML MCP             │  Common Understanding for AI & Humans
├─────────────────────────┤
│  RFCXML                 │  Single Source of Truth
└─────────────────────────┘

既存の MCP との比較

機能	既存の mcp-rfc	RFCXML MCP
RFC テキストの取得	✅	✅
セクションの抽出	✅（テキストベース）	✅（構造ベース）
MUST／SHOULD／MAY の抽出	❌	✅
条件／例外の構造化	❌	✅
RFC 依存関係グラフ	❌	✅
定義のスコープ管理	❌	✅
実装チェックリスト	❌	✅

クイックスタート

Claude Desktop／Claude Code での使用

次の内容を MCP 設定ファイルに追加します。

{
  "mcpServers": {
    "rfcxml": {
      "command": "npx",
      "args": ["-y", "@shuji-bonji/rfcxml-mcp"]
    }
  }
}

バージョンを固定するには（0.6.x ではパッチリリースが頻繁に公開されます）、パッケージ指定にバージョンを記述します。

{
  "mcpServers": {
    "rfcxml": {
      "command": "npx",
      "args": ["-y", "@shuji-bonji/[email protected]"]
    }
  }
}

再起動後も取得した RFC をディスクに保持するには、RFCXML_CACHE_DIR を渡します（ディスクキャッシュと rfcxml-prefetch を参照）。

{
  "mcpServers": {
    "rfcxml": {
      "command": "npx",
      "args": ["-y", "@shuji-bonji/[email protected]"],
      "env": { "RFCXML_CACHE_DIR": "/home/you/.cache/rfcxml-mcp" }
    }
  }
}

設定ファイルの場所：

• Claude Desktop（macOS）：~/Library/Application Support/Claude/claude_desktop_config.json
• Claude Desktop（Windows）：%APPDATA%\Claude\claude_desktop_config.json
• Claude Code（プロジェクトスコープ）：プロジェクトルートの .mcp.json
• Claude Code（ユーザースコープ）：~/.claude.json
• Claude Code（CLI）：claude mcp add rfcxml -- npx -y @shuji-bonji/rfcxml-mcp

インストール（任意）

グローバルにインストールするには：

npm install -g @shuji-bonji/rfcxml-mcp

次に MCP を設定します。

{
  "mcpServers": {
    "rfcxml": {
      "command": "rfcxml-mcp"
    }
  }
}

利用可能なツール

フェーズ 1：基本構造

• get_rfc_structure - セクション階層とメタデータを取得
• get_requirements - 規範要件（MUST／SHOULD／MAY）を構造とともに抽出
• get_definitions - 用語の定義とそのスコープを取得

フェーズ 2：関係

• get_rfc_dependencies - 参照されている RFC（規範的／参考情報）を取得
• get_related_sections - 同じ RFC 内の関連セクションを取得

フェーズ 3：検証支援

• validate_statement - ある記述に関係する RFC 要件を見つけ、検出された矛盾を報告します。これは適合性の判定ではありません。isValid は三値（null = 判定に十分な一致がない、false = 矛盾が検出された、true = 一致した要件の中に矛盾が検出されなかった）です。判定はご自身で行ってください。
• generate_checklist - 実装チェックリストを生成

レガシー RFC のサポート

RFC 8650（2019 年 12 月）以降に公開された RFC は、公式の RFCXML v3 形式で利用できます。それ以前の RFC では、XML が用意されていない場合があります。

このサーバーには自動フォールバック機能が含まれており、XML が利用できない場合は、代わりにテキスト形式を解析します。

ソース情報

すべてのレスポンスにソース情報が含まれます。

{
  "rfc": 6455,
  "sections": [...],
  "_source": "text",
  "_sourceNote": "Warning: Parsed from text format. Accuracy may be limited."
}

_source	説明
xml	RFCXML から解析（高精度）
text	テキストから解析（中程度の精度）

互換性

RFC	形式	備考
RFC 8650 以降	XML	公式 RFCXML v3 のサポート
RFC 8650 より前	Text	自動フォールバック

出力サンプル

以下の各サンプルは、現在のビルド（npm run build を実行後、MCP クライアント経由で記載のツールを呼び出し）の実際の出力を抜粋したものです。フィールド名と値はそのまま掲載しており、長い配列は ... で省略しています。

get_rfc_structure - RFC 構造を取得

get_rfc_structure { "rfc": 9293 }

{
  "metadata": {
    "title": "Transmission Control Protocol (TCP)",
    "docName": "draft-ietf-tcpm-rfc793bis-28",
    "number": 9293,
    "date": "2022-08",
    "category": "std",
    "stream": "IETF",
    "abstract": "This document specifies the Transmission Control Protocol (TCP). ..."
  },
  "sections": [
    { "number": "1", "title": "Purpose and Scope" },
    { "number": "2", "title": "Introduction" },
    {
      "number": "3",
      "title": "Functional Specification",
      "subsections": [
        { "number": "3.1", "title": "Header Format" },
        {
          "number": "3.5",
          "title": "Establishing a Connection",
          "subsections": [
            { "number": "3.5.1", "title": "Half-Open Connections and Other Anomalies" },
            { "number": "3.5.2", "title": "Reset Generation" },
            { "number": "3.5.3", "title": "Reset Processing" }
          ]
        }
      ]
    }
  ],
  "referenceCount": { "normative": 15, "informative": 85 },
  "_source": "xml"
}

number は RFC に印刷されているセクション番号（3.5、A.2）であり、RFCXML の pn（section-3.5）ではありません。category / stream / abstract は IETF Datatracker API から取得され、API にアクセスできない場合、またはマッピングに存在しない値が返された場合（例：RFC 1 は unkn / legacy）は省略されます。その場合は _sourceNote にその旨が記載されます。

get_requirements - 規範的要件を抽出

get_requirements { "rfc": 9293, "level": "MUST" }

{
  "rfc": 9293,
  "filter": { "section": "all", "level": "MUST" },
  "stats": { "total": 55, "byLevel": { "MUST": 55 } },
  "requirements": [
    {
      "id": "R-3.5-1",
      "level": "MUST",
      "text": "A TCP implementation MUST support simultaneous open attempts (MUST-10).",
      "section": "3.5",
      "sectionTitle": "Establishing a Connection",
      "fullContext": "A TCP implementation MUST support simultaneous open attempts (MUST-10).",
      "subject": "tcp implementation",
      "action": "support simultaneous open attempts (MUST-10)"
    },
    {
      "id": "R-3.7.1-1",
      "level": "MUST",
      "text": "TCP endpoints MUST implement both sending and receiving the MSS Option (MUST-14).",
      "section": "3.7.1",
      "sectionTitle": "Maximum Segment Size Option",
      "fullContext": "TCP endpoints MUST implement both sending and receiving the MSS Option (MUST-14).",
      "subject": "tcp endpoints",
      "action": "implement both sending and receiving the MSS Option (MUST-14)"
    }
  ],
  "_source": "xml"
}

id は R-<section>-<n> の形式で、n はセクションごとに採番されます。そのため、ドキュメント内の別の箇所に要件が追加されても、識別子は変わりません。

get_rfc_dependencies - RFC の依存関係を取得

get_rfc_dependencies { "rfc": 9293 }

{
  "rfc": 9293,
  "normative": [
    { "rfcNumber": 791, "title": "Internet Protocol", "anchor": "RFC0791" },
    { "rfcNumber": 1191, "title": "Path MTU discovery", "anchor": "RFC1191" },
    {
      "rfcNumber": 2119,
      "title": "Key words for use in RFCs to Indicate Requirement Levels",
      "anchor": "RFC2119"
    }
  ],
  "informative": [
    { "rfcNumber": 793, "title": "Transmission Control Protocol", "anchor": "RFC0793" },
    { "rfcNumber": 896, "title": "Congestion Control in IP/TCP Internetworks", "anchor": "RFC0896" }
  ],
  "_source": "xml",
  "_referencesSource": "xml"
}

_referencesSource は、参照リストの取得元を示します。xml（RFCXML の <references>）、text（プレーンテキストの「References」セクション）、または api（プレースホルダーのタイトルを含む Datatracker の relateddocument）です。

generate_checklist - 実装チェックリストを生成

generate_checklist { "rfc": 9293, "role": "client", "sections": ["3.5", "3.7.1"] } — markdown フィールド：

# RFC 9293 Implementation Checklist

**Transmission Control Protocol (TCP)**

Role: client

Generated: 2026-09-04T17:09:37.833Z

## Mandatory Requirements (MUST / REQUIRED / SHALL)

- [ ] **MUST** A TCP implementation MUST support simultaneous open attempts (MUST-10). (§3.5)
- [ ] **MUST** TCP endpoints MUST implement both sending and receiving the MSS Option (MUST-14). (§3.7.1)
- [ ] **MUST** If an MSS Option is not received at connection setup, TCP implementations MUST assume a default send MSS of 536 (576 - 40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15). (§3.7.1)

## Recommended Requirements (SHOULD / RECOMMENDED)

- [ ] **SHOULD** TCP implementations SHOULD allow a received RST segment to include data (SHLD-2). (§3.5.3)

同じ呼び出しでは、"stats": { "must": 6, "should": 2, "may": 1, "total": 9 } も返されます。

validate_statement - 該当する要件を検索

validate_statement { "rfc": 6455, "statement": "The client MUST mask all frames sent to the server." }

{
  "rfc": 6455,
  "statement": "The client MUST mask all frames sent to the server.",
  "analysis": { "detectedLevel": "MUST", "detectedSubject": "client" },
  "isValid": true,
  "matchingRequirements": [
    {
      "id": "R-5.3-2",
      "level": "MUST",
      "text": "When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values.",
      "section": "5.3",
      "sectionTitle": "Client-to-Server Masking",
      "_matchScore": 17,
      "_matchedKeywords": ["client", "mask", "frames"],
      "_subjectMatch": true,
      "_levelMatch": true
    }
  ],
  "conflicts": [],
  "_source": "text",
  "_sourceNote": "Warning: Parsed from text format. Validation accuracy may be limited."
}

isValid: true が意味するのは、一致した要件の間に矛盾が検出されなかったことだけです。十分な強さで一致する要件がない場合、isValid は null になり、_verdictNote にその理由が記載されます。

テキストへのフォールバック出力（レガシー RFC）

get_rfc_structure { "rfc": 6455 } — RFC 6455 は RFCXML v3 より前の RFC であるため、プレーンテキストが解析されます。

{
  "metadata": {
    "title": "The WebSocket Protocol",
    "number": 6455,
    "date": "2011-12",
    "category": "std",
    "stream": "IETF",
    "abstract": "The WebSocket Protocol enables two-way communication ..."
  },
  "sections": [
    { "number": "1", "title": "Introduction" },
    { "number": "2", "title": "Conformance Requirements" },
    { "number": "5", "title": "Data Framing" }
  ],
  "referenceCount": { "normative": 18, "informative": 9 },
  "_source": "text",
  "_sourceNote": "Warning: Parsed from text format. Accuracy may be limited."
}

RFC 8650 以降では、まず XML が試されます。すべての XML ソースが 404 を返した場合、呼び出しは失敗します（「その番号の RFC は公開されていません」）。XML の取得が別の理由（5xx、タイムアウト）で失敗した場合は、テキストが使用され、XML の取得に失敗したことと、一時的な問題である可能性があることが _sourceNote に記載されます。

ディスクキャッシュと rfcxml-prefetch

デフォルトでは、取得した RFC はメモリ内 LRU キャッシュにのみ保存され、再起動のたびに再取得されます。ディスクに保存するには、RFCXML_CACHE_DIR を設定します。

$RFCXML_CACHE_DIR/
├── xml/rfc9293.xml     # RFCXML (RFC 8650 and later)
└── text/rfc6455.txt    # plain text (older RFCs, or XML fetch failures)

このパッケージには rfcxml-prefetch CLI も含まれており、オフライン利用や CI 利用に備えて、同じレイアウトに事前にデータを保存できます。

# Fetch a range into $RFCXML_CACHE_DIR (or ~/.cache/rfcxml-mcp when unset)
npx -y -p @shuji-bonji/rfcxml-mcp rfcxml-prefetch --range 9110-9114

# Individual RFCs, explicit directory, re-download even if cached
npx -y -p @shuji-bonji/rfcxml-mcp rfcxml-prefetch --rfc 6455 --rfc 9293 --cache-dir ./rfc-cache --force

オプション：--range A-B、--rfc N（繰り返し指定可能）、--cache-dir DIR、--concurrency N（デフォルトは 3）、--force。ディスク上にすでに存在する RFC（XML またはテキスト）は、--force を指定しない限りスキップされます。RFC 番号には数字のみを指定してください。--rfc 9110abc を指定すると、終了コード 1 で終了します。

例

完全なチェックリストのサンプルについては、examples/ ディレクトリをご覧ください。

RFC	プロトコル	ソース
RFC 6455	WebSocket	テキスト（フォールバック）
RFC 9293	TCP	RFCXML
RFC 7540	HTTP/2	テキスト（フォールバック）

Claude 用プロンプトの例：

Generate an implementation checklist for RFC 9293 (TCP).

内部アーキテクチャ

モジュール構成

src/
├── index.ts                    # MCP server entry point
├── config.ts                   # Centralized configuration
├── constants.ts                # BCP 14 keyword definitions + RFC number limits
├── services/
│   ├── rfc-fetcher.ts          # RFC fetching (parallel)
│   ├── rfc-service.ts          # RFC parse & cache management
│   ├── rfcxml-parser.ts        # RFCXML parser
│   ├── rfc-text-parser.ts      # Text fallback parser
│   └── checklist-generator.ts  # Checklist generation service
├── tools/
│   ├── definitions.ts          # MCP tool definitions
│   └── handlers.ts             # Tool handlers (toolHandlers map)
├── types/
│   └── index.ts                # Type definitions
└── utils/
    ├── cache.ts                # LRU cache
    ├── fetch.ts                # Parallel fetch utility
    ├── logger.ts               # Logger abstraction
    ├── requirement-extractor.ts # Shared requirement extraction
    ├── section.ts              # Section search utilities
    ├── statement-matcher.ts    # Weighted statement matching
    ├── text.ts                 # Text processing utility
    └── validation.ts           # Input validation

RFC 取得の最適化

2 つの XML ソース（RFC Editor、Datatracker）に並列でリクエストを送信し、最初に成功した応答を使用します。tools.ietf.org は 2021 年に廃止されており、使用されません。再試行は行わず、並列リクエストによる競合のみが冗長性を確保します。

┌─────────────────┐
│  fetchRFCXML()  │
└────────┬────────┘
         │ Parallel requests
    ┌────┴─────────┐
    ▼              ▼
┌────────┐    ┌────────┐
│RFC     │    │Data-   │
│Editor  │    │tracker │
└────┬───┘    └────┬───┘
     │             │
     └──────┬──────┘
            │ Promise.any (first success)
            ▼
    ┌───────────┐
    │ Successful│ → Cancel other requests via AbortController
    │ Response  │
    └───────────┘

同じ RFC に対する同時呼び出し（たとえば、get_rfc_structure と get_requirements を並列で実行する場合）では、進行中の取得処理と解析処理がそれぞれ 1 つずつ共有されます。

キャッシュ戦略

メモリ制限付きの LRU（最も長く使われていない項目を削除する）キャッシュに加え、以下の XML／テキストキャッシュより下位に、任意のディスクキャッシュ（RFCXML_CACHE_DIR）があります。

キャッシュ	最大エントリー数	内容
XML キャッシュ	20	RFCXML の生データ
テキストキャッシュ	20	テキストの生データ
メタデータキャッシュ	100	RFC のメタデータ
解析キャッシュ	50	解析済みの構造

開発

# Install dependencies
npm install

# Development mode
npm run dev

# Build
npm run build

# Unit tests (single run) / watch mode
npm test
npm run test:watch

# E2E test (MCP client integration; fetches a few real RFCs)
npm run test:e2e

# Audit against real RFCs, tool-to-tool crosscheck, output snapshots
# (see tests/audit/README.md; run weekly by .github/workflows/audit.yml)
npm run audit
npm run crosscheck
npm run snapshot

# Lint
npm run lint

# Format
npm run format

ライセンス

MIT

関連プロジェクト

• mjpitz/mcp-rfc - テキストベースの RFC MCP
• ietf-tools/RFCXML - RFCXML スキーマ
• xml2rfc - IETF 公式ツール