Global Executables

Global Executables

公開する前に、CLI コマンド名がすでに使われているか確認しましょう。
AI エージェントやブラウザーから、npm、PyPI、crates.io、Go modules、Homebrew、 Debian などの実行ファイル名を検索できます。

プレイグラウンドを試す · MCP サーバーをインストール · ドキュメントを読む · データを確認する

このツールが作られた理由

パッケージ名と、インストールされるコマンド名は必ずしも同じではありません。 パッケージ名をレジストリで検索しても、別の名前のパッケージが提案したコマンドを すでに提供しているといった衝突を見落とすことがあります。

このインデックスは、重要な関係性を保持します。

command → provider → package → ecosystem → source evidence

今すぐ試す—インストール不要

**インデックスプレイグラウンド**を開き、 名前の確認、類似コマンドの検索、提供元の調査、ソースの網羅状況の確認ができます。 プレイグラウンドは MCP サーバーと同じ公開 JSON データセットを読み込み、 クエリデータがサードパーティ API に送信されることはありません。

AI を活用して確認するには、以下の MCP サーバーに接続して、次のように尋ねます。

I am naming a new CLI. Check `envc`, `evcr`, `evpk`, and `envcp` for exact
collisions and confusingly similar commands. Keep rejected names internal and
explain the coverage caveat for every survivor.

エージェントは、パッケージ名の検索に頼らず、証拠を示して envcp を却下できます。 このコマンドは PyPI 上の chaperone と envcp の両方から提供されています。

利用できる機能

このサーバーに書き込みツールはなく、見つかったソフトウェアをインストールしたり実行したりすることもありません。

クイックスタート

1. uv をインストールする

推奨セットアップでは、uv を使用します。 このリポジトリのクローン、データセットのダウンロード、API キーの作成は不要です。

uvx が利用できることを確認します。

uvx --version

2. MCP サーバーを追加する

以下からクライアントを選択してください。初回起動時に PyPI からパッケージをダウンロードし、2 回目以降の起動では uv のキャッシュを再利用します。

{
  "mcpServers": {
    "global-executables": {
      "command": "uvx",
      "args": ["global-executables", "mcp"]
    }
  }
}

claude mcp add global-executables -- uvx global-executables mcp

codex mcp add global-executables -- uvx global-executables mcp

{
  "servers": {
    "global-executables": {
      "type": "stdio",
      "command": "uvx",
      "args": ["global-executables", "mcp"]
    }
  }
}

{
  "command": "docker",
  "args": ["run", "-i", "--rm", "ghcr.io/asopitech-labs/global-executables-mcp:latest"]
}

3. エージェントに質問する

次のプロンプトを試してください。

Is the command name `envc` already taken? Check similar names too.

Check `envc`, `evcr`, `evpk`, and `envcp` as possible CLI names. Do not show
rejected candidates; explain the dataset coverage for the survivors.

Which package provides the `ruff` executable, and how should I install it in a
Python 3.12 project virtual environment?

通常、エージェントは一括処理に check_executables を、残った候補の検索に search_similar_executables を呼び出します。

重要

found: true は衝突があることを意味します。found: false は、現在の スナップショットに一致するものがないことだけを意味します。status が unknown の場合、 ソースのカバレッジが不完全なため、その名前が利用可能だと証明されているわけではありません。 名前を採用する前に、warnings、absence.confidence、coverage_scope を確認してください。

仕組み

スナップショット検索では、クエリに必要な公開 dictionary ブランチのファイルのみを取得し、 現在のユーザーのキャッシュディレクトリに保存して、ETag で再検証します。 ネットワークが一時的に利用できない場合も、キャッシュ済みファイルを引き続き使用できます。

uvx global-executables mcp --help では、同じオプションをフラグとして確認できます。このパッケージは リリース 1.3.0 から PyPI に公開されています。HTTP トランスポート、オフラインでの動作、 ソースチェックアウトからの実行については、MCP guide を参照してください。

MCP ツール一覧

