Jarroba Tools

Jarroba Tools MCP

AI に「計算」ではなく答えを「創作」させるのではなく、Jarroba Tools の決定論的なツールを利用できる、ローカルの MCP サーバー（stdio）です。すべてお使いのマシン上で実行されます。ホストがサーバーをサブプロセスとして起動し、stdin/stdout 経由で通信します。ネットワークも、エンドポイントも、アカウントも必要ありません。

ツールは ウェブアプリと同じロジックを再利用します。Angular を除いたサービスを使うため、別実装との乖離も起きません。

コンテキストは無料ではないため、4 つのパッケージに分けています

すべてのツール定義を最初に読み込むクライアント（Cursor など大半のクライアント、および Tool Search をオフにした Claude Code）では、何も入力する前に 140 個すべてのツールを読み込むだけで コンテキストを約 53,800 トークン消費します。これは Claude Code 独自の計測値です。0.1.7 で /context を使って計測した結果（120 個のツールで 41,996 トークン）を、npm run tokens で外挿しました。デフォルトで有効な Claude Code の Tool Search は、使用直前に定義を読み込むため、カタログ全体で数百トークンしかかかりません。GitHub 公式の MCP サーバーは、この問題の典型例です。Cursor の上限は約 40 個のツールです。140 個のカタログは「より完全」なのではなく、より高コストです。また、モデルの選択精度も下がります。大規模なカタログでよく起きる失敗は、ツールが見つからないことではなく、隣にある別のツールを呼び出すことだからです。

そこで、実際に必要なものを選んでください。

パッケージ	ツール	コンテキスト	用途
@jarroba/mcp-logs	12	約 5,500 トークン	コンテキストに収まらないログを読む
@jarroba/mcp-tests	4	約 1,700 トークン	テストを監査する（自作のテストも含む）
@jarroba/mcp-calc	5	約 1,600 トークン	単位、方程式、シートを使った数学
@jarroba/mcp	140	約 53,800 トークン	すべて

4 つとも同じソースを使用しています。フィルターには JARROBA_MCP_DOMAINS 環境変数を使い、各バイナリはそれぞれのドメインをデフォルトとして設定します。これは制限ではありません。mcp-logs をインストールし、汎用ツールも必要なら JARROBA_MCP_DOMAINS=logs,core を追加してください。ドメイン：core、calc、diagram、kg、db、ai、logs、queue、project、tests、api、chip、chem、access、archsim、security、experiments、payroll。

置き換えではなく、新しい補完機能：Tool Search

2026 年 1 月以降、Claude Code はデフォルトでツールスキーマ全体の読み込みを遅延し、モデルが検索すると判断したときにのみ読み込むようになりました。Anthropic は自社ベンチマークで、大規模なカタログにおけるコンテキストの大幅な削減を報告しています。ただし、これによって上記のパッケージ分割が無意味になるわけではありません。読み込みを遅延しても、ツールの名前とサーバー独自の instructions はセッション開始時に読み込まれるため、103 個のツールを持つサーバーは 11 個のサーバーよりも基本コストが高くなります。また、すべての MCP クライアントが自動的に読み込みを遅延するわけではありません（明示的にツールを有効にする必要があるクライアントや、古いクライアントなどでは、すべてを最初に読み込みます）。そのため、ここにあるすべてのサーバーには、簡潔な instructions フィールドを設定しています。読み込みが遅延される環境では、このフィールドだけが、そもそもいつここを検索すべきかをモデルに伝えるテキストになります。

インストール

// Claude Desktop (claude_desktop_config.json), Cursor, Cline, VS Code…
{ "mcpServers": {
    "jarroba-logs":  { "command": "npx", "args": ["-y", "@jarroba/mcp-logs"] },
    "jarroba-tests": { "command": "npx", "args": ["-y", "@jarroba/mcp-tests"] }
} }

# Claude Code
claude mcp add jarroba-logs -- npx -y @jarroba/mcp-logs

npx はパッケージをお使いのマシンにダウンロードし、そのマシン上で実行します。何もアップロードされません。

---

ここで実際に異なる点

このカタログの大半は、モデルが間違えやすい算術処理です。そのうち 2 つの部分は、それとは別のものです。

