mcpField
E
EDGAR 13F point-in-time

EDGAR 13F point-in-time

ローカル
github.com/Serios16金融データ01 週間前に更新

EDGAR 13F point-in-time について

EDGAR 13F point-in-timeは、指定日に把握できた機関投資家の保有状況を調べるMCPサーバーです。提出日の可視性と訂正ルールを適用し、過去の調査やバックテストを支援します。

主な機能

  1. 01運用者名からCIK候補を検索
  2. 02指定日までに公開された提出書類を一覧
  3. 03指定日時点の四半期保有状況を取得
  4. 042期間の保有状況を比較
  5. 05返却するポジションを絞り込み

活用シーン

  1. 01過去の日付に把握できた保有状況を再現
  2. 02投資バックテストから後日の提出を除外
  3. 0313Fの訂正と出典を確認
  4. 04運用者の四半期間のポジションを比較

MCP 対応

stdioでMCPクライアントと通信し、運用者検索、提出書類一覧、時点保有状況、期間比較のツールを提供します。各クエリのas_of日付より後に提出された書類は除外されます。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"serios16-edgar13f": {
"command": "uvx",
"args": [
"edgar13f-mcp"
],
"env": {
"SEC_USER_AGENT": "<SEC_USER_AGENT>",
"EDGAR13F_AGENT_MODE": "<EDGAR13F_AGENT_MODE>",
"EDGAR13F_CACHE_DIR": "<EDGAR13F_CACHE_DIR>"
}
}
}
}
起動コマンドuvx edgar13f-mcp
設定が必要な環境変数
SEC_USER_AGENTUser-Agent sent to sec.gov, e.g. 'Your Name [email protected]' (SEC fair access).
EDGAR13F_AGENT_MODE'on' caps unnarrowed holdings/diff answers at 50 positions (auto_limited: true).
EDGAR13F_CACHE_DIROn-disk cache directory (default: $XDG_CACHE_HOME/edgar13f or ~/.cache/edgar13f).

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypiedgar13f-mcp1.2.2

ツール

4

掲載時のツール一覧 · 1 週間前に更新

パラメーター型必須説明
namestringはい
as_ofstringいいえISO-8601 形式の知識基準日:この日までに EDGAR で公開提出された情報のみを使って回答します。
limitintegerいいえ

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

edgar13f-mcp

指定した日時点で知り得た情報に基づいて、SEC Form 13F の保有状況に関する質問に回答するMCP サーバーです。サーバーの作成前に固定された評価セットが付属しています。

何をするのか、なぜ時点が重要なのか

米国で13F対象有価証券を1億米ドル以上保有する機関投資家は、四半期ごとに、四半期末から最長45日後までにForm 13Fを提出します。その後、報告書を修正する機関投資家も多くいます。訂正版は報告書全体を置き換えます。新規保有銘柄の修正報告書は行を追加します。そのため、「2024-12-31時点でマネージャーXは何を保有していたか?」への正しい回答は日によって異なります。提出日より前は何もなく、その後は当初の報告書があり、さらに後には修正後の報告書がある、ということです。

常に最新バージョンを返すツールは、バックテスト、調査メモ、エージェントの回答に未来の情報を混入させます。このサーバーは呼び出しごとにas_of日付を受け取り、次の2つのルールに従います(全文はcontracts/CONTRACTS.mdを参照してください)。

  • 可視性(§3): 提出書類は、EDGARの提出日がas_of以前の場合に限り、その日時点で参照できます。それより後に提出されたものは、行、引用、提出書類の一覧、どの提出書類を「最新」と見なすかを含め、回答に影響しません。
  • 修正報告書(§4): 対象期間のうち参照可能な提出書類を時系列に並べます。基準となるのは、最後に提出された当初報告書または訂正版です。その後に提出された新規保有銘柄の修正報告書をすべて追加します。各行には、その行の出典となった提出書類が引用されます。

インストールと実行

Python 3.11と公式のMCP Python SDK 2.xが必要です。サーバーはstdio経由でのみMCPと通信します。

GitHubから直接実行するコマンドは1つです(uvが必要です。パッケージレジストリには公開されていません)。

export SEC_USER_AGENT="Your Name [email protected]"   # required by SEC fair access
uvx --python 3.11 --from git+https://github.com/Serios16/edgar13f-mcp edgar13f-server

