Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal: optional per-server authentication for remote MCP pipelines

Abierto
  • ¿Algo no está bien?
#522 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
api, authentication, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
5.7k
Forks
450
Merge medio
1 d 4 h
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenBMB/UltraRAG

Todos los issues de OpenBMB/UltraRAG

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.