Unpack settings in FastMCP

[Kludex]

No description provided.

[Kludex]

This is the main change. The rest is just to comply with those types.

[dsp-ant]

Suggested change

	message_path: str = "/messages/",
	message_path: str = "/messages",

[Kludex]

Hard to trust AI nowadays. 👀

[Kludex]

Oh, actually, the AI didn't make a mistake.

The default on Settings.message_path was added with the /.

[dsp-ant]

yea i know :(, is that correct tho?

[Kludex]

Given that it doesn't follow the pattern, no. But also there's some redirect issues that people may be facing.

But should I really change it in this PR? It may affect people.

[dsp-ant]

My main worry is that we now keep the defaults in sync between Settings and this. I think ideally, but sadly a BC break would be to just accept settings: Settings = Settings() here. Since I think that would be backwards incompatible. For now, since Settings is only used internally to FastMCP should we remove the defaults from the Settings class, such that we only provide it here?

[Kludex]

Yep, we should remove the defaults from Settings.

[dsp-ant]

LGTM

[GZGavinZhao]

This PR likely broke a lot of uvx my-mcp-server workflows by removing **settings as an argument to FastMCP.__init__:

Traceback (most recent call last):
  File "/home/gavinzhao/.cache/uv/archive-v0/Sd9MpTigriP_4YpcGN7U3/bin/lean-lsp-mcp", line 6, in <module>
    from lean_lsp_mcp import main
  File "/home/gavinzhao/.cache/uv/archive-v0/Sd9MpTigriP_4YpcGN7U3/lib64/python3.13/site-packages/lean_lsp_mcp/__init__.py", line 3, in <module>
    from lean_lsp_mcp.server import mcp
  File "/home/gavinzhao/.cache/uv/archive-v0/Sd9MpTigriP_4YpcGN7U3/lib64/python3.13/site-packages/lean_lsp_mcp/server.py", line 98, in <module>
    mcp = FastMCP(**mcp_kwargs)
TypeError: FastMCP.__init__() got an unexpected keyword argument 'env_vars'

I understand that it's kind of awkward to have a backwards compatibility guarantee for a fast-moving package like mcp, but perhaps it'd be a good idea to at least document this change? Especially since this change is made in a patch release?

[MischaPanch]

This is a breaking change and you only updated the patch version of the package. It broke our code:
oraios/serena#381

You could fix this by rolling this back, urgently releasing 1.12.4, and then doing it in a backwards compatible way or make a new major version.

For reference of what breaks: this code now causes a pydantic validation error

mcp_settings: Settings = Settings(lifespan=self.server_lifespan, host=host, port=port)
mcp = FastMCP(**mcp_settings.model_dump(), instructions="...")

[MischaPanch]

Fun coincidence: I had raised the problem with the constructor a while ago and in the issue had proposed a backwards compatible way to handle this
#305

[GZGavinZhao]

For uvx users, a temporary fix for this is to have mcp==1.12.2 in a requirements.txt file and add --with-requirements=requirements.txt as the first arugment to uvx.

Actually, you can also add the environment variable UV_CONSTRAINT=<path-to-requirements.txt-above> to whatever MCP configuration you're using, e.g.:

{
  "mcpServers": {
    "lean-lsp": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "lean-lsp-mcp"
      ],
      "env": {
        "UV_CONSTRAINT": "requirements.txt"
      }
    }
  }
}

[mzyil]

please add a bot to your repo that verifies backwards compat. a lot of people depend on your code and you are past alpha.

[Kludex]

It seems there were two different issues here:

• Use of env_vars (i.e. passing unused parameter to the constructor)
• Instantiating Settings by oneself, which I guess would be to have a false sense of type safety?

I didn't expect people to be instantiating the Settings themselves.

---

I guess the way to go here now is to:

1. Ignore the messages above - this change seems reasonable.
2. Add a kwargs back with a deprecation warning in it saying that those parameters are not used, and add the default values for settings back - which I think we should deprecate the Settings class itself.

[MischaPanch]

Settings is a public class and it was the only way to have the kwargs names and types analyzed by the IDE - how was the sense of type safety false?

But it seems like indeed few people were using it, otherwise this would have gotten more attention

[cbcoutinho]

This change has also broken the ability to override variables using FASTMCP_ env var prefix by providing all these defaults prior to instantiating the Settings object.

[0xMirasio]

why this PR has been merged wtf