Update to v2.13.0 with poetry leads to "Invalid marker for 'python_full_version'"

[Spikhalskiy]

Description

An attempt to upgrade from 2.12.5 to 2.13.0 in Poetry managed project leads to

Invalid marker for 'python_full_version': > 3.14rc1.0
ERROR conda.cli.main_run:execute(125): `conda run poetry lock` failed. (See above for error)

1. Does FastMCP actually require Python 3.14 now? Python 3.14 was released two weeks ago, and some packages haven't yet published compatible builds. If so, it would be nice to add a note and a warning in the release notes.
2. Even with upgrading to Python 3.14.0, the invalid marker error doesn't go away.

Version Information

Poetry version 2.2.1
Python 3.11.13
fastmcp: 2.12.5 (OK), 2.13.0 (not OK)

[jlowin]

There's no reference to 3.14 in our dependencies afaik... /marvin can you explain and fix this?

[marvin-context-protocol]

Claude finished @jlowin's task —— View job • claude/issue-2257-20251025-2021 • Create PR ➔

---

Investigation Complete ✓

• Read pyproject.toml to examine dependencies
• Identify the malformed marker causing the error
• Fix the invalid marker syntax
• Run validation (uv sync, pre-commit, pytest)
• Commit and push changes
• Provide PR creation link

Root Cause

The issue is caused by beartype version 0.22.3, which was released on October 23, 2025. This version has a requires_python field with:

"!=3.14rc1,!=3.14rc2,>=3.10"

This syntax explicitly excludes Python 3.14rc1 and 3.14rc2, which is incompatible with Poetry's marker parsing, causing the error Invalid marker for 'python_full_version': > 3.14rc1.0.

The dependency chain is:

fastmcp 2.13.0 → py-key-value-aio >=0.2.6 → beartype >=0.22.2

When Poetry tries to resolve dependencies, it encounters beartype 0.22.3 (the latest version satisfying >=0.22.2) and fails to parse the release candidate exclusions.

Solution

Added an explicit version constraint for beartype in pyproject.toml:

"beartype>=0.22.2,<0.22.3",

This pins beartype to version 0.22.2 (released October 4, 2025), which doesn't have the problematic rc exclusions. All tests pass:

• ✅ uv sync - Dependencies resolved successfully
• ✅ uv run pre-commit run --all-files - All checks passed
• ✅ uv run pytest - 2988 passed, 14 xfailed, 1 xpassed

Create Pull Request

---

Branch: claude/issue-2257-20251025-2021 |

[Spikhalskiy]

Yes, pinning beartype = "0.22.2" indeed solves the issue.
The correspondent issue in beartype: beartype/beartype#569

[jlowin]

Ok I'd prefer not to have to manage nested dependencies, hopefully beartype will have a patch soon

[strawgate]

If they don't release something before Monday, i can also release a version of py-key-value-aio that pins beartype

Let me know if we want that sooner

I thought adding beartype might cause problems but I never imagined this would be the problem it would cause! 😅

[leycec]

@beartype 0.22.4 has landed. I swear @beartype usually never causes problems. Okay. Technically, there was that one little time @beartype broke PyTorch. And... uhh. I guess @beartype broke FastMCP too now, huh? Jeez. It's not looking good for @beartype.

In @beartype's defense, everything was Poetry's fault. requires-python = ">=3.10,!=3.14rc1,!=3.14rc2" is a PEP 440-compliant version specifier. That's valid syntax in pyproject.toml. Yet, Poetry begged to disagree. Poetry walks its own special road.

In Poetry's defense, everybody loves Poetry. That's not much of a defense, but it's hard to argue with literally everybody. I take breakage like this extremely seriously. I fixed this even faster than I fixed our PyTorch breakage. I'm trustworthy! @beartype is trustworthy! I'm typing too many exclamation marks, aren't I? 😓

Thanks for being so understanding, everybody. FastMCP is awesome. Oh – and last but not least...

I Forgot to Tell Everybody that @beartype Supports FastMCP

The @beartype 0.22.x series added official support for FastMCP – as well as Celery, LangChain, Redis, and probably a ton of other stuff everybody cares about. Specifically, @beartype 0.22.x knows about FastMCP tools and how to properly type-check them. This now "just works" out of the box:

# In a user's "{some_package}.__init__" submodule:
from beartype.claw import beartype_this_package
beartype_this_package()

# In the same user's "{some_package}.muh_fastmcp" submodule:
from fastmcp import Client, FastMCP

fastmcp_server = FastMCP('Super Cool FastMCP Server Yo')
fastmcp_client = Client(fastmcp_server)

# @beartype used to raise exceptions here. Now, it doesn't. We give thanks.
@fastmcp_server.tool
def muh_fastmcp_tool(some_rando_string: str) -> int:
    return len(some_rando_string)

