René's URL Explorer Experiment

Title: docs: load media examples from disk instead of inline base64 by maxisbey · Pull Request #3108 · modelcontextprotocol/python-sdk · GitHub

Open Graph Title: docs: load media examples from disk instead of inline base64 by maxisbey · Pull Request #3108 · modelcontextprotocol/python-sdk

X Title: docs: load media examples from disk instead of inline base64 by maxisbey · Pull Request #3108 · modelcontextprotocol/python-sdk

Description: Rework the media docs examples to load their files from disk instead of embedding a base64 blob. Motivation and Context The image/audio tutorials on the media page opened with LOGO_PNG = base64.b64decode("iVBORw0KGgo...") — the first thing a reader met was an opaque blob rather than the API being taught, and it read as if conjuring base64 by hand were part of the job. The examples now show the realistic pattern: Image(path=...) / Audio(path=...) pointing at logo.png / chime.wav beside the server. The paths are anchored with Path(__file__).parent so the example keeps working when a host launches the stdio server from an arbitrary working directory (hosts generally do — a bare relative path would resolve against wherever that happens to be), and the page now says so explicitly. The data= + format= mode is still taught in "Bytes or a file", reframed as the mode for bytes that never touch disk (Pillow output, screenshots, ...). No binary asset is committed: the tests fabricate the files in tmp_path and repoint the tutorials' module-level path constants (the same pattern FastAPI's docs tests use for its FileResponse examples). The SDK never parses the contents, so opaque bytes suffice. Also fixed while here: the audio wire-format illustration showed the base64 of the now-deleted placeholder (its RIFF size field included), which no reader's own WAV would reproduce — truncated to the universal prefix. How Has This Been Tested? tests/docs_src/test_media.py updated: fabricated assets in tmp_path, exact ImageContent/AudioContent round-trip assertions, plus a new test pinning that path= files are read when the result is built (which is what makes the fabricate-then-call pattern sound). Drove both tutorial files end-to-end over a real stdio subprocess (mcp run + stdio_client): image and audio round-trip byte-for-byte with the files on disk; a missing file surfaces as a clean tool error naming the path; launching the server from a different working directory still resolves the files (the __file__ anchoring at work). Breaking Changes None — docs and tests only. 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 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 The old examples' data= mode (with the format= caveat) is still covered by test_raw_data_without_a_format_falls_back_to_a_default_mime_type and the !!! check admonition — nothing the page previously taught was dropped, the two construction modes just swapped billing. AI Disclaimer

Open Graph Description: Rework the media docs examples to load their files from disk instead of embedding a base64 blob. Motivation and Context The image/audio tutorials on the media page opened with LOGO_PNG = base64.b64...

X Description: Rework the media docs examples to load their files from disk instead of embedding a base64 blob. Motivation and Context The image/audio tutorials on the media page opened with LOGO_PNG = base64.b64...

Opengraph URL: https://github.com/modelcontextprotocol/python-sdk/pull/3108

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width