mcpField
E
eodrecord

eodrecord

ローカル
github.com/CloudCorpRecords金融データ02 日前に更新

eodrecord について

eodrecord は、SPY と QQQ を追跡するルールベースモデルの公開済み日次記録をエージェントが参照するための読み取り専用ブリッジです。遅延公開データ、フィールド定義、検証情報、最新公開状態の参照先を提供します。

主な機能

  1. 01公開済みモデル状態と配分の参照
  2. 02公開フィールド定義の取得
  3. 03台帳フィンガープリントと検証証明の参照
  4. 04最新公開状態の掲載先の確認

活用シーン

  1. 01SPY と QQQ の過去の配分確認
  2. 02公開フィールドの定義の確認
  3. 03公開記録の完全性の検証

MCP 対応

MCP クライアントに4つの読み取り専用ツールを公開し、呼び出しを上流サービスへ転送して結果を変更せず返します。

設定

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

mcp.json · 共通設定
{
"mcpServers": {
"cloudcorprecords-eodrecord": {
"command": "npx",
"args": [
"-y",
"@reneturcios/eodrecord"
]
}
}
}
起動コマンドnpx -y @reneturcios/eodrecord

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

パッケージ
npm@reneturcios/eodrecord0.1.0
ocighcr.io/cloudcorprecords/eodrecord:0.1.0

ツール

4

掲載時のツール一覧 · 2 日前に更新

パラメーター型必須説明
daysintegerいいえ遅延記録から返す直近のセッション数(デフォルトは30)。

詳細

eodrecord

eodrecord は、ルールベースのインデックスモデルが公開した記録を読み取るための窓口をエージェントに提供します。このモデルは SPY と QQQ を追跡しており、各取引終了時点での保有銘柄と配分が、日次記録として公開されます。その記録の無料閲覧版は、ライブ版より90日遅れており、このパッケージを使ってエージェントが読み取るのは、遅延版の記録そのもの、公開される各フィールドの固定定義、記録が後から書き換えられていないことを誰でも確認できる台帳フィンガープリント、そして現在公開中の状態への参照情報です。

このパッケージ自体はモデルデータを保持しません。ツール一覧には、ライブエンドポイントから取得した内容をそのままローカルで返し、各ツール呼び出しは上流に転送して、返ってきた内容を一切変更せずに返します。4つのツールはいずれも、公開済み資料を読み取るだけです。購入、購読、キーの発行、外部へのデータ送信を行うことはありません。

ツール

  • get_public_record — 公開された日次モデル状態と配分の変更を、90日の遅延付きで表示します(ベンダーの公開記録ページのデータ)。公開済みの状態のみを返し、再計算は行いません。オプション:返す直近のセッション数を指定する1〜260の整数days(デフォルトは30)。引数は必須ではありません。
  • get_definitions — 公開されるすべてのフィールドの固定定義を返します。対象は、市場レジーム、配分状態、延長度、次のシグナルまでの距離、シグナル、および公開スケジュールです。引数はありません。
  • get_verification — RFC 3161 と OpenTimestamps の証明を含む最新の公開台帳フィンガープリントと、記録を独立して検証する方法を返します。引数はありません。
  • get_current_state — 現在公開中の状態の場所を返します。コアメンバーは公開当日の夕方に受け取れます。キーがない場合は、コアへのアクセス方法と、遅延版の公開記録の場所を返します。引数はありません。

設定

  • TIDELINE_MCP_URL(オプション)— 上流エンドポイントを上書きします。デフォルトはhttps://tideline.jbpscapital.com/mcpです。(この上書き用フックは、この再構築版独自のラベル付き再現です。)
  • TIDELINE_API_KEY(オプション)— 設定すると、すべての上流リクエストに呼び出し元自身のキーを使ったAuthorization: Bearer <key>ヘッダーが付加されます。設定されていない場合、キーのヘッダーは送信されません。(ヘッダー名はオリジナルのレジストリ記録に基づいて固定されています。この記録では、必須とはされていないシークレットのAuthorizationヘッダーが宣言されています。記録にはパッケージの環境変数名が記載されていないため、環境変数名と Bearer による転送はラベル付きの再現です。オリジナルのインターフェースはキーなしで取得されました。)
転送の仕組み

最初のツール呼び出し時に、クライアントは上流とのストリーミング可能な HTTP セッションを開始します。まず JSON-RPC のinitializeリクエスト(protocolVersion 2025-03-26、clientInfo の name はeodrecord)を送り、続いてnotifications/initialized通知を送り、その後、呼び出し元の引数を変更せずに含めたtools/callリクエストを送信します。上流がinitializeへの応答でMcp-Session-Idヘッダーを返した場合、その値はセッション内の以降のすべてのリクエストに付加され、そのプロセスが存続する間、同じセッションが再利用されます。応答は通常の JSON またはサーバー送信イベントで届く場合があり、どちらも読み取ります。

上流で成功した結果は、上流が設定したisErrorフラグも含め、そのまま通過します。JSON-RPC エラー、2xx 以外のステータス、読み取れない応答、または完了できないリクエストによる失敗は、テキストがeodrecord error:で始まるisError結果として返されます(このエラー表示は、この再構築版独自のラベル付き再現です)。

CLI

各ツールは、1つの JSON 引数文字列を受け取るサブコマンドとしても利用できます。

npx @reneturcios/eodrecord get_public_record '{"days":30}'
npx @reneturcios/eodrecord get_definitions
npx @reneturcios/eodrecord get_verification
npx @reneturcios/eodrecord get_current_state
npx @reneturcios/eodrecord --version

終了コード:成功時は0、isError結果の場合は1、使用方法のエラーの場合は2です。

MCP サーバー

npx -y @reneturcios/eodrecord mcp

MCP クライアントの設定:

{
  "mcpServers": {
    "eodrecord": {
      "command": "npx",
      "args": ["-y", "@reneturcios/eodrecord", "mcp"]
    }
  }
}

Docker

docker run -i ghcr.io/cloudcorprecords/eodrecord
docker run --rm ghcr.io/cloudcorprecords/eodrecord --version

コンテナのデフォルトコマンドはmcpです。そのため、最初の形式は stdio MCP サーバーとして動作し、それ以外の引数は通常どおり CLI に渡されます。

開発

npm install
npm run build
npm test
npm run dev

テストスイートはすべて、スタブ化した JSON-RPC 上流接続を使って実行されます。ライブネットワークへの呼び出しはありません。

License

MIT — see LICENSE.

コメント

MCP は初めてですか?

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

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