コンテキストに収まらないログを読む

ログツールが受け取るのは、貼り付けたテキストではなくファイルパスです。それがこの仕組みの要点です。本番環境や CI のログは数十 MB、あるいは数百 MB にもなり、ツール呼び出しには収まりません。しかし、サーバーは Node で動作するため、自らファイルを開き、収まる分だけを返せます。CI の失敗をデバッグするエージェントはログを読めませんが、ログについて質問できます。

• log_analyze — 形式、イベントの数（40 行のスタックトレースも 1 件として数えます）、レベル、時間範囲、根本原因を特定したエラー、最も頻出するパターンを返します。
• log_reduce — 文字数の上限内に収まるようにログを切り詰めます。エラーと完全なトレース、その直前の範囲、一度しか現れない内容は残します。繰り返しは [xN] にまとめます。
• log_patterns — 行をテンプレートにグループ化します（Drain）。「connected to 10.0.0.1」と「connected to 10.0.0.7」は同じメッセージとして扱われます。また、通常知りたいことの多いまれなメッセージも返します。
• log_trends — いつ始まったかを、総量ではなく各パターンのそれ自体との比較で答えます。急増したもの、新たに現れたもの、そして現れなくなったものを返します。最後のものはどこにも警告が上がらず、最悪の知らせであることもよくあります。
• log_around — ある時点の前後で、ほかに何が集中していたかを示します。前に始まったことは原因の候補であり、後に起きたことはたいてい結果です。
• log_distinguish — イベントのグループ（デフォルトではエラー）が、残りと何によって区別されるかを示します。グループ内で過剰に現れるフィールドと値の組み合わせを返すため、たとえばすべての失敗に共通するバージョンがわかります。
• log_stacktrace — Java/JVM、Python、Node、Go、.NET、Rust、Ruby、PHP に対応し、Caused by の連鎖、根本原因、自分のコードの最初のフレームを返します。
• log_lint — ログが適切に記述されているかを確認します。秘密情報の出力、ファイルを埋め尽くす 1 行、タイムゾーンのないタイムスタンプ、逆行する時計、リクエスト ID の欠落などを検出します。
• log_convert — JSON／logfmt／syslog 5424／CSV／OpenTelemetry／ECS の間で変換し、変換によって失われる情報を事前に示します。
• log_rotation — ローテーションされたログを時系列順に並べます。ローテーション番号は時系列と逆順になり、アルファベット順では app.log.10 が app.log.9 より前になります。先にこのツールを使わないと、逆順に読んでしまいます。
• log_profile_check／log_profile_suggest — チームのログの形式を記述した、再利用可能なプロファイルです。check は、モデルが修正できるように、各エラーの正確なフィールドをすべて返します。

呼び出し元に異議を唱えるツール

「テストを通して」と言われたエージェントには、バグを診断するか、マッチャーの対象を広げるか、アサーションを削除するか、テストケースをスキップするかという二つの道があります。後者のほうが簡単です。より優れたモデルであっても、これを直すことはできません。プロンプトで丁寧に頼んでも同じです。必要なのは、モデルの外側にある判定役です。このカタログで、呼び出した相手に異議を唱えるために存在するのはこの部分だけです。自分のコードにも実行してください。

• test_audit — テストファイルが実際に何をアサートしているかを、ケースごとに示します。値についてアサートするもの、何かが存在することだけを確認するもの、何もアサートしないもの、無効化されているものを、それぞれの判定の根拠とともに返します。TypeScript、JavaScript、Python、Java、Go に対応します。
• test_diff_audit — 二つのバージョンを比較し、変更によって安全網が弱められたかどうかを示します。マッチャーの対象範囲が広がった、アサーションが消えた、実行されなくなったケースなどを検出します。
• test_cases — 型をもとに、書く価値のあるテストケースを提案します。どの手法が適用されるか、そしてその理由も示します（境界値は順序がなければ意味を持たないため、真偽値には境界値がありません）。また、5 件だけ書く時間がある場合に重要な 5 件も返します。
• test_debt — git blame を使って、無効化されたテストを経過期間とともにすべて表示します。テストランナーにとってこれらのテストは存在しないため、カバレッジレポートにも表示されません。