リリースを固定するには、タグを追加します。例:git+https://github.com/Serios16/[email protected]。Claude DesktopなどのMCPクライアントの場合:

{"mcpServers": {"edgar13f": {
  "command": "uvx",
  "args": ["--python", "3.11", "--from", "git+https://github.com/Serios16/edgar13f-mcp", "edgar13f-server"],
  "env": {"SEC_USER_AGENT": "Your Name [email protected]"}}}}

このコマンドはtests/tools/install_smoke.shでテストされています(空のuvキャッシュ、MCPハンドシェイク。出力はreports/artifacts/install_smoke.txtを参照してください)。クローンから実行する場合:

python3.11 -m venv .venv && . .venv/bin/activate
pip install -e .
export SEC_USER_AGENT="Your Name [email protected]"   # required by SEC fair access
python -m edgar13f.server                                   # or: edgar13f-server

環境変数:

  • SEC_USER_AGENT:sec.govに送信するUser-Agentです。必須です。設定されていない場合、サーバーはsec.govにアクセスしません。
  • EDGAR13F_CACHE_DIR:ディスク上のキャッシュです。既定値は$XDG_CACHE_HOME/edgar13f(または~/.cache/edgar13f)で、それが利用できない場合はユーザー専用の一時ディレクトリになります。サーバーが書き込みを行うのはここだけです。
  • EDGAR13F_REDACT:既定で墨消しされる行を返すには、値を正確にoffに設定します(制限事項を参照してください)。それ以外の値、または未設定の場合は、墨消しが有効になります。
  • EDGAR13F_AGENT_MODE:絞り込みのない保有状況の回答と差分の回答を、保有規模の大きい上位50件に制限するには、値を正確にonに設定します(エージェントでの使用を参照してください)。未設定の場合、v1のすべての呼び出しはv1.1.0とバイト単位で同じ回答を返します。
  • EDGAR13F_FIXTURE_DIR:EDGARの代わりに記録済みフィクスチャを提供します(テストで使用されます。EDGAR13F_REDACT=offとの併用は拒否されます)。

SECへのアクセスは公正なアクセスに関するポリシーに従います。同じキャッシュディレクトリを共有するプロセス間では、リクエストの開始間隔が少なくとも0.25秒(1秒あたり5回未満)になるように調整されます。403/429/5xx応答およびHTML形式のエラーページが返された場合は、指数バックオフが行われます。応答はディスク上にキャッシュされます。

ツール

ツール返される内容
find_manager(name[, as_of][, limit])現在または過去のEDGAR上の名称に name が含まれるCIK候補。13Fを提出した実績のある運用者が先に表示されます。entity_name はEDGAR上の現在の名称です(特定時点の名称ではありません)。as_of を指定した場合、has_13f_filings はその日付以前に提出された13Fのみを数えます。
list_13f_filings(cik, as_of[, period])運用者が as_of 以前に提出したすべての13F-HR、13F-HR/A、13F-NT、13F-NT/A(period が指定されている場合はその期間のもののみ)。期間、訂正番号と種類、レポートの種類、運用者名、EDGARへのリンクを含みます。
get_holdings_as_of(cik, period, as_of[, cusip][, issuer][, max_positions][, position_type])ある四半期について、as_of 時点で判明している有効な保有内容を、提出された行ごとに返します(統合や再スケーリングは行いません)。ベースとなる提出書類と、適用されたすべての訂正を引用します。
diff_holdings(cik, period_a, period_b, as_of[, cusip][, issuer][, max_positions])同じ as_of 時点で解決した2つの四半期間のポジションの変化。キーは(CUSIP、put/call、SH/PRN)で、追加、削除、増加、減少、変更なしに分類されます。

find_manager、period、issuer、max_positions は Addendum A から追加されています(加算的な変更です。これらを使わない呼び出しは、v1.1.0とまったく同じ応答になります)。

すべての応答は、免責事項 「13Fレポートにはロングポジションのみが記載されます。データは期間末から最大45日遅れる可能性があります。」 を含むJSONオブジェクトです。サーバーが回答できない場合は、status: "declined" と6つの理由のいずれか(unknown_cik、not_yet_filed、notice_only、invalid_period、invalid_argument、unsupported_request)を含む通常の結果を返します。

エージェントでの使用(Addendum A)