スナップショット検索ツールは読み取り専用です。discover_published_package は、範囲を限定したレジストリおよびアーティファクトへのライブリクエストを実行しますが、パッケージコードは実行しません。Git 書き込みアクセスが設定された指定ランナーでは、検証に成功すると、中央で再検証するための不変な intake/<id> ブランチも確保されます。結果には reservation.status が報告されます。設定されていないコピーでは unavailable が報告され、公開済みであるとは主張しません。MCP も CLI も、公開済みの辞書に直接書き込みません。 リポジトリの Verify and reserve published package discovery GitHub Actions ワークフローが指定ランナーです。このワークフローは、コレクターの前に CLI と MCP の両方を呼び出します。インストール解決ツールは手順を返すだけで、ソフトウェアのインストールや実行は行いません。入力全体と結果の仕様については、MCP ガイドを参照してください。

定期実行される取り込みコレクターは、確保された証拠を検証して再確認してから、artifact-data にマージします。定期更新のみが、引き続き辞書ブランチへの書き込みを行います。ランナーの設定と予約のライフサイクルについては、MCP ガイドを参照してください。

対応エコシステム

各プロバイダーは、ソースと信頼度レベル（direct、filesystem、inferred）を保持します。網羅状況はエコシステムによって異なるため、否定的な結果には明示的な網羅性メタデータが付与され、すべてのレジストリが完全に網羅されているかのような扱いはしません。収集の詳細についてはデータソース、結果の仕様については網羅状況と鮮度を参照してください。

ドキュメント一覧

トラブルシューティング

目標

Global Executables は、次の提供を目指しています。

• 実際に使われている実行可能ファイル名の公開データセット。
• 複数エコシステムにわたるカバレッジ。
• 収集したすべての実行可能ファイルについて追跡可能な出典情報。
• 再現可能なデータセット生成。
• Git に適した構造化データ。
• 効率的な検索のための機械可読インデックス。
• 実行可能ファイル名の履歴追跡。
• AI エージェント向けの MCP アクセス。
• データセットのカバレッジと鮮度に関する明示的な情報。

データセット自体が主要な成果物です。

MCP サーバーは、その公開データにアクセスするためのレイヤーであり、信頼できる情報源ではありません。

ライブ版の Index Playground では、クロールの進捗を確認し、読み取り専用の check、search、similar、coverage、assess クエリをブラウザーから直接実行できます。プレイグラウンドは、公開 JSON データセットを利用する静的な GitHub Pages クライアントです。クエリデータがサードパーティ API に送信されることはありません。

プログラムと公開データは、それぞれ独立したライフサイクルを持ちます。プログラムのソース、スキーマ、テスト、ドキュメントは main にあり、生成された JSON 辞書は orphan dictionary ブランチにあります。安定した生データのベース URL は次のとおりです。

https://raw.githubusercontent.com/asopitech-labs/global-executables/dictionary

ブランチの契約、ローカル設定、main URL の切り替えについては、dictionary ブランチの移行に関する注記を参照してください。

Go の開発は、JetBrains Modern Go Guidelinesに従います。バージョン管理されたレビュー、ビルド、テスト、セキュリティ、リリースのワークフローについては、Go クローラーの開発およびビルドの契約を参照してください。

アーキテクチャ

Package ecosystems
        │
        ├── Debian / Ubuntu
        ├── Arch Linux
        ├── Homebrew
        ├── npm
        ├── PyPI
        ├── crates.io
        ├── Go modules
        ├── RubyGems
        ├── Packagist / Composer
        ├── ConanCenter
        ├── vcpkg
        ├── xmake-repo
        └── others
                │
                ▼
          GitHub Actions (`main`)
                │
       collect / normalize
                │
                ▼
  `dictionary` branch dataset
                │
        ┌───────┴────────┐
        │                │
        ▼                ▼
   GitHub / raw        MCP Server
      data                │
                          ▼
                     AI agents

GitHub Actions は定期的に上流のパッケージ情報を収集し、実行可能ファイルのレコードを正規化し、インデックスを再生成してデータセットを検証した後、生成されたファイルを公開します。

データモデル

正規の単位は実行可能ファイル名です。

各実行可能ファイルは、既知のプロバイダーを含む構造化ファイルで表されます。

概念的には次のとおりです。

{
  "command": "example",
  "providers": [
    {
      "ecosystem": "example-ecosystem",
      "package": "example-package",
      "version": "1.0.0",
      "repository": "https://example.com/repository",
      "source": "example-source",
      "confidence": "direct"
    }
  ],
  "first_seen": "2026-08-14",
  "last_seen": "2026-08-14"
}