このツールは軽々しく非難しません。認識できないマッチャーは「アサーションなし」ではなく、**「判定不能」**として返します。チーム独自の expect() がある場合は、dialects で宣言してください。

---

カタログの残り

@jarroba/mcp から利用するか、JARROBA_MCP_DOMAINS を拡張してください。 図表（diagram、8） — JTD AI が図表を作成するための JSON 形式です。diagram_svg は通常の Node 上でレンダリングするため、モデルは描画を実際に確認できます。インクリメンタルビルダー（diagram_new / _add / _preview）を使えば、少しずつ作成してループ内で確認できます。これは、モデルが自身の出力を評価する唯一の方法です。 mermaid_validate は、Mermaid コードをMermaid 独自のパーサー（Web で使用されているバージョン）にかけ、行、列、予期されるトークンとともにエラーを返します。モデルはレンダリングできない Mermaid（引用符で囲まれていない括弧、ID としての end、円グラフ内の % など）を書くことがありますが、パーサーのエラーを確認すれば自力で修正できます。解析のみを行います。パーサーは別ファイルとして初回使用時に読み込まれるため、それまではコストがかかりません。

データベース（db、9） — SQL テキストを正規表現で推測するのではなく、一時的な PostgreSQL（pglite）で DDL を実行して実際のスキーマにします。MySQL／SQLite／SQL Server／Oracle のダンプの変換、設計のレビュー、ドキュメントやエンティティクラスの生成に使用できます。3 つのツールは構造ではなくデータを調べます。実際に行を返す結合経路、データが裏付ける外部キー（推測ではなく件数で確認）、そして見過ごされがちな失敗を検出する行レベルセキュリティのチェックです。さらに、トランザクション内でロールバックされる、指定したロールが実際に何を参照できるかのシミュレーションも行います。 db_query_check はスキーマに対してクエリを実行し、実行できるか、どの列と型が返されるかを確認します。また、compareWith が指定されている場合は、2 つのクエリの結果が異なる最小限のデータ（NULL を含む NOT IN など）を、その INSERT 文とともに見つけます。 db_migration_measure はスキーマに対してマイグレーションを実行し、各ステートメントが実際に取得するロック（pg_locks）や、テーブルを書き換えるか全件スキャンするかを測定して、より安全なバージョン（CONCURRENTLY、NOT VALID + VALIDATE、lock_timeout…）を作成します。ロックレベルを推測する必要はありません。アプリケーションの queries を渡すと、そのマイグレーションによって壊れたり動作が変わったりするクエリも示します。

ナレッジグラフ（kg、4） — SPARQL 1.1、SHACL、そして Oxigraph 上の「コードとしてのセマンティクス」レイヤーを提供します（WASM、サーバー不要）。これにより、「収益」のような指標を、誰かが独自に考えたクエリではなく、合意された定義に基づいて計算できます。

AI に関する AI（ai、6） — 決定論的でモデルを使わないため、ここで役立ちます。AI はモデル呼び出しのコストをかけずに、自身のシステムプロンプトをレビューし、RAG コーパスを準備し、自身の回答を主張と出典の照合にかけ、作成したばかりの評価スイートを検証できます。また、インストールするかどうかを検討している MCP サーバーのカタログを監査し、以前に承認した tools/list を基に「ラグプル」（承認後に変更されたツール）を検出することもできます。さらに、トレーニングで学んだ実践方法を推奨する前に、practice_check が日付付きの登録簿を基に、その方法が現在も有効かどうか、何に取って代わられたのか、いつからか、どの程度確かなのかを知らせます。ナレッジカットオフを指定すると、その後に変わった内容だけが対象になります。