拡張機能は、通常は名称から調査を始め、40 MBの回答を読み取れないLLMエージェントを想定しています。一般的な手順は次のとおりです。

// 1. name -> CIK (managers that have filed Form 13F come first)
{"tool": "find_manager", "arguments": {"name": "berkshire hathaway", "as_of": "2025-08-27"}}
// 2. which filings make up one quarter, as of a date
{"tool": "list_13f_filings", "arguments": {"cik": "1067983", "as_of": "2025-08-27", "period": "2025-03-31"}}
// 3. one issuer only; the answer adds matched_cusips
{"tool": "get_holdings_as_of", "arguments": {"cik": "1067983", "period": "2025-03-31", "as_of": "2025-08-27",
                                              "issuer": "apple"}}
// 4. the 10 largest positions; the answer adds total_positions, truncated and order
{"tool": "get_holdings_as_of", "arguments": {"cik": "1067983", "period": "2025-03-31", "as_of": "2025-08-27",
                                              "max_positions": 10}}
// 5. the 20 largest changes by |value_delta|
{"tool": "diff_holdings", "arguments": {"cik": "1067983", "period_a": "2024-12-31", "period_b": "2025-03-31",
                                         "as_of": "2025-08-27", "max_positions": 20}}
  • issuer(2~100文字)を指定すると、発行体名に大文字と小文字を区別せず、連続する空白文字をまとめて照合し、一致する行のみが残ります。cusip と併用した場合はAND条件になります。
  • max_positions(1~200)を指定すると、ポジション(CUSIP、put/call、SH/PRNのグループ)を、保有内容では合計金額順、差分では |value_delta| 順に並べ、上位のポジションとその全行を返します。ポジションが分割されることはないため、1つのポジションに多数の行を提出する運用者では、返される行も多数になる場合があります。1つの証券を指定するには、issuer または cusip を使用してください。
  • 新しいパラメーターは行の絞り込みまたは並べ替えのみを行います。引用情報(accession_number、source_accessions、filing_date)と特定時点の動作は変更されず、秘匿化はフィルター処理より前に行われます。
  • find_manager は現在および過去のEDGAR上の名称をすべて照合し、EDGAR上の現在の名称を返すため、名称については特定時点の情報ではありません。空のキャッシュで初めて呼び出すと、1993年以降のEDGARの四半期フォーム索引を読み込みます(キャッシュディレクトリごとに一度、約1分かかります)。以降の呼び出しは数ミリ秒で完了します。

EDGAR13F_AGENT_MODE=on の場合、cusip、issuer、max_positions のいずれも指定しない get_holdings_as_of または diff_holdings の呼び出しは、max_positions に50を指定した場合と同じように処理され、応答に auto_limited: true が追加されます。それ以外の呼び出しには影響しません。MCP クライアントの設定:

{"mcpServers": {"edgar13f": {
  "command": "uvx",
  "args": ["--python", "3.11", "--from", "git+https://github.com/Serios16/edgar13f-mcp", "edgar13f-server"],
  "env": {"SEC_USER_AGENT": "Your Name [email protected]", "EDGAR13F_AGENT_MODE": "on"}}}}

制限事項

  • ロングポジションのみ。 Form 13Fにはショートポジションがないため、position_type が "long" 以外の場合は拒否されます。
  • 遅延。 報告書の提出期限は四半期末から最長45日後で、訂正報告書が数か月後に届くこともあります。回答の鮮度は、as_of までに提出された内容に限られます。
  • 秘匿処理。 デフォルトでは、ゴールドETF/信託、米国エネルギーセクターのETF、S&P 500インデックスファンド/ETF、およびこれらのUCITS版の行は、情報テーブルの解析時に削除されます。作者がこれらの金融商品を対象外とする別の調査を行っているためです。削除された行は、その後、返却、キャッシュ、ログ記録されることはありません。照合には発行体名と銘柄名のパターン、およびCUSIPリストを使い、意図的に削除対象を広めに取っています。そのため、一般的な有価証券も一部削除されます。採点対象の点数を損なう具体例は2つあります。すべての「SPDR S&P ...」ファンド(S&P 500に限らず、S&Pを銘柄名に含むSPDRファンド全般)と、信託またはファンドに似た名称の発行体の債券で、クラス名に「.500」のクーポンが記載されているもの(例:「5.500% NOTES」)です。クラス名に「UNIT」と記載されたエネルギー企業も該当します。裁定D2により、これらの点数を取り戻すためにリストを狭めることは禁止されています。削除対象のCUSIPを照会すると、行なしでokが返されます。秘匿処理は保有行に適用されますが、find_managerはエンティティ名をフィルタリングせずに返します(裁定N1)。秘匿処理を無効にするには、EDGAR13F_REDACT=off(正確にoff)を設定してください。この設定で読み込まれた行は別のディレクトリにキャッシュされ、秘匿処理を再び有効にすると配信されなくなります。CLAUDE.mdのルール2とREGISTER.mdの裁定D2を参照してください。
  • サーバーは2013年より前のテキスト形式の13F提出書類に対応しておらず、価格、チャート、パフォーマンス数値もありません。

