modelcontextprotocol / modelcontextprotocol/python-sdk

support logging to stderr in Jupyter Notebook Environments.

Aberta
#156 12 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

bug good first issue P3 ready for work
Linguagem predominante
Python
Estrelas
24.3k
Forks
4k
Merge médio
1d 1h
PRs com merge (30d)
31

Descrição

Is your feature request related to a problem? Please describe.
I want to make mcp python-sdk jupyter notebook compatible. When running in a notebook environment, MCP work but do not output stderr as it does normally.

For instance in jupyter notebook:

import mcp
import os
from mcp.client.stdio import stdio_client

serverparams = mcp.StdioServerParameters(
    command="uv",
    args=["--quiet", "run", "../src/echo.py"],
    env={"UV_PYTHON": "3.12", **os.environ},
)

async with stdio_client(serverparams) as (read, write):
    async with mcp.ClientSession(read, write) as session:
        await session.initialize()
        tools = await session.list_tools()
        print(tools)

Outputs:

meta=None nextCursor=None tools=[Tool(name='echo_tool', description='Echo the input text\n\n    Args:\n        text (str): The text to echo\n\n    Returns:\n        str: The echoed text\n    ', inputSchema={'properties': {'text': {'title': 'Text', 'type': 'string'}}, 'required': ['text'], 'title': 'echo_toolArguments', 'type': 'object'})]

while running the server without jupyter notebook:

❯ uv run --quiet src/echo.py
starting echo server

stderr is correctly displayed.

This is a big problem mostly because if the server is crashing or the command is wrong you have no way to know what's wrong: nothing is logged and the jupyter notebook cell just hangs.

Describe the solution you'd like
I found the culprit being the use of:

process = await anyio.open_process(
        [server.command, *server.args],
        env=server.env if server.env is not None else get_default_environment(),
        stderr=sys.stderr,
 )

In particular sys.stderr here is not working in the jupyter / ipython context. Instead I would suggest a working change as follow:

  1. remove the stderr params from the process and handle process.stderr in an async function as stdout / stdin is handled.
  2. to that effect, use a stderr_reader async function like the following:
    async def stderr_reader():
        assert process.stderr, "Opened process is missing stderr"
        try:
            async for line in process.stderr:
                if is_jupyter_notebook():
                    print(f"\033[91m {line.decode().strip()}")
                else:
                    # redirect to stderr as before
                    print(line.decode().strip(), file=sys.stderr)
        except anyio.ClosedResourceError:
            await anyio.lowlevel.checkpoint()

This would result in the same behavior as before while allowing the stderr to be logged in the jupyter notebook context.

Additional context
Jupyter notebook support support is also requested for mcpadapt which bring MCP server tools in any agentic framework, as many agentic framework demonstrate usage in jupyter notebooks.
https://github.com/grll/mcpadapt

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Direção de pesquisa

Comece em stdio_client e em sua chamada para anyio.open_process e, em seguida, compare como funciona o tratamento existente de stdout e stdin com process.stderr. A tarefa estará concluída quando os erros do servidor estiverem visíveis em notebooks Jupyter ou IPython, enquanto stderr mantiver seu comportamento normal em outros contextos, inclusive quando o processo falhar ou o comando for inválido.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
jupyter-notebook, python
Domínio
backend, cli, developer-experience
Tipo de issue
Funcionalidade
Dificuldade
3/5
Tempo estimado
1-2 dias
Status de atividade
Ativa
Clareza
Razoavelmente clara
Facilidade para iniciantes
58/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.