プロジェクト用ワークショップ（project、10） — make を実行せずにシミュレーションし、各ターゲットがなぜ再ビルドされるのかを示します。実際の make ログと予測を比較できます（シミュレーションでは「キャッシュ済み」とされたターゲットが再ビルドされていた場合、未宣言の依存関係があることを示します）。Git を使わずに git check-ignore -v を実行でき、同じファイルについて Git と Docker の判断が異なる箇所も確認できます。また、変更によって無効になる Docker レイヤーも示します。 dora_metrics は gh run list の JSON（およびリードタイム計算用の git log）から 4 つの DORA 指標を算出し、失敗したデプロイが失敗としてカウントされる理由を示します。さらに、2019～2024 年の State of DevOps レポートすべてに基づいてチームを分類し、レポートの表だけでは判定できない場合は「曖昧」と示します。 maven_plan は Maven を実行せずに、プロジェクトで mvn <command> が何を実行するかを示します。リアクターの順序、フェーズごとの実行内容、各ゴールの由来（パッケージング、独自の pom、親、プロファイル）を提示し、実際の mvn ログとゴールごとに照合します。gradle_plan は --dry-run の出力を読み取り、各タスクに対応する Maven の処理を示します。 化学および固体物理（chem、12） — このサーバー全体を象徴する分野です。モデルはクロムの電子配置をでっち上げ、イオン化の際に誤った軌道から電子を取り除き、結合エネルギー（D0）と井戸の深さ（De）を混同します。ここでは、実測値を基準としたオラクルとテストを備えたサービスが、それらの誤りを防ぎます。溶液については、酸、塩基、塩をどのように混ぜても正確な pH と、併記された教科書の公式および誤差（chem_ph）、当量点と最適な指示薬を含む滴定（chem_titration）、塩が沈殿するかどうかと、どれだけ溶けるか（chem_solubility）を扱います。すべての定数には、測定に用いられた論文が付いています。

キューイングとメッセージブローカー（queue、8） — Erlang B と M/M/c を使って、必要なリソースの数、待ち時間、拒否される割合を計算します。さらに、公式を相互検証するためのシミュレーションもあります。モデルが頭の中で誤りやすいブローカーの計算機能は、RabbitMQ と Kafka から移植し、実際の 4.0.5/4.3.6 および 4.3.1 ブローカーに照らして調整しています。RabbitMQ のエクスチェンジがどのキューにルーティングするか、その理由（rabbit_route）、AWS SNS のフィルターポリシーがメッセージを通すかどうか（sns_filter、AWS のドキュメントに基づく）、Kafka のキーがどのパーティションに割り当てられるか（kafka_partition、計算過程付きの murmur2）、コンシューマーグループがパーティションをどう分割するか（kafka_assign：range、roundrobin、sticky、cooperative-sticky）を扱います。

ID／RBAC（access、4） — Azure RBAC、AWS IAM/Organizations、GCP Resource Manager、Kubernetes RBAC のいずれかを模した、ベンダー中立の ID／RBAC モデルです。各ルールは公式ドキュメントに照らして検証されています。access_check は、「このプリンシパルはこのスコープでこのアクションを実行できるか、そしてその理由は何か」に対し、3 値の判定（許可／拒否／判定不能 — モデル化されていない条件が結果を左右する場合は、3 つ目の判定になります）と、どのルールが判定を下したかを示す段階的なトレースで回答します。access_who_can は、候補となるプリンシパルのリストを対象とするその双対機能です。access_diff は同じシナリオの 2 つのバージョン（例：オフボーディング、またはロール割り当ての削除）を比較し、アクセス権を得る人、失う人を報告します。シナリオは world にインラインで渡すため、同期を保つサーバー側のセッションはありません。また、cedar_check は公式の Cedar エンジンで Cedar ポリシー（AWS Verified Permissions）を実行します。解析エラーとスキーマエラーに加え、各リクエストについて、判定を下したポリシーとともに許可／拒否を返します。また、permit が見つからないケースと、forbid が優先されるケースを区別します。

アーキテクチャシミュレーション（archsim、2） — llms.txt の隣にある archsim.md 形式に対応した、Architecture Simulator のエンジンです。archsim_validate はドキュメントを検証し、archsim_simulate はシミュレーションを実行して、スループット、p50/p95 応答レイテンシ（最初のキューまで）、処理レイテンシ、可用性、ボトルネック、1 時間あたりのコスト、キューごとのラグ／「N 秒で満杯」になるまでの時間／気付かれずに失われたメッセージ、およびツールのレポートと同じ調査結果を返します。キューはプル方式（コンシューマーが処理できる分だけ取得）、キャッシュは経路を短縮し、ロードバランサーは負荷を分散し、サービスはすべての依存先を呼び出します。オートスケーリングが反映されるまでには約 1 分かかります。ピーク、DDoS、LLM の停止などを指定する、時間指定の phase をオプションで追加すると、最悪の状況を確認できます。