評価方法

  • 非公開で固定済みの採点器。 正解データセット、漏洩データセット、採点器は、サーバーコードが存在する前に、別の非公開リポジトリで固定されました。ビルダーはそのリポジトリを読み書きできません。contracts/PREREG_COMMITMENT.mdには、そのリポジトリのマニフェストと、ここにコピーされた契約ファイルのSHA-256が記録されています。最終段階の完了後にすべて公開し、ハッシュを検証できるようにします。
  • 正解データセット: ケースの種類(例:訂正報告の前日と当日)ごとに層別化した、厳選項目40件と生成項目700件、および漏洩ケース3,114件です。
  • **ゲートのほかに、**非公開リポジトリには、実行前にそれぞれ事前登録された、アウトオブサンプルのデータセット、LLMエージェントを組み込んだ評価、その評価の診断目的での再実行、Q3 2026の提出期限前後のライブ取得結果も保存されています(結果は以下を参照)。
  • このリポジトリ内の制御。 CIでは、すべてのプッシュ時にオフラインで実行されます。テストではソケット接続が拒否されます。
    • ミュータント制御(可視性チェックを無効化し、違反を検出する必要があります。Addendum Aのすべてのパラメーターとfind_manager(as_of)も対象)と、ノーオペレーション制御を備えた漏洩テスト一式。
    • 失敗を仕込んだ合成行によるブロックリストの検証。
    • 独立したオラクルを使った§4の訂正ルールの網羅的チェック。仕込まれたルール変更ごとにテストが失敗します(tests/unit/test_restatement.py)。
    • サイズ、マップ、クレームの各チェック。それぞれに失敗を仕込んでいます。
  • OSレベルの隔離。 CIでは、読み取り専用のチェックアウトのコピーを使い、サーバーを別の非特権OSユーザーとして実行します。そのユーザーが想定されたキャッシュディレクトリ以外にファイルやディレクトリを作成した場合、ジョブは失敗します。また、仕込まれた想定外の書き込みを検出する必要があります(tests/tools/unprivileged_probe.sh)。
  • 外部との照合(テスト時のみ)。 tests/tools/datasets_crosscheck.pyは、ランダムにサンプリングした(cik, period, as_of)の組み合わせに対する回答を、SEC Form 13F Data Setsと比較します。サーバーがデータセットを読み込むことはありません。
ゲート結果(評価者による報告、集計値のみ)

項目ごとの結果は、設計上非公開です。事前登録された判定ゲートであるゲート 2 は、v1.0.0 のタグが付けられたコミット b208c47 で合格しました。ゲート 3、4、5 は、v1.1.0、v1.2.0、v1.2.1 のタグが付けられたコミット ca60c5c、f7ee806、cc61944 で合格しました。5 つのゲートすべてで集計値は同じです。

指標ゲート 1ゲート 2 (v1.0.0)ゲート 3 (v1.1.0)ゲート 4 (v1.2.0)ゲート 5 (v1.2.1)
主要ゲートすべて PASSすべて PASSすべて PASSすべて PASSすべて PASS
生成項目698 / 700698 / 700698 / 700698 / 700698 / 700
生成時の見落とし1 restatement_before、1 restatement_after同じ同じ。両方とも D2 の過剰マッチ同じ同じ
引用の有効性669 / 671669 / 671669 / 671669 / 671669 / 671
情報漏えい3,114 件中、違反 0 件3,114 件中 0 件3,114 件中 0 件3,114 件中 0 件3,114 件中 0 件
厳選項目34 / 3434 / 3434 / 3434 / 3434 / 34
回答拒否6 / 66 / 66 / 66 / 66 / 6

