satisfy pyright untyped decorators in mcp.server.fastmcp.server

[zzstoatzz]

Motivation and Context

using a .vscode/settings.json like this

{
    "python.analysis.typeCheckingMode": "strict"
}

the following example throws squiggles on main

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("YouHaveBeenGoosed")

@mcp.tool()
def give_me_a_goose() -> str:
    return "goose"

if __name__ == "__main__":
    mcp.run()

How Has This Been Tested?

observing a marked lack of squiggles on this branch

Breaking Changes

no

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Type nit

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

i purposefully wasn't so prescriptive with _Function, happy to be more specific if needed

if you're wondering how I got here: PrefectHQ/marvin#1042

[zzstoatzz]

omit artifacts from vscode-based editors

[dsp-ant]

Terribel. Feel free to keep it. I dont use vscode myself but i am sure plenty people do.

[dsp-ant]

Thank you. This is great! Throwing this back into you queue for two pieces:

• Shall we rename _Function to something that is exported?
• How can we check in CI/pre-commit that we won't break this?

[dsp-ant]

Any reason to use the _. I wonder if a caller wants to somehow wrap add_tool and type it, they might want to reuse the type?

[zzstoatzz]

@dsp-ant - I've updated the PR to move/rename _Function as AnyFunction in mcp.types - lmk what you think!

as for the question of catching typing regressions in CI, are you suggesting something in addition to the pyright running in shared.yml? in prefect we have some type tests like this (leveraging a mypy pytest plugin) as well as a pyright CI job using a config file.

Not sure what'd be preferable to you, but happy to take a shot at it (here or follow up PR) if one of them sounds attractive!

[dsp-ant]

@dsp-ant - I've updated the PR to move/rename _Function as AnyFunction in mcp.types - lmk what you think!

as for the question of catching typing regressions in CI, are you suggesting something in addition to the pyright running in shared.yml? in prefect we have some type tests like this (leveraging a mypy pytest plugin) as well as a pyright CI job using a config file.

Not sure what'd be preferable to you, but happy to take a shot at it (here or follow up PR) if one of them sounds attractive!

Is there abenefit over mypy? I guess the current checks should be sufficient right?

[dsp-ant]

Thank you! Much appreciated! The more type safety the better!

[zzstoatzz]

I guess the current checks should be sufficient right?

I think so! perhaps someday a pyright config file in a the root of the repo could more specifically config that existing pyright job but that's firmly in the subjective realm in my book 😄

thanks for the review!