async def muh_fastmcp_app() -> None:
    async with fastmcp_client:
        await fastmcp_client.ping()

        TOOL_INPUT = 'You take this input and take it good'

        tool_output = await fastmcp_client.call_tool(
            'muh_fastmcp_tool', {
                'some_rando_string': TOOL_INPUT,
            }
        )

        assert tool_output.data == len(TOOL_INPUT)

All works. All type-checks.

Incidentally, if anyone on the FastMCP side would like to investigate an even closer relationship between FastMCP and @beartype, it'd be fun to see if we could get @beartype to officially type-check FastMCP tools (and other stuff, possibly) without requiring users to beartype_this_package().

Or... is that already happening? Maybe that's what "adding beartype" meant. Uh oh. I suddenly feel like my ignorance is showing. Let's wrap this up quick. Thanks for flying the friendly @beartype skies, all! 🐻 🛫

[strawgate]

@leycec We recently added adaptable storage to FastMCP using a new key-value store library I've been working on https://github.com/strawgate/py-key-value. py-key-value currently uses BearType in warning mode for unbearably fast runtime type-checking (as you are aware), and I hope to start enforcing type-checks in that library via strawgate/py-key-value#120. Enabling BearType was very fun and involved learning about the Python Numerical Tower and the suddenly inalienable differences between integers and floats.

I have experimented with enabling BearType on FastMCP (I ran into some immediate issues with BearType and subscripted generics) and would be interested in exploring a closer relationship between FastMCP and BearType! The first step is likely engaging in a selective memory wipe of a previous BearType faux pas

FastMCP, the LangChain of the Model Context Protocol (MCP) world.

