Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Proposal: optional per-server authentication for remote MCP pipelines

オープン
  • 何か問題がありますか？
#522 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
api, authentication, backend

調査の方向性

Look at the build() and load_pipeline_context() functions to see how remote MCP server URLs are passed to mcp-remote. The issue mentions PR #425 which touched remote MCP configuration; review its changes. Determine if the existing bridge or a FastMCP-native transport is used. A synthetic local authenticated MCP service test is proposed as a follow-up.

索引モデルが issue の本文から書いたものです。

説明

Is your feature request related to a problem? Please describe.

UltraRAG accepts HTTP(S) MCP server paths in a pipeline. In the current build() and load_pipeline_context() paths, the remote client configuration passes the URL to mcp-remote without a per-server authentication option. A user who has an authenticated remote MCP service therefore has no documented way to supply its Bearer header through the pipeline configuration. This is a source-level observation; I have not claimed a successful remote connection or run a hosted service.

Describe the solution you'd like

Before preparing a PR, could the maintainers clarify whether authenticated remote MCP servers are within UltraRAG's intended scope? If so, would you prefer an optional per-server header reference resolved from an environment variable at runtime, and should it use the existing bridge or a FastMCP-native remote transport? I would aim to keep credentials out of tracked/generated configuration and logs, apply the same behavior in build and run, and leave local and unauthenticated servers unchanged. A subsequent PR could include a synthetic local authenticated MCP service test covering an accepted token, a 401 response, tool invocation, and cleanup.

Describe alternatives you've considered

A user-managed local proxy or custom stdio wrapper could inject credentials, but each user would have to deploy and maintain it. I have not verified that approach with UltraRAG and would welcome guidance on the preferred connection model before implementing anything upstream.

Additional context

I noticed #425 touched the remote MCP configuration and was closed without a merge or public explanation. I do not want to duplicate that change; please let me know if the remote bridge is intentionally out of scope.

Disclosure: this request is motivated in part by work to make the Baizhi Cloud toolkit usable in Agent/RAG workflows. Baizhi would be only an optional example, not a default server or endorsement. Its hosted service requires a user-supplied key and may incur usage charges; the published plugin code does not include the hosted backend. I have not tested Baizhi against UltraRAG or used a live key for this proposal.

主要言語
Python
スター
5.7k
フォーク
453
平均マージ
3日 2時間
マージ済み PR（30日）
4

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

OpenBMB/UltraRAG のほかの issue

OpenBMB/UltraRAG の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。