-
Notifications
You must be signed in to change notification settings - Fork 572
Description
[Question] Is _resolve_session_id expected to be called in STDIO mode?
Hi! First of all, thank you for this great project!
What I Noticed
While testing with fastmcp dev (STDIO mode), I found that after calling set_active_instance, subsequent tool calls experience a ~10 second delay before executing.
After digging into the code, I found that PluginHub._resolve_session_id() is being called even in STDIO mode. Since there's no WebSocket plugin connected in STDIO mode, it waits for the full retry timeout (40 × 250ms ≈ 10s) before falling back.
The good news: After the timeout, the tool call still succeeds via the "recently active instance" fallback mechanism. So functionality is not broken — it's just a delay on the first call after setting an active instance.
Steps to Reproduce
- Start the MCP server using
fastmcp devto launch MCP Inspector - Open Unity Editor with a project that has MCP for Unity package installed
- In MCP Inspector, call the
set_active_instancetool to set an active Unity instance (e.g.,MyProject@abc123) - Call any other tool (e.g.,
execute_menu_item,get_hierarchy, etc.) - Observe: The tool call hangs for ~10 seconds before executing
Code Analysis
In main.py, PluginHub.configure() is called unconditionally on startup:
# main.py lines 103-107
global _plugin_registry
if _plugin_registry is None:
_plugin_registry = PluginRegistry()
loop = asyncio.get_running_loop()
PluginHub.configure(_plugin_registry, loop) # Always called!Then in unity_instance_middleware.py, the middleware checks PluginHub.is_configured() which is always True:
# unity_instance_middleware.py lines 84-93
async def on_call_tool(self, context: MiddlewareContext, call_next):
ctx = context.fastmcp_context
active_instance = self.get_active_instance(ctx)
if active_instance:
if PluginHub.is_configured(): # Always True!
try:
session_id = await PluginHub._resolve_session_id(active_instance)
except Exception:
self.clear_active_instance(ctx)
return await call_next(context)Questions
I'm not sure if this is intentional design or something that could be improved:
- Is
PluginHubintended to be configured/used in STDIO mode as well? - Should the middleware check the transport mode before calling
_resolve_session_id?
Environment
- Server version: 8.1.4
- Transport mode: STDIO
- OS: Windows