If only BearType could vibe check in O(1) as well! All this could have been avoided but it is taken care of now (I can't even recall what the original problem was now).

With that out of the way I guess the second step is to likely to come up with a cool graphic.

Maybe something like this:

With those two out of the way, what do you imagine the third step should be?

[Spikhalskiy]

This was resolved with fastmcp 2.13.0.1 and beartype 0.22.4.
There is also an upcoming fix for poetry: python-poetry/poetry-core#893
Thank you!

[leycec]

@strawgate: OMG! py-key-value looks awesome. In hindsight, it's fascinating that nobody ever thought of that. It's obvious. Why bake in support for a single key-value store when you can just abstract away the low-level minutiae, right? Vendor lock-in is the death of everything still good and holy in this world.

Of course, somebody will do the same exact thing to @beartype someday. I support that day. 😅

Enabling BearType was very fun...

You're so nice. I now want to do everything I can for FastMCP and py-key-value. Canadian Gods of Snow, Sleet, Ice, and Hail, guide my keyboard to help these wonderful people!

...and involved learning about the Python Numerical Tower and the suddenly inalienable differences between integers and floats.

...i'm so sorry. My religious conviction to preserve numerical precision has traumatized others. If you'd like to avoid that and just go back to the Good Ol' Bad Days of PEP 484's implicit numeric tower in which int and float are synonymous type hints, @beartype fully supports your desire to avoid trauma:

from beartype import BeartypeConf
from beartype.claw import beartype_this_package
beartype_this_package(conf=BeartypeConf(is_pep484_tower=True))  # <-- stop traumatizing me, @beartype

The first step is likely engaging in a selective memory wipe of a previous BearType faux pas

...i'm so sorry. I only meant that FastMCP is big, ripped, muscley, and shirtless like LangChain! I forgot that everyone hates LangChain despite the existence of LangGraph, because apparently you can never undo the existence of LangChain. Oh, Gods... Wipe away this craven LLM sin I have committed. 😭

With that out of the way I guess the second step is to likely to come up with a cool graphic.

With those two out of the way, what do you imagine the third step should be?

I... uhh. I'm nervously tugging my collar here. The sweat is beading my forehead. My eyes are squinting as the spotlight glares.

Allow me to now honor your life-changing infographic with words that will let everyone down. FastMCP is tightly coupled to Pydantic. Of course, that's not a bad thing whatsoever. Pydantic is the industry-standard for reasonably Pythonic JSON (de)serialization and validation. I'd be concerned if I didn't see Pydantic everywhere. Because my grep-foo is substandard at best, I couldn't quite grep where FastMCP is validating Pydantic models. I expected to find a model_validate(_json)? call somewhere. Yet, I couldn't. My grep-foo is weak. 😞

Annnnnways. @beartype is near-real-time. Literally instantaneous. There's no measurable cost. This means you can chain Pydantic and @beartype together with no degradation in performance. Let Pydantic keep doing its thing, but optionally insinuate @beartype into the type-checking workflow (as possibly outlined below). Alternately, disable Pydantic validation altogether and unconditionally type-check with @beartype. Alternately...

Let users themselves decide. This is the ideal choice. Probably. Default to just preserving Pydantic validation as is. Let's not break the world just because @beartype politely asks you to break the world. Let users optionally configure FastMCP to (A) disable Pydantic validation and/or (B) enable @beartype (or whatever other runtime type-checkers if they please). Certainly, there is an infinite amount of fun work there if anyone wants it. It's fun! I swear it's fun...

I did casually note two things while grepping about like a madman on a Monday:

• The @FastMCP.tool decorator accepts a metric ton of optional parameters. Good. You know how I mentioned that py-key-value looks awesome but that somebody will do the same exact thing to @beartype someday? Perhaps that day has come. If one or both of us (co-)create py-type-check (or whatevahs), then downstream consumers like FastMCP could allow users to swap in their type-checker of choice by exposing a new optional parameter accepted by @FastMCP.tool ala @tool(type_checker=py_type_check.TypeChecker.BEARTYPE) or @tool(type_checker=py_type_check.TypeChecker.TYPEGUARD). Alternately, the choice of type-checker is probably a more global preference. FastMCP users might prefer to globally configure that via their global FastMCP configuration rather than on a per-tool basis. Maybe? Annnnyways. The core conceit is mostly the same. In the body of the @FastMCP.tool decorator, you might do something like this:

from py_type_check import TypeChecker
...

    def tool(
        ...
        # Default to no runtime type-checking, in which case we trust the Universe. A lot.
        type_checker: TypeChecker = TypeChecker.NONE,
    ):
            # Runtime type-checker corresponding to the user-requested type-checker if any or
            # the identity function silently reducing to a noop otherwise.
            from py_type_check import get_type_checker_from_enum
            type_checker_func = get_type_checker_from_enum(type_checker)

            tool = Tool.from_function(
                type_checker_func(fn),  # <-- *HO, HO, HO.* Merry Christmas, FastMCP. Santa QA Claws delivers the quality.

Or maybe just generalize type_checker: Callable[[T], T] = lambda func: func where T = TypeVar(bound=Callable)? Then users could pass whatever runtime type-checker they like without needing the explicit permission of py_type_check? Of course, the whole point of py_type_check is that it abstracts away all that stuff (like configuring type-checkers, which probably gets pretty cray-cray pretty fast). Indeed, it's probably best to force py_type_check. Let's not let users blow up FastMCP and then blame FastMCP. Annnnnyway.

• Totally unrelated to @beartype and type-checking, but FastMCP's "Decorating Methods" caveats doesn't seem quite right. On the face of it, it really does seem like a future version of FastMCP should be able to transparently support standard-issue decoration use cases like:

from fastmcp import FastMCP
mcp = FastMCP()

class MyClass:
    @mcp.tool  # <-- Seems like FastMCP really should be able to make that work? Maybe?
    def my_method(self, x: int) -> int:
        return x * 2

In theory, the @FastMCP.tool decorator should be able to support both instance and class methods by (in order):

1. Detecting when it's being applied to an instance or class method. @FastMCP.tool currently detects only the latter, but could detect the former as well by either:
   • Trivial signature introspection. If the first parameter is self, it's almost certainly an instance method.
   • Non-trivial call stack introspection. Technically, classes are lexical scopes. This means that @FastMCP.tool can iteratively crawl up the call stack until it either leaves a module boundary or finds a class scope. Definitely hard stuff. Definitely doable, too. Personally, I'd just wing it and introspect for self parameters until users complain. 😆
2. If @FastMCP.tool detects it's being applied to an instance or class method, it returns a non-data descriptor (i.e., an object whose class satisfies the descriptor protocol by defining the __get__() dunder method) rather than doing what it currently does. That descriptor's __get__() dunder method then (in order):
   1. Binds the function it was instantiated with to either the desired instance or class object.
   2. DOES ALL OF THE STUFF THE @FastMCP.tool DECORATOR CURRENTLY DOES. Clearly, this is where the saucy magic sauce happens. 😋
   3. Returns the now-bound instance or class method.

In theory, everything should just "work" from the end user perspective. You've almost certainly thought of all that, because you are FastMCP. There's a good reason why that simply doesn't work, I'm sure. Still. Descriptors are fun! I'm saying "fun" a lot. It's almost like that word means something different when I use it.

Unrelatedly but relatedly...

The Next Version of pytest-beartype Type-checks Tests and Fixtures

Yes! So much hype! If you're interested in QA-ing your pytest test suite, something fun is about to land. Slated to be released tomorrow, ^gulp pytest-beartype 0.3.0 will be Python's first devtool to type-check pytest tests and/or fixtures. When pytest-beartype 0.3.0 lands, just:

• Require pytest-beartype >=0.3.0 in your test extras in pyproject.toml.
• Invoke pytest with pytest --beartype-tests --beartype-fixtures in tox (or nox).

Boom! pytest lawlessness has now been conquered by the grizzled bear. 💪 🐻