生成時の見落としはどちらもルール D2 に起因します。ブロックリストによって、採点者が期待した行が削除されています(既知の過剰マッチのパターン 2 件については「制限」を参照)。D2 では、見落としを解消するためにリストを狭めることを禁止しています。

アウト・オブ・サンプル。 凍結された評価の対象期間(as_of は 2025-08-27 まで)の範囲外である、2025-09 から 2026-08 までの日付の提出書類では、主要ゲートはすべて PASS でした。生成 699 / 700、3,102 件中の情報漏えい違反 0 件、引用 639 / 640、回答拒否 6 / 6 です。見落とし 1 件は D2 の過剰マッチで、採点前に予測されていました。

AI エージェントに役立つか?(評価者による報告、集計値のみ)

実行前に事前登録済み(2026-10-14):同じモデル(Claude Sonnet 5.5、effort medium)、同じ平易な英語の質問 80 件、同じ指示、12 ターンの上限、ツールの結果ごとに 50,000 文字の上限で、各質問を 2 回実行しました。すべてのツール結果は、モデルに渡す前に同じ方法で編集されました。各質問には、マネージャーと発行体(CIK や CUSIP ではなく)、四半期、および「as filed with the SEC on or before」に続く日付が記載されています。

ツールボックス正解漏えい1 回の実行あたりのツール呼び出し正解 1 件あたりのコスト
ツールなし5 / 150(回答拒否のみ。予算上限で停止)00$0.17
edgar13f v1.2.0、エージェントモード160 / 16002.2$0.017
EdgarTools MCP 5.60.0105 / 16009.0$0.145

EdgarTools とのペア比較の差は +34 ポイント(95% CI +24~+44)であり、事前登録されたルールに基づくと edgar13f のほうが優れています。EdgarTools は差分(7 / 20)、修正書類(7 / 20)、特定時点に関する質問(23 / 40)で最も成績が低く、edgar13f はすべての種類の質問に正しく回答しました。

EdgarTools が見落とした理由。 見落とした質問 31 件について事前登録済みの診断用再実行を行ったところ(2026-10-15)、同じ見落としが再現されました(62 回中 49 回)。今回も数値の誤りや情報漏えいはありませんでした。

  • 33 件は 12 ターンを使い切っており、そのうち 31 件はモデルが正しい提出書類をすでに見つけた後でした。
  • 16 件は回答拒否でした。そのうち 13 件は回答が存在する質問に対するもので、3 件は回答拒否の理由が誤っていました。このうち 4 件は、誤った提出書類または期間をたどった後に発生しました。
  • 文字数上限が原因のものはなく、数値の誤りもありませんでした。

ターン数の上限を増やせば、コスト増と引き換えに差の一部を埋められる可能性がありますが、測定はされていません。事前に示された解釈では edgar13f のほうが情報漏えいが少ないことも予想されていましたが、どちらも漏えいはありませんでした。そのため、情報漏えいの防止はツールレベルで示されています(上記のゲートを参照)が、エージェントについては裏付けも否定もされていません。

留意事項:

  • モデルとプロンプトはそれぞれ 1 つです。
  • 質問は、このサーバーの目的である特定時点の 13F 検索であり、SEC に関する一般的な質問ではありません。発行体名が複数の証券と一致した質問は除外されました。
  • 採点では、基本となる提出書類の引用が必要です。質問対象の行が記載されている新規保有分の修正書類も認めるルールの場合、edgar13f の引用は 126 / 126 件が有効です(記録値は 122 / 126)。
ライブテスト(事前登録済み、結果待ち)

2026年第3四半期の提出期限(2026年11月16日)前後に、評価担当者はランダムに抽出した300人のマネージャーについて、11月13日、17日、19日、26日にそれぞれ前日について質問し、v1.1.0の回答を記録します。これらの提出書類を対象とするデータセットがSECから公開された後に、回答を採点します。v1.1.0はテストの事前登録時点で最新だったリリースです。これらの呼び出しではv1.2.0の新しいパラメーターを一切使用せず、v1.2.0のデフォルト値はv1.1.0とバイト単位で同一であるため(フィクスチャ呼び出し3,689件、ライブ呼び出し1,328件を比較)、結果はv1.2.0にも当てはまります。記録と採点のコードは最初の記録前に凍結されており、そのハッシュは reports/LIVE_TEST_COMMITMENT.md に記載されています。