1 つの実行可能ファイルが、複数のエコシステムにまたがる複数のプロバイダーを持つ場合があります。

リポジトリ構成

dictionary ブランチには公開済みの成果物のみが含まれます。

dictionary/
├── data/
│   ├── executables/
│   │   ├── en/
│   │   │   ├── envc.json
│   │   │   └── envcp.json
│   │   └── gi/
│   │       └── git.json
│   │
│   ├── indexes/
│   │   ├── prefix/
│   │   ├── length/
│   │   ├── ecosystem/
│   │   └── trigram/
│   │
│   ├── metadata.json
│   └── history.json
└── reports/
    ├── production-crawl.json
    └── production-refresh.json

main ブランチには別途、fixtures/、schema/、src/、tools/、 tests/、docs/、playground/、および .github/workflows/ が含まれます。上記の生成済みパスは追跡しません。正規データセットには通常の構造化ファイルを使用しており、データベースサーバーは不要です。

派生インデックスは再現可能であり、正規の実行可能ファイルのレコードから再生成できます。

検索

完全一致検索は、リポジトリ構造に直接対応します。

たとえば、次のようになります。

envcp
  ↓
prefix: en
  ↓
data/executables/en/envcp.json

これにより、利用者は一元管理されたデータベースをダウンロードしたり、クエリしたりすることなく、個々のレコードを取得できます。

派生インデックスは、次のような、より広範なクエリをサポートします。

• プレフィックス；
• 実行可能ファイルの長さ；
• エコシステム；
• 類似した名前。

データソース

各エコシステムの収集処理は独立しています。

情報源として、次のものが考えられます。

C と C++ には単一のレジストリがないため、代わりに3つのレシピリポジトリを参照し、それぞれが実際に保持している最も確かな根拠を採用します。vcpkg は、ポートがインストールするツールの名前を指定します。名前の指定によってツールがインストールされるためです。ConanCenter のレシピは実行可能ファイルの名前を指定しないため、ビルド済みパッケージ自体のファイル一覧を参照します。xmake はパッケージがバイナリーであることを宣言しますが、そのバイナリーの名前は指定しません。そのため、xmake のレコードには inferred と記され、宣言として扱うべきではありません。これら3つのいずれも「網羅的」ではありません。vcpkg のポートはコマンドを宣言せずにインストールすることがあり、誰もビルドしていない ConanCenter のレシピからはインストールされるファイルについて何も分からず、xmake のパッケージは別の名前でコマンドをインストールすることがあります。

このプロジェクトでは、すべての観測結果を同じ信頼性のものとして扱うのではなく、各実行可能ファイルをどのように発見したかを記録します。

信頼度

レコードには、実行可能ファイル名がどのように確定されたかを示す信頼度レベルが付与されることがあります。

たとえば、次のようになります。

direct
filesystem
inferred

direct は、実行可能ファイルがパッケージのメタデータで明示的に宣言されていることを意味します。

filesystem は、パッケージの内容にインストール済みの実行可能ファイルが確認されたことを意味します。

inferred は、間接的に推定されたことを意味し、信頼度を低く見積もる必要があります。

利用者はこの情報を使い、名前が衝突する可能性がある場合に、それが重大かどうかを判断できます。

インストールガイダンス

resolve_installation と resolve_installations は、環境固有のインストールガイダンスを提供します。エージェントはこれらの MCP ツールを直接呼び出せます。また、利用者は同じターゲットコンテキストを ブラウザー版 Playground で入力できます。CLI では、ローカルの辞書を使ってリゾルバーを実行することもできます。

global-executables resolve-installation pygo --root ./dictionary \
  --environment '{"package_manager":"pip","runtime_version":"3.12","install_scope":"project","virtualenv_bin":"./.venv/bin"}'

MCP ガイドでは、必須のターゲットコンテキストと installation-v1 の結果コントラクトについて説明しています。ターゲット固有のインストールと実行による検証がないガイダンスには、unverified と記されます。 手法の検証記録では、テスト済みのパッケージマネージャー構文と、テストされていないパッケージ ID を区別しています。

エージェントのワークフロー

命名エージェントは、CLI 名の候補を提示する前に Global Executables を使用する必要があります。

推奨ワークフロー：

