Add a runtime create_model variant to the schema_validators example

[Aaron-Oh]

What

The schema_validators example story shows four ways to type a tool
parameter so MCPServer derives and enforces inputSchema: a pydantic
BaseModel, a TypedDict, a @dataclass, and a bare dict[str, Any].

This adds a fifth variant: a pydantic model built at runtime with
create_model from an external JSON Schema dict, then handed to
@mcp.tool() exactly like a hand-written BaseModel.

Why

Issues #323, #761, and #772 all asked the same thing: how to drive a
tool's inputSchema from a JSON Schema you already hold (from OpenAPI, a
config file, a DB row) rather than a class written out in source. The
maintainer answer is "use a pydantic model as the parameter" — but the
example suite never showed how to get that model when it isn't declared
statically. This closes that documentation gap with a runnable variant.

Notes

• A create_model() result is opaque to static type checkers (its fields
  don't exist until runtime, and a runtime variable can't appear in a type
  annotation). A TYPE_CHECKING branch aliases it to a same-shape declared
  model so type checkers can see the fields; at runtime the dynamic class is
  what @mcp.tool() reflects over. This is called out in the README.
• The published schema is identical to the greet_pydantic variant — the
  point is purely how the model is obtained, not a different wire shape.
• server_lowlevel.py, client.py, and README.md are updated to cover
  the new variant.

Validation

• uv run --frozen ruff format --check / ruff check — clean
• uv run --frozen pyright — 0 errors
• uv run --frozen pytest tests/examples -k schema — 14 passed
  (in-memory/http × modern/legacy × server/server_lowlevel, plus the
  manifest and story-shape checks)

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[Aaron-Oh]

Thanks for the review — addressed both in 230f718:

• P2 (server.py): required is optional in JSON Schema, so it's now defaulted to an empty list before the membership test. A schema with only optional properties (the OpenAPI/config/DB-row case this pattern advertises) builds instead of raising KeyError at import time. Verified an all-optional schema now builds while the original still behaves identically.
• P3 (README.md): greet_dynamic publishes the same schema as greet_pydantic, so the client.py bullet now reads "four typed variants" (calling out the runtime create_model one) rather than three.

[Aaron-Oh]

Hi maintainers, sorry for the small bump on this one.

Just a gentle ping — CI is all green here, and the two cubic comments are already addressed in 230f718 (the missing required one was actually a real bug at import time, so thanks for catching it).

I know the review queue is quite busy these days, so please take your time, no rush at all. But if this variant is not the direction you want for examples/stories/schema_validators/, please feel free to tell me — I'm happy to rework the scope or just close it. Any feedback would be very appreciated.

Thank you in advance!

[maxisbey]

Thanks for the PR, and sorry it sat here without a proper review.

We're closing most of the open PR backlog. v2 is out and changed a lot of the SDK, so many older PRs no longer apply as written, and we're a small team that realistically doesn't have the capacity to work through the rest.

If this still matters to you on v2, the most useful thing you can do is open an issue (or comment on the existing one) with your use case and a repro. Hearing why it matters to you is what we use to decide what to prioritise.

_{AI Disclaimer}