Initial Checks
Release Line
2.x (current stable). The same code exists on v1.x (src/mcp/server/fastmcp/utilities/types.py).
Description
Image and Audio compute the MIME type two different ways. With path= they use a suffix table (.jpg -> image/jpeg, .mp3 -> audio/mpeg, .m4a -> audio/mp4). With format=, which docs/servers/media.md says to pass whenever you use data=, they just do f"image/{format}" / f"audio/{format}". So the same name gives different results depending on which keyword it arrives through, and format= puts non-registered types on the wire:
Image(data=..., format="jpg") -> mimeType: "image/jpg" (should be image/jpeg)
Audio(data=..., format="mp3") -> audio/mp3 (should be audio/mpeg)
Audio(data=..., format="m4a") -> audio/m4a (should be audio/mp4)
This is easy to hit: switching a tool from Image(path="chart.jpg") to Image(data=buf.getvalue(), format="jpg") silently changes the wire output from image/jpeg to image/jpg, and a consumer that validates image MIME types rejects it.
Expected: format="jpg" and path="x.jpg" give the same registered type.
Proposed fix: route format= through the same table the path= branch already has, keeping image/<format> / audio/<format> as the fallback for names outside it (so format="bmp" etc. are unchanged). I have this fix with parametrized tests ready locally (100% branch coverage on types.py, ruff/pyright clean) and would like to open the PR if this is accepted.
Example Code
from pathlib import Path
from mcp.server.mcpserver import Audio, Image
print(Image(data=b"\x00", format="jpg").to_image_content().mime_type) # image/jpg (expected image/jpeg)
print(Audio(data=b"\x00", format="mp3").to_audio_content().mime_type) # audio/mp3 (expected audio/mpeg)
print(Audio(data=b"\x00", format="m4a").to_audio_content().mime_type) # audio/m4a (expected audio/mp4)
# The same helpers get it right when the name arrives as a file suffix:
print(Image(path=Path("x.jpg"))._mime_type) # image/jpeg
Python & MCP Python SDK
Python 3.12.13
mcp 2.2.0 (also reproduced on main @ f1b6589)
Disclosure: found, reproduced and the draft fix tested locally with the help of an AI coding agent (Claude Code); I reviewed the report before filing it.
Initial Checks
Release Line
2.x (current stable). The same code exists on
v1.x(src/mcp/server/fastmcp/utilities/types.py).Description
ImageandAudiocompute the MIME type two different ways. Withpath=they use a suffix table (.jpg -> image/jpeg,.mp3 -> audio/mpeg,.m4a -> audio/mp4). Withformat=, whichdocs/servers/media.mdsays to pass whenever you usedata=, they just dof"image/{format}"/f"audio/{format}". So the same name gives different results depending on which keyword it arrives through, andformat=puts non-registered types on the wire:Image(data=..., format="jpg")->mimeType: "image/jpg"(should beimage/jpeg)Audio(data=..., format="mp3")->audio/mp3(should beaudio/mpeg)Audio(data=..., format="m4a")->audio/m4a(should beaudio/mp4)This is easy to hit: switching a tool from
Image(path="chart.jpg")toImage(data=buf.getvalue(), format="jpg")silently changes the wire output fromimage/jpegtoimage/jpg, and a consumer that validates image MIME types rejects it.Expected:
format="jpg"andpath="x.jpg"give the same registered type.Proposed fix: route
format=through the same table thepath=branch already has, keepingimage/<format>/audio/<format>as the fallback for names outside it (soformat="bmp"etc. are unchanged). I have this fix with parametrized tests ready locally (100% branch coverage ontypes.py,ruff/pyrightclean) and would like to open the PR if this is accepted.Example Code
Python & MCP Python SDK
Disclosure: found, reproduced and the draft fix tested locally with the help of an AI coding agent (Claude Code); I reviewed the report before filing it.