osFoundry / Platform
コネクタ
プラットフォームが対応するすべての連携先のカタログ ― 公式とコミュニティの両方。
概要
コネクタは、ワークスペースから利用できるすべての連携を一つにまとめた osFoundry のカタログです。扱う対象は二種類あります。一つは API コネクタで、OAuth、APIキー、bearer、basic のいずれかの認証を挟んだ外部の HTTP API を指します。もう一つは MCP サーバーで、Model Context Protocol に対応したツールを、端末上でローカルに動かすか、HTTP 経由でホスト型として利用します。連携先を複数の設定画面に散らばせるのではなく、閲覧画面ではすべてをカテゴリー別にまとめています。AIプロバイダー、生産性、コミュニケーション、開発ツール、ストレージ、ソーシャル、そして MCP といった区分に加えて、名前、説明、タグを対象にしたライブ検索を備えているので、実際に探すときの感覚のまま目的の機能にたどり着けます。
osFoundry の中では、このカタログは固定された一覧ではありません。Discover パネルはアプリ内から公式の MCP レジストリを検索するので、「いま持っているもの」のすぐ隣に「これから追加できるもの」が並びます。クエリを入力するか GitHub リポジトリの URL を貼り付けると、osFoundry はそれを README からの推測ではなく、構造化されたインストール可能なサーバー定義（コマンド、引数、必要な環境変数）へと解決します。レジストリへの公開は許可を要しないため、各結果には出所が示されます。検証済みネームスペースのバッジは、公開者が自分の身元を証明したこと（io.github.* ネームスペースなら GitHub OAuth、ドメインなら DNS/HTTP による証明）を伝えます。これはインストール前に、正規のサーバーとタイポスクワットを見分けるためにまさに必要な手がかりです。カードには、サーバーが端末上で動くか（stdio）ホスト型か（HTTP）、そしてすでに追加済みかどうかが表示されます。
この仕組みが効いてくるのは、osFoundry が BYOK かつローカルファーストだからです。自分のアカウントを自分の認証情報でつなぐため、再販業者の上乗せはありません。秘密情報は OS のキーチェーンに置かれ、コネクタ定義やモデルに送られるコンテキストに入ることはありません。コネクタがひとたび用意されると、エージェントとワークスペースのアプリは、管理者が制御し監査可能なプロキシを通してそれを使います。アプリはネットワークへ直接アクセスせずに動き、connector.call() を呼び出すので、外向きの各リクエストはアプリのマニフェストと照合され、ログに残ります。アップデート検出は、インストール済みのレジストリサーバーに新しいバージョンが出たことを知らせ、新しいコードを黙って再実行することはありません。コマンドやサーバー URL が変われば、最初のインストールと同じ明示的な同意を改めて求めます。
主な機能
- すべての連携を一つのカタログで閲覧できます。API コネクタと MCP サーバーをカテゴリー別（AIプロバイダー、生産性、コミュニケーション、開発ツール、ストレージほか）にまとめ、名前、説明、タグを横断して検索できます
- 公式 MCP レジストリ（registry.modelcontextprotocol.io）のコミュニティサーバーをアプリ内から直接発見でき、GitHub リポジトリの URL を貼り付ければインストール可能なサーバーへと解決します
- インストール前に公開元がわかります。検証済みネームスペースには検証バッジ（GitHub OAuth または DNS/HTTP による証明）が付き、正規の公開者と、誰でも公開できるコミュニティ登録とを見分けられます
- 端末上で子プロセスとして動くローカル（stdio）サーバーと、プラットフォームが仲介するホスト型（HTTP）サーバーのどちらもインストールできます。認証情報は OS のキーチェーンに残り、コネクタ定義には入りません
- 自分のアカウントを自分のキー（OAuth、APIキー、bearer、basic）でつなぎます。再販業者の上乗せはなく、エージェントやアプリは管理者が制御する監査可能なコネクタプロキシ経由でそのツールを呼び出せます
活用例
- ワークスペース管理者: Twitter/X や Salesforce の API コネクタを一度だけ設定（ベースURL、OAuthスコープ）しておけば、ワークスペース内のすべてのアプリとエージェントが、各ユーザーが認証情報を用意しなくてもプロキシ経由でそれを呼び出せます
- 開発者やパワーユーザー: MCP サーバーの GitHub URL を貼り付け、検証済みの io.github ネームスペースであることを確認し、ローカルの stdio サーバーとしてインストールして、そのまますぐにチャットからツールを呼び出せます
- プライバシーを重視するチーム: API キーを OS のキーチェーンに保管し、端末上のローカル MCP サーバーを動かすことで、データも認証情報もマシンの外に出さずに、コミュニティの連携を一つのカタログで閲覧できます
よくある質問
ここでの API コネクタと MCP サーバーの違いは何ですか
API コネクタは、特定の外部 HTTP API を認証方式（OAuth、APIキー、bearer、basic）で包んだもので、通常はワークスペース管理者が一度作成し、その後アプリやエージェントがコネクタプロキシ経由で呼び出します。MCP サーバーは Model Context Protocol でツールを公開するもので、端末上で子プロセスとしてローカルに動く（stdio）か、HTTP 経由で到達するホスト型のどちらかです。両者は同じカタログに API か MCP のタグ付きで現れるので、まとめて閲覧できます。
コミュニティのコネクタはどこから来るのですか、また安全ですか
Discover パネルは公式の MCP レジストリ（registry.modelcontextprotocol.io）を検索します。ここには誰でも公開できます。osFoundry は、公開者のネームスペースが検証済みのとき（io.github.* 名なら GitHub OAuth、ドメインなら DNS/HTTP による証明）に検証バッジを表示します。これは誰が公開したかを証明するものであって、そのコードが安全であることを保証するものではありません。そのため、インストール前に公開者を確認することが前提になります。ローカルサーバーは自分のマシンで動き、必要な環境変数はあらかじめ表示されます。
認証情報はどこに保存されますか
秘密情報がコネクタ定義に保持されたりモデルに送られたりすることはありません。カタログが持つのは変数名やヘッダー名だけで、その値は持ちません。ローカルの MCP サーバーでは、認証情報は OS のキーチェーンに置かれます。API コネクタの認証情報は、プロキシがアプリに代わってリクエストを送る際に認証ヘッダーを組み立てるためだけにサーバー側で復号され、そのリクエストはアプリのマニフェストと照合され監査可能です。これは osFoundry が BYOK かつローカルファーストであることと一貫しています。