Generate candidate names internally
            │
            ▼
     check_executables
            │
            ▼
 Separate `found:true` collisions from `found:false` observations
            │
            ▼
 search_similar_executables for not-found candidates
            │
            ▼
 Remove confusing candidates
            │
            ▼
 Present surviving names

却下した候補をユーザーに提示する必要はありません。

このサービスの目的は、衝突チェックを手動の後続タスクではなく、エージェントの通常の推論ワークフローに組み込むことです。

結果の意味

データセットに含まれていないからといって、その実行可能ファイル名がこれまで使われたことがないと証明されるわけではありません。

そのため、結果では事実として確認できた内容と、不在である確信度を区別します。

collision
clear_in_index
unknown

たとえば：

{
  "name": "evpk",
  "found": false,
  "status": "unknown",
  "snapshot": "2026-10-19",
  "coverage_scope": "unknown",
  "checked_sources": [
    "arch",
    "crates",
    "debian",
    "go",
    "homebrew",
    "npm",
    "pypi",
    "ubuntu"
  ],
  "searched_sources": [
    "arch",
    "crates",
    "debian",
    "go",
    "homebrew",
    "npm",
    "pypi",
    "ubuntu"
  ],
  "coverage": {
    "arch": {
      "status": "success",
      "coverage_kind": "exhaustive",
      "records": 1647,
      "source": "data/production/intermediate/arch.jsonl"
    },
    "npm": {
      "status": "success",
      "coverage_kind": "partial",
      "records": 127,
      "source": "data/production/intermediate/npm.jsonl",
      "scope": "ecosyste.ms critical npm population covering 80% of downloads or dependent repositories",
      "catalog_complete": true,
      "catalog_packages": 2295,
      "catalog_snapshot": "2026-10-18",
      "catalog_source": "https://packages.ecosyste.ms/critical?registry=npmjs.org",
      "catalog_digest": "sha256:4b610ce561d63b72b7a4137ed75ba5ecbec5fbafda236218fc4264c92db605b3"
    }
  },
  "warnings": [
    {
      "code": "npm_coverage_incomplete",
      "ecosystem": "npm",
      "message": "npm coverage is incomplete or limited to a declared population. A missing result is not proof that no npm package uses this executable and is not permission to adopt the name.",
      "coverage": {
        "status": "success",
        "coverage_kind": "partial",
        "source": "data/production/intermediate/npm.jsonl",
        "scope": "ecosyste.ms critical npm population covering 80% of downloads or dependent repositories",
        "catalog_complete": true,
        "catalog_packages": 2295,
        "catalog_snapshot": "2026-10-18",
        "catalog_source": "https://packages.ecosyste.ms/critical?registry=npmjs.org",
        "catalog_digest": "sha256:4b610ce561d63b72b7a4137ed75ba5ecbec5fbafda236218fc4264c92db605b3"
      },
      "reference": "https://github.com/asopitech-labs/global-executables/issues/54"
    }
  ],
  "absence": {
    "status": "not_found_in_current_index",
    "confidence": "insufficient_coverage",
    "searched_sources": [
      "arch",
      "crates",
      "debian",
      "go",
      "homebrew",
      "npm",
      "pypi",
      "ubuntu"
    ]
  }
}

found:false は、その名前が現在のインデックスで見つからなかったことを意味します。unknown は、利用可能なカバレッジが不在を網羅的に断定するには不十分であることを意味します。クエリが利用できなかったという意味ではありません。clear_in_index は、クエリ対象のスナップショット内のすべてのソースが coverage_kind: exhaustive であり、実行が成功し、有限の母集団制限（scope または catalog_* フィールド）がない場合にのみ返されます。npm のクリティカルカタログが完了すると catalog_complete: true が設定され、coverage_kind: partial のままとなります。これによってスナップショットが網羅的になることはありません。npm のカバレッジが不完全な場合は、npm_coverage_incomplete 警告も追加されます。これらのステータスはいずれも、名前を採用してよいという許可を意味しません。

coverage オブジェクトには、ソースごとの収集ステータス、カバレッジの種類、レコード数が記録されます。この例では代表的な 2 つのソースを示しています。実際のレスポンスにはスナップショット内のすべてのソースが含まれます（各ソースの入力パスが含まれる場合もあります）。

