No UI tools

[mulka]

What happened?

Getting an error from fastmcp dev apps.

Error message: "No UI tools found on this server. Use @app.ui() to register entry-point tools."

My requirements.txt:

fastmcp[apps] @ git+ssh://git@github.com/jlowin/fastmcp.git@8ee81b3037d28a86063e763e6be8830d5b5e7b1f
pydocket==0.17.9

Example Code

from prefab_ui.app import PrefabApp
from prefab_ui.components import Text
from fastmcp import FastMCP

mcp = FastMCP("Hello Prefab")

@mcp.tool(app=True)
def hello_prefab() -> PrefabApp:
    return PrefabApp(view=Text("Hello, world!"))

Version Information

FastMCP version:                                                   3.2.1.dev22+8ee81b30
MCP version:                                                                     1.27.0
Python version:                                                                 3.12.11
Platform:                                                    macOS-26.4-arm64-arm-64bit
FastMCP root path: /Users/mulka/Code/mcp-app-example/.venv/lib/python3.12/site-packages

[jlowin]

Hi @mulka - I'm having trouble replicating with your code, it seems to be loading for me. Is there any other info you could provide to help debug?

[mulka]

@jlowin Try deactivating the venv then reactivating it before running the fastmcp CLI again. I've noticed I have to do that.

Here's the commands I used to reproduce on a fresh venv.

mulka@Mac ~ % which python
/Users/mulka/.asdf/shims/python
mulka@Mac ~ % python --version    
Python 3.12.11
mulka@Mac ~ % python -m venv venv                     
mulka@Mac ~ % source venv/bin/activate
((venv) ) mulka@Mac ~ % pip install "fastmcp[apps] @ git+ssh://git@github.com/jlowin/fastmcp.git@8ee81b3037d28a86063e763e6be8830d5b5e7b1f"
Collecting fastmcp@ git+ssh://****@github.com/jlowin/fastmcp.git@8ee81b3037d28a86063e763e6be8830d5b5e7b1f (from fastmcp[apps]@ git+ssh://git@github.com/jlowin/fastmcp.git@8ee81b3037d28a86063e763e6be8830d5b5e7b1f)
  Using cached fastmcp-3.2.1.dev22+8ee81b30-py3-none-any.whl
...
((venv) ) mulka@Mac ~ % pip install pydocket==0.17.9
Collecting pydocket==0.17.9
  Using cached pydocket-0.17.9-py3-none-any.whl.metadata (6.7 kB)
...
((venv) ) mulka@Mac ~ % deactivate 
mulka@Mac ~ % source venv/bin/activate
((venv) ) mulka@Mac ~ % fastmcp dev apps server.py
[04/08/26 14:14:28] INFO     Starting user server on port 8000…                                          apps_dev.py:1737
                    INFO     Fetching app-bridge.js from npm…                                            apps_dev.py:1738
[04/08/26 14:14:30] INFO     FastMCP dev UI at http://localhost:8080

[jlowin]

I tested with the same commit, Python 3.12.11, your exact code, and pydocket installed, and can't reproduce this.

I think maybe this is an asdf shim issue. fastmcp dev apps spawns the MCP server as a subprocess using sys.executable. If asdf's shim resolves fastmcp to a different Python than your venv's, the subprocess won't have your venv's packages (prefab_ui), the tool won't register, and the picker shows "No UI tools." The deactivate/reactivate workaround supports this: it forces the venv's Python first on PATH.

Can you check what these show with your venv activated?

which python
which fastmcp
python -c "import sys; print(sys.executable)"

If python points to an asdf shim but fastmcp points to your venv's bin, or vice versa, that's the mismatch. It's hard to say though.

[mulka]

((venv) ) mulka@Mac ~ % which python
/Users/mulka/venv/bin/python
((venv) ) mulka@Mac ~ % which fastmcp
/Users/mulka/venv/bin/fastmcp
((venv) ) mulka@Mac ~ % python -c "import sys; print(sys.executable)"
/Users/mulka/venv/bin/python

[mulka]

Note that it does work with newer versions of pydocket. It's just this slighter older version that doesn't work for me.

[jlowin]

So it does work with newer pydocket? That's so strange. I couldn't replicate with your version but maybe @chrisguidry has an idea?

[chrisguidry]

I'm also not able to reproduce this, even with pydocket==0.17.9.

One thing I see right off the bat is that fastmcp 3.2 requires a newer version of pydocket, it's configured to use tasks = ["pydocket>=0.18.0"]. I believe there were some small import compatibility problems that could interfere with tool discovery and server startup. Also, that is when I split the pydocket and uncalled-for packages up, which could mean that something is getting cross-wired between the different packages' Dependency classes.

If you're using fastmcp>=3.2.1 you should definitely be using pydocket>=0.18.0.

Is there a reason you need to pin to the older docket version? I am pretty sure Docket's user-facing API is fully compatible so bumping to the latest should be fine. How do things look if you install fastmcp[apps,tasks] @ ...?

[mulka]

My understanding is that if you only include the apps extra and not the tasks extra it doesn't upgrade the version of pydocket because it isn't required. So, if apps actually uses pydocket, maybe it needs to be required in that case so folks can upgrade from older versions of FastMCP to the newer one.

[jlowin]

Apps doesn't use pydocket I don't think, which is why this is very strange.

[mulka]

@jlowin @chrisguidry Got it reproducing in docker if that helps: https://github.com/mulka/mcp-app-example/tree/no_ui_tools

[mulka]

@jlowin Looks like list_tools ends up calling get_task_context.

File "/Users/mulka/Code/fastmcp/src/fastmcp/server/server.py", line 575, in list_tools
return await self._run_middleware(
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/server.py", line 451, in _run_middleware
return await chain(context)
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/middleware/middleware.py", line 92, in call
return await handler_chain(context)
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/middleware/middleware.py", line 133, in on_message
return await call_next(context)
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/middleware/middleware.py", line 140, in on_request
return await call_next(context)
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/middleware/dereference.py", line 29, in on_list_tools
tools = await call_next(context)
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/server.py", line 586, in list_tools
skip_auth, token = _get_auth_context()
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/server.py", line 182, in _get_auth_context
return (False, get_access_token())
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/dependencies.py", line 791, in get_access_token
snapshot = _get_task_snapshot_sync()
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/dependencies.py", line 358, in _get_task_snapshot_sync
task_info = get_task_context()
File "/Users/mulka/Code/fastmcp/src/fastmcp/server/dependencies.py", line 120, in get_task_context
traceback.print_stack()

Anyway, I can no longer reproduce this bug in the main branch. Probably due to this change: #3807

[jlowin]

This was fixed in #3807.

The root cause: is_docket_available() only checked import docket, so your pydocket==0.17.9 (below the 0.18.0 floor that fastmcp[tasks] enforces, but present because it wasn't gated by the apps extra) made the check return True. Then on every list_tools call, the auth context fallback chain reached get_task_context(), which tried from docket.dependencies import current_execution — a symbol that doesn't exist in pydocket < 0.18.0 — and raised an ImportError.

The reason you saw "No UI tools found" instead of an actual error: the dev server's _list_tools() helper catches all exceptions from the MCP client and returns an empty list, so the ImportError on the server side silently became "zero tools discovered."

The fix version-checks pydocket via importlib.metadata against a >= 0.18.0 floor, so an older transitive pydocket is now treated as "not installed" and the entire docket code path is skipped. Your trace of the call chain was spot on — thanks for digging in.