A/B 実験（experiments、3） — モデルが誤った検定を選ぶ場面です。abtest_analyze は適切な検定（z 検定または Fisher の正確確率検定）を使用し、区間、バリアントがコントロールを上回るベイズ確率 P、Holm/BH 補正を用いた A/B/n を提示し、常にサンプル比率の不一致をチェックします。abtest_sample_size は訪問者数と日数を計画します（R の power.prop.test）。abtest_sequential は、途中で結果を確認する場合の各確認時点における境界を提示します（Pocock、O'Brien-Fleming、Lan-DeMets の消費関数）。テストでは R／ldbounds の参照値と照合済みです。 セキュリティ（security、10） — Web のセキュリティツールと同じエンジンで、エージェントが行動を起こす前に確認すべき項目です。hidden_text_scan は、モデルには文字どおり見えない指示（不可視の Unicode タグ文字、異体字セレクターやビットエンコーディング、双方向制御文字、見た目が似た文字）を見つけてデコードします。paste_check は、ログや HAR に含まれるシークレットをチケットに貼り付ける前に検出し、それぞれがどのリクエストのどのヘッダーにあるかを示して、編集済みのコピーを返します。actions_audit は、注入可能な GitHub Actions ワークフロー、pull_request_target によるチェックアウト、ピン留めされていないアクションを検出します。headers_audit、email_auth_audit（SPF/DKIM/DMARC）、saml_audit は、貼り付けた内容を確認します。agent_config_audit は、エージェント自身の設定、MCP 設定、タスク、指示ファイルを確認し、承認なしで実行されるものを優先して表示します。oauth_audit は、/authorize URL や貼り付けた openid-configuration（あるいはその両方）を RFC 9700 に照らして確認します（PKCE S256、state、nonce、PAR、リダイレクト URI、implicit および password グラント、id_token の「none」など）。k8s_network_reach は、NetworkPolicy に基づいて、どの Pod がどの Pod に到達できるか（接続可能なペアとそのポートのみ）を示し、あるペアがブロックされる理由を説明します。k8s_manifest_check は、クラスターがマニフェストを受け入れるかどうかを示します。対象は、Kubernetes のバージョン（1.33–1.37）の公式スキーマ（不明なフィールドと、意図したフィールドとの違い、型の誤り、削除された API）と、ワークロードおよび名前空間ごとの Pod Security Standards です。また、core の jwt_decode は、トークンを受け入れると危険な要因（alg none、有効期限 exp の欠落、kid インジェクション、ヘッダー内の鍵、さらに鍵を指定した場合はアルゴリズム混同や短い HMAC シークレット）も警告するようになりました。渡した内容を静的解析するだけです。何も取得せず、何も実行しません。

汎用（core、32） — CIDR／サブネット分割、実際のトークナイザーを使ったトークン数のカウント（OpenAI のものに加え、Qwen3 と Mistral はローカルで実行し、Claude は実測に基づく推定を行います）、ハッシュ、JWT のデコード、正規表現（静的な ReDoS チェック regex_redos_check を含む）、スプレッドシート数式の監査（spreadsheet_audit：.xlsx／.ods を再計算し、古い値や循環参照を検出）、サイズを問わないキーによる CSV 差分（csv_diff：不足、余分、変更のある行と、該当する列を示します）、タイムスタンプ、cron、色、WCAG コントラスト、chmod、JSON の差分、単位（kB と KiB）、ハミング、IEEE-754、基数変換、プログラマー向け計算機、semver、形式変換、Unicode、そして json_schema_validate（実際の JSON Schema（draft 2020-12／2019-09／07）に照らして JSON ドキュメントを検証し、すべてのエラーについて JSON Pointer を示します。独自の構造化出力を確認できます）。