これは、その名前が法的に、あるいは世界的に利用可能であることを保証するものではありません。

カバレッジと鮮度

データセットのメタデータには、次の情報が記録されます。

• 生成タイムスタンプ；
• スナップショット識別子；
• インデックス化された実行可能ファイルの数；
• 有効なコレクター；
• 各上流ソースの鮮度；
• コレクターのステータス。

これらの情報は、構造化データとしても MCP 経由でも利用できます。

そのため、エージェントはインデックスを完全だと決めつけるのではなく、検索結果の信頼性を評価できます。

信頼できる情報源としての GitHub

Global Executables は、正規データをリポジトリの orphan dictionary ブランチに意図的に保持しています。

これにより、次のことが可能になります。

• 透明性のあるデータ来歴；
• レビュー可能な変更；
• 再現可能な生成；
• 履歴の追跡；
• フォークとミラー；
• raw ファイルへの直接アクセス；
• MCP サービスの可用性からの独立。

ホストされた MCP エンドポイントが消失しても、データセットは引き続き利用できます。

サードパーティは、リポジトリから直接、別の MCP サーバー、検索エンジン、CLI、または分析ツールを構築できます。

自動化

GitHub Actions がデータセットを管理します。

一般的なパイプラインは次のとおりです。

scheduled / manual trigger
          │
          ▼
     run collectors
          │
          ▼
       normalize
          │
          ▼
        merge
          │
          ▼
 generate executable files
          │
          ▼
    generate indexes
          │
          ▼
       validate
          │
          ▼
        publish

コレクターには実際の収集ロジックを含め、GitHub Actions から独立させる必要があります。これにより、ローカルで実行およびテストすることもできます。

開発中は、互換性のある GitHub Actions ワークフローをローカルで実行するために act を使用できます。

Global Executables ではないもの

Global Executables は、次のものではありません。

• 商標検索サービス；
• ブランド名の利用可能性を確認するサービス；
• パッケージレジストリ；
• パッケージマネージャー；
• 脆弱性データベース；
• ソフトウェアカタログ；
• 未使用の名前が法的に利用可能であることの証明。

Global Executables が答えるのは、より限定的な次の問いです。

データセットが対象とするソフトウェアエコシステム全体で、使用されていることが知られている実行可能ファイル名は何ですか？

商標、会社名、ドメイン、リポジトリ名、およびウェブ全般の検索は、引き続き別途確認する必要があります。

想定される用途

CLI の命名以外にも、このデータセットは次の用途に活用できます。

• CLI 命名アシスタントの自動化；
• リポジトリの CI ポリシー；
• パッケージ公開時のチェック；
• エコシステム内の衝突分析；
• 実行可能ファイルの検索；
• CLI エコシステムの歴史的な調査；
• IDE および開発者向けツールとの連携；
• AI エージェントの事前チェック。

プロジェクトの原則

まず公開データ、次に MCP。

Global Executables の価値は、特定のサーバー実装に左右されません。

長期的に価値を持つ資産は、オープンに利用でき、再現可能な、エコシステム横断の実行可能ファイル名データセットです。

MCP によって、そのデータセットをエージェントがすぐに活用できます。

現在の実装

スキーマ、決定論的ビルダー、本番用 OS インデックスコレクター、派生する プレフィックス／長さ／エコシステム／トライグラムおよび論理スコープの インデックス、コレクターパーサー、検証済み npm/PyPI 検出用の Git 取り込み機能を備えた ローカル／HTTP MCP サーバー、評価 API、範囲を限定したフィクスチャの鮮度シナリオ、および CI チェックが このリポジトリに実装されています。カバレッジは 各ソースに対して測定されます。npm は、有限の ecosyste.ms クリティカルカタログが完了しても （catalog_complete: true）、coverage_kind: partial のままです。全レジストリにまたがる npm の ロングテールはインデックスに含まれていません。正確な命名、シャーディング、エイリアス、および 履歴のルールについては docs/DATA_MODEL.md を、再現可能な コマンド、鮮度状態のシナリオ、および実測カバレッジの正直な制限については docs/OPERATIONS.md を参照してください。

セットアップなしで使うには、クイックスタートを参照してください。ネットワークに接続せずに 固定スナップショットをクエリするには、プログラムをインストールし、公開済みブランチを別の ワークツリーに展開して、サーバーからその場所を指定します。

