Fall back to config args when CLI varargs are absent

In run, server_args comes from *server_args, so it is always a tuple (empty when the user passes no trailing args) and never None. With this is not None check, final_server_args now always takes the tuple and never falls back to config.deployment.args, which means fastmcp.json deployment.args are silently dropped unless the user re-specifies args on the CLI. This breaks existing config-driven launches (including reload/subprocess paths) that depend on configured server arguments.

Useful? React with 👍 / 👎.

Good catch — *server_args is variadic so it's always a tuple, never None. Reverted to or for this specific case. The other parameters all default to None so is not None is correct for them.

Pass port=0 through to run_async kwargs

This merge now preserves port=0 from CLI/config (port if port is not None else ...), but run_command still only forwards port when it is truthy (if port: later in the same function). As a result, run_command(..., port=0) with a fastmcp.json file drops the port entirely and server.run_async falls back to global settings, so the override is not honored and even a configured deployment.port can be bypassed.

Useful? React with 👍 / 👎.

Fixed — changed if final_port: to if final_port is not None: in both reload and uv subprocess command builders (lines 645-649 and 698-703). Also fixed the module-mode ignored options warning (lines 524-531).

Preserve falsy HTTP overrides in reload/subprocess commands

The new is not None merge keeps falsy overrides like --port 0 and --path "", but the reload/uv command builders still append these flags only when truthy (if final_port, if final_path). In fastmcp run --reload (and uv-wrapped runs), those overrides are silently omitted from the child command, so the child process starts with default/config values instead of the requested override.

Useful? React with 👍 / 👎.

Fixed in the same commit — both command builder paths now use is not None.

Treat empty path as unset before building HTTP routes

Switching to path is not None means path="" now gets forwarded to create_streamable_http_app/create_sse_app instead of falling back to configured defaults. Starlette routes require paths to start with /, so FastMCP.http_app(path="", transport="http"|"sse") now raises AssertionError: Routed paths must start with '/' during startup. Before this change, an empty string flowed through or and safely used the default MCP path, so this introduces a new crash path for callers that pass empty values.

Useful? React with 👍 / 👎.

Valid — path="" would crash Starlette's route validation. In practice nobody passes empty path (the CLI param defaults to None, not ""), but this is a minor behavior change. An explicit empty string for a URL path is a caller error regardless.

Skip port kwarg when transport is stdio

run_command now always forwards port when it is non-None, so calls like run_command(..., transport="stdio", port=0) (or equivalent CLI/config flows) pass port into server.run_async. In the stdio branch, TransportMixin.run_async forwards kwargs to run_stdio_async, which does not accept a port parameter, causing TypeError and process exit instead of starting the server. This regression is triggered specifically by falsy-but-valid overrides such as port=0 that were previously filtered out.

Useful? React with 👍 / 👎.

Fixed — HTTP-specific kwargs (host, port, path) are now guarded by if transport != "stdio" in the kwargs builder so they don't leak into run_stdio_async.

Resolve default transport before appending HTTP kwargs

run_command now filters HTTP-only kwargs with if transport != "stdio", but transport can be None here and server.run_async() resolves that to fastmcp.settings.transport (default "stdio"). With this patch’s is not None checks, calls like run_command(..., transport=None, port=0) now pass port through, and the stdio path raises TypeError because run_stdio_async does not accept port (same for host/path). Fresh evidence in this commit is the combination of transport != "stdio" and port is not None, which still treats None as HTTP-capable.

Useful? React with 👍 / 👎.

Valid — fixed in a follow-up PR. The guard now uses transport is not None and transport != "stdio" so HTTP kwargs aren't passed when transport is unspecified (defaults to stdio).