レイテンシ

コールドスタート(キャッシュが空)の状態で、当該四半期において墨消し後の行数が最も多い5件の13F-HRについて、get_holdings_as_of(cik, 2025-03-31, as_of=2025-08-27) をプロセス内で測定しました(実測値。tests/tools/cold_latency.py、成果物 reports/artifacts/cold_latency_stage3_*.json)。各セルの値は、2回(v1.0.0)または3回(v1.1)の実行のうち最悪の値です。1776033では翌日に提出された訂正報告書が元の34,332行の報告書に置き換わるため、回答は1,599行です。

CIK行数v1.0.0v1.1SECへのリクエスト数
201238350,1588.3 s4.1 s9 -> 6
31993349,5948.1 s4.3 s9 -> 5
176175544,54816.2 s4.2 s31 -> 5
89542144,19244.5 s7.6 s118 -> 13
17760331,5998.1 s2.9 s23 -> 6

v1.1は、要求された四半期に影響する表紙ページと履歴ページのみを読み込みます。キャッシュが温まった状態では、呼び出しは0.6秒未満です。list_13f_filings は引き続きすべての提出書類の表紙ページを読み込むため、これらのマネージャーでは初回呼び出しに2~36秒かかります。MCP stdio経由の場合、サーバーが50k行(約40 MB)の回答に約1秒を追加しますが、MCP Python SDKのstdioクライアント(2.2.0)自体は、このサイズのメッセージの読み取りに6~15秒かかります(メッセージサイズに対して二次的に増加します。上流への報告書はreports/upstream/に草稿があります)。

エージェント向け拡張機能について、同じ5人のマネージャーを2回実行して測定しました(実測値。tests/tools/agent_latency.py、成果物 reports/artifacts/agent_latency_run1.json および _run2.json)。

呼び出し初回呼び出し、キャッシュが空以降
find_manager(name)63~79 s(EDGARの名前ファイルと四半期ごとのフォームインデックスの136個のプレフィックス。キャッシュディレクトリごとに1回)0.02~0.05 s。新しいプロセスでは1.7~3.2 s
list_13f_filings(cik, as_of, period)0.7~3.7 s(全件リストでは2~36 s)0.05 s未満

max_positions=50を指定すると、保有銘柄の回答は17~19 MB(44~50k行)から0.4~1.0 MBに縮小され、大規模マネージャー4人のうち3人では、SDKクライアントの読み取り時間が6~14秒から0.2~0.3秒になります。残りの1人は銘柄ごとに数百行を報告するため、50銘柄でも17,741行(6.7 MB)になります。差分の回答は0.4~2.1 MBから約13 KBに縮小されます。

実測成果物を含むステージレポートはreports/にあります。

テスト

pip install -e ".[test]"
python -m pytest -q tests          # offline; sockets are refused
python tests/checks/size_budget.py . && python tests/checks/map_check.py . && python tests/checks/claims_check.py .

プロトコルチェック:inspector CIジョブは、固定されたMCP Inspector CLI(tests/inspector/inspector_check.sh)を、記録済みフィクスチャ上でサーバーに対して実行します。両方のプロトコル期間(initializeハンドシェイクを行う2025-11-25と、行わない2026-07-28)で検査し、結果をreports/artifacts/inspector_stage5.jsonと照合します。また、ツールを3つ列挙するスタブに対して失敗する必要があります。ライフサイクルチェック(stdinのクローズ、不正な行、呼び出し中のSIGTERM/SIGKILL)はtests/invariants/test_lifecycle.pyにあります。レジストリのメタデータはserver.json、手順はPUBLISHING.mdを参照してください。

MAP.mdには各モジュールの一覧と、各契約ルールがどこで適用・テストされるかが記載されています。 REGISTER.mdには判断、前提、提案が記録されています。

ライセンス

MITです。詳細はLICENSEを参照してください。ランタイム依存関係には、OSI承認の寛容なライセンス(MIT/Apache/BSD/PSF/ISC)のみを使用しています。サーバーはedgartoolsを使用せず(評価では比較の基準としてのみ使用)、AGPLプロジェクトのコードも含みません。SECとは提携しておらず、返される情報はいずれも投資助言ではありません。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。