base_convert（ローカライズされた名称で基数 2–64 に対応）は、サービスが LOCALE_ID に依存するため、ここにはありません。number_bases ですでに 2／8／10／16 に対応しています。

---

プライバシーと、正直な脅威モデル

通信は stdio で行われ、すべてローカルで処理されます。 サーバー、ネットワーク、テレメトリーはありません。

あとで知るより先に知っておくべきことが 2 つあります。

• パスを受け取るツールは、呼び出し元のプロセスが読み取れるものなら何でも読み取ります。 それが設計上の目的です。200 MB の CI ログを扱えるようになるのはそのためであり、ローカルの stdio 環境ではサーバーはあなたとして実行されるため、パスはあなた自身のファイルを指します。しかし、プロンプトインジェクションが起きると呼び出し元はもはや信頼できません。実態に即して扱ってください。これらのツールは、起動したプロセスと同じ権限を持ちます。
• ツールが返す内容は、モデルのコンテキストに入ります。 悪意あるテキストを含むログファイルは、Web ページと同じように間接的なプロンプトインジェクションの経路になります。ここでそれをサニタイズするものはなく、サニタイズすることもできません。

すべてのツールは MCP の annotations を宣言しており、ホスト側で段階的な確認を適用できます。ほとんどのツールは readOnlyHint: true, openWorldHint: false です。例外も正直に宣言しています。パスを受け取るツールは openWorldHint: true です（結果は引数ではなくディスクから取得されます）。また、ファイルに書き込むのは diagram_render だけです。アノテーションは UI 向けのヒントであり、セキュリティ機構ではない点に注意してください。仕様自体にも、クライアントは信頼すると判断していないサーバーのアノテーションを信頼してはならないと記されています。

jarroba.com の記事：独立したリモートサーバー

jarroba.com の記事の検索と閲覧は、意図的にこれらのパッケージには含まれていません。ネットワークが必要で、ここにあるものはすべてローカルで実行されるためです。このサイトでは、独自のリモート MCP サーバー（Streamable HTTP、JSON レスポンス、読み取り専用、アカウント不要）として提供されています。

https://jarroba.com/wp-json/jarroba/v1/mcp

2 つのツールがあります。jarroba_search（テキスト、言語、カテゴリー、シリーズ、または最新の記事から検索）と jarroba_article（リンクと CC BY-NC-SA 3.0 の帰属表示を含む要約）です。IP ごとにレート制限があります。 Claude Code では、claude mcp add --transport http jarroba https://jarroba.com/wp-json/jarroba/v1/mcp を実行します。 上記のパッケージとは異なり、ここで検索した内容は jarroba.com に送信されます。

開発

cd mcp
npm install
npm run typecheck     # types for the server and its tests
npm test              # smoke: starts the server and calls the tools (222 checks)
npm run test:paquete  # packs, INSTALLS outside the repo, and checks all three packages (~2 min)
npm run catalogo      # the per-domain tool counts, derived

npm test と npm run test:paquete は互換性がありません。その教訓を得るのに、ツールが 7 つ壊れました。 npm test はチェックアウト内から tsx でサーバーを実行し、隣に node_modules があるため、インストール後に初めて発生する問題を構造上検出できません。バンドルに含まれないアセット、ディスク上の独自ファイルを探すインライン化された依存関係、リポジトリを基準に解決されるパスなどです。213 件のチェックが成功している一方で、公開パッケージでは 7 つの db_* ツールが壊れていました。しかも、その問題でプロセスも終了し、つまりセッション全体が停止しました。test:paquete はパッケージを作成し、一時ディレクトリにインストールして、インストール済みのバイナリと通信します。外部依存関係ごとに 1 つのケースがあり、最後にセッションがまだ稼働しているかを確認します。プロセスを終了させるツールは成功（応答した）と報告し、残り 84 個をすべて停止させるためです。

ツールを追加するには、そのサービスをインポートして登録し、src/catalogo.ts で対応するドメインに追加します。登録されたツールにドメインが宣言されていない場合、サーバーは起動を拒否します。この仕組みによって、この README の件数も正確に保たれます。

ライセンス

MIT — LICENSE を参照してください。