python -m pip install -e .
git fetch origin dictionary
git worktree add .dictionary origin/dictionary
global-executables-mcp --root . --dataset-root .dictionary

リモートアクセスには --transport streamable-http を使用してください。どちらのモードも check_executable、check_executables、get_executable、 search_executables、search_similar_executables、get_coverage、 assess_executable、および assess_executables を公開します。どちらの モードも書き込み機能は公開しません。MCP を実行せずに、dictionary ブランチから 正規 JSON を直接読み取ることで、リポジトリのライセンスに基づいてデータを再利用できます。 ローカルクライアントの設定、リモートエンドポイント、リソース、健全性の可視性、およびサバイバーのみを対象とする エージェントのワークフローについては、docs/MCP.md を参照してください。

手動のフィクスチャワークフローでは、範囲を限定した増分鮮度スキャンを実行します。 不変のテストパーティションを順に処理し、カーソルと最後に成功した観測結果を freshness-data ブランチに保存して、機械可読なテストレポートを公開します。これは本番環境の鮮度処理でも、 データセット全体の更新でもありません。カバレッジはスナップショット固有のものであり、get_coverage によって 報告されます。公開済みスナップショットには、本番用 OS/Homebrew のカバレッジ、完了済みだが部分的な npm クリティカルカタログ（レジストリ全体を網羅するものではない catalog_complete）、および PyPI や Go などの他のレジストリの部分的なカバレッジが含まれます。これはエコシステム全体を網羅するものではないため、 利用側は clear_in_index／unknown の意味と npm_coverage_incomplete 警告を 維持する必要があります。

レジストリアーティファクトの検査は、個別に再開できます。CI は有限の npm クリティカルカタログを更新し、毎日 100％までクロールします。一方、専用のローカルコンテナーは PyPI と Go モジュールのカーソルを進め、チェックポイントを artifact-data に公開します。これらのローカル コンテナーは完了を一時的に促進するもので、100％に達すると停止します。ソースが 100％に達すると、6 時間ごとの GitHub Actions マトリックスが、永続化された更新カーソルを使って インデックス済みの全パッケージを順に処理します。成功した結果は、より新しいリリースで削除されたコマンドも含め、 古いパッケージ観測結果を置き換えます。CI はさらに、1 日 1 回 crates.io のダンプの変更を確認し、 変更があった場合にのみダンプをダウンロードします。CI リフレッシャーは、正規化済みの観測結果に変更があった場合にのみ辞書の再構築をディスパッチし、 クロールの進捗を公開するたびに Pages を再デプロイします。Go モジュール、npm、PyPI、RubyGems、および Packagist は トランザクション型の Go ランタイムを使用します。これらの bbolt 状態では、カーソル、リトライ判定、および観測結果が まとめてコミットされます。CI は npm の範囲限定の対象集団を再生成します。 PyPI、RubyGems、および Packagist はサンプリング済みカタログを再利用し、Go はインデックスを拡張します。 宣言されたカタログを完了すると catalog_complete が設定される場合があります。npm は、そのカタログだけを根拠に coverage_kind: exhaustive へ昇格することはありません。他のソースは、有限の対象集団による制限がなく、宣言されたカタログと 必須のアーティファクト検査が正常に完了した場合にのみ、exhaustive になります。 収集に成功しただけでは、衝突がないと断定できません。 有効なクエリはすべて、事実に基づく found の観測結果を返します。フィクスチャ、スモークテスト、および部分的なスナップショットでは、名前が見つからない場合に不在を確信するには不十分です。clear_in_index を返すには、クエリ対象のスナップショット全体が網羅的であることをメタデータで明示する必要があります。派生検索インデックスはメタデータ内で整合性が固定されており、プレフィックス、長さ、エコシステム、および類似性に関するクエリで直接使用されます。

クリーンチェックアウトからのセットアップ、クライアント設定、想定される応答、および検証手順については、docs/SETUP.md を参照してください。

Issue の完了とリリースの証跡については、docs/RELEASE.md に従ってください。実装に関する主張だけでは作業は完了しません。

データソース、そのライセンスと利用規約、および必要な帰属表示については、docs/DATA_SOURCES.md に記載されています。