Follow-up to #3880, which fixed #3867 by adding _object_schema_to_type in src/fastmcp/utilities/json_schema_type.py and wiring it into _get_from_type_handler. That fix resolves the reported bug (nested dict / list[dict] schemas deserializing to empty Root() objects on the client), but two other call sites still carry their own hand-rolled copies of the same four-case logic:
json_schema_to_type — the top-level entry point at roughly lines 180-198- the
anyOf branch inside _schema_to_type at roughly lines 362-374
Both happened to be correct on their own, which is why the bug only surfaced through the recursive path. But keeping three near-duplicate copies of this logic is exactly the divergence risk that produced #3867 in the first place — the next change to object-schema handling has to remember to touch all three.
The follow-up is small: refactor both call sites to delegate to _object_schema_to_type, then verify the existing test suite still passes. No behavior change expected.
Follow-up to #3880, which fixed #3867 by adding
_object_schema_to_typeinsrc/fastmcp/utilities/json_schema_type.pyand wiring it into_get_from_type_handler. That fix resolves the reported bug (nesteddict/list[dict]schemas deserializing to emptyRoot()objects on the client), but two other call sites still carry their own hand-rolled copies of the same four-case logic:json_schema_to_type— the top-level entry point at roughly lines 180-198anyOfbranch inside_schema_to_typeat roughly lines 362-374Both happened to be correct on their own, which is why the bug only surfaced through the recursive path. But keeping three near-duplicate copies of this logic is exactly the divergence risk that produced #3867 in the first place — the next change to object-schema handling has to remember to touch all three.
The follow-up is small: refactor both call sites to delegate to
_object_schema_to_type, then verify the existing test suite still passes. No behavior change expected.