Python: MCP Connector Failure

[mehmetaltuntas]

Hi,

I have a lifespan method that does call out the initialize orchestrator as follows:

@asynccontextmanager
`
async def lifespan(app: FastAPI):
global kernel, chat_service, request_settings

try:
    kernel, chat_service, request_settings = await initialize_orchestrator()
except Exception as e:
    raise

yield

# Cleanup on shutdown`

and as follow up, I do have the code where I do register MCP Sse Plugin as:

# genie_plugin = MCPSsePlugin( # name="GenieAgent", # description=""" # Databricks Genie Agent for data analysis and workspace interaction # """, # url="http://genie-mcp.io/sse", # request_timeout=10000000 # ) # await genie_plugin.connect() # kernel.add_plugin(genie_plugin)

At the orchestrator level, I do get the following error message time to time:

File "/usr/local/lib/python3.12/site-packages/semantic_kernel/functions/kernel_function_from_method.py", line 107, in _invoke_internal . File "/usr/local/lib/python3.12/site-packages/semantic_kernel/connectors/mcp.py", line 412, in call_tool. raise FunctionExecutionException(f"Failed to call tool '{tool_name}'.") from ex

Any good practice to handle it and re-establish the connection by the framework?

[eavanvalkenburg]

hi @mehmetaltuntas this seems related to the same issue as described in #12627 which in itself is caused by this MCP issue: modelcontextprotocol/python-sdk#922 in the #12627 there is a workaround mentioned, I believe at this time is the only way to resolve this, until the package is fixed, but I'll keep checking in and trying some things on our end anyway, thanks for reporting!

[mehmetaltuntas]

hi @mehmetaltuntas this seems related to the same issue as described in #12627 which in itself is caused by this MCP issue: modelcontextprotocol/python-sdk#922 in the #12627 there is a workaround mentioned, I believe at this time is the only way to resolve this, until the package is fixed, but I'll keep checking in and trying some things on our end anyway, thanks for reporting!

Hi @eavanvalkenburg , thanks for the response. Is the task of cleanup a workaround?

Also, another behaviour that I've experienced is that the connection may drop and I have to manage the remote mcp server exception in the filter and re-add it. Not sure a good approach - tbh.

[eavanvalkenburg]

the workaround is that the cleanup needs to happen in the exact right order and place for it to not throw an error, this is something the the MCP package should fix, so for now putting in more controls over when and how the connection is made and broken requires a bit more work. That might also solve your other issue, and depending on the latency of setting up the connection it might be easier to just do that closer to the run, instead of one time.

[mehmetaltuntas]

the workaround is that the cleanup needs to happen in the exact right order and place for it to not throw an error, this is something the the MCP package should fix, so for now putting in more controls over when and how the connection is made and broken requires a bit more work. That might also solve your other issue, and depending on the latency of setting up the connection it might be easier to just do that closer to the run, instead of one time.

what I've done is that I am having a Custom MCP SSE Plugin class definition that I could override message_handler method so that I could capture the following error:

peer closed connection without sending complete message body (incomplete chunked read) (Error count: 1)

Again, this could be bit unnecessary work if kernel manages the connectivity gracefully and does the re-establishment.