MCP ImageContent not passed to VLM + no working directory placeholder in prompts

[sunasaji]

Which version of LM Studio?
LM Studio 0.4.6

Which operating system?
Windows11

What is the bug?
When an MCP tool returns ImageContent, LM Studio stores the image in the per-conversation working directory, but the VLM does not receive the image as a model input. The model reports it cannot see the image.
Additionally, the per-conversation working directory (or conversation ID) is not exposed to the model via prompt template placeholders, so the model cannot discover the correct path on its own.

Screenshots

Logs
1772465710308.conversation.json

Observed behavior:

• The image returned by the MCP tool is saved under LM Studio’s working directory, e.g.
  C:\Users\USER\.lmstudio\working-directories\1772465710308
• LM Studio logs contain 1772465710308, but there is no evidence of this value being passed into the model prompt.
  As a result, the model has no way to determine the active conversation’s working directory, and it cannot “see” the image it just retrieved.

To Reproduce
Steps to reproduce the behavior:

1. Create a minimal MCP server that returns ImageContent:

# minimal_image_mcp.py
import base64
import asyncio
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import ImageContent, Tool

app = Server("minimal-image")

@app.list_tools()
async def list_tools():
    return [Tool(
        name="return_image",
        description="Return a local image as ImageContent.",
        inputSchema={"type":"object","properties":{"path":{"type":"string"}}, "required":["path"]},
    )]

@app.call_tool()
async def call_tool(name, arguments):
    path = arguments["path"]
    with open(path, "rb") as f:
        data = base64.b64encode(f.read()).decode("utf-8")
    mime = "image/png" if path.lower().endswith(".png") else "image/jpeg"
    return [ImageContent(type="image", data=data, mimeType=mime)]

async def run():
    async with stdio_server() as (r, w):
        await app.run(r, w, app.create_initialization_options())

if __name__ == "__main__":
    asyncio.run(run())

2. Add to mcp.json:

{
  "mcpServers": {
    "minimal-image": {
      "command": "C:\\Windows\\py.exe",
      "args": ["-3", "C:\\Users\\USER\\minimal_image_mcp.py"]
    }
  }
}

3. Start LM Studio, enable the MCP server, and run:

Get the image at "C:\path\to\the\image.jpg" by using the return_image tool in mcp/minimal-image and transcribe it using the model's Vision function.

4. The tool returns ImageContent and LM Studio saves it in the working directory, but the model replies it cannot see the image.

Expected behavior

1. Provide template placeholders (e.g., {workingDirectory} or {conversationId}) so the system prompt can include the current conversation’s working directory or ID.
2. If the model can discover the working directory path, it can use mcp-filesystem or mcp-local-vision to access and interpret the images it just retrieved.

Related issue
Similar report for reference:
modelcontextprotocol/servers#2389

[Muritavo]

I'm also interested in on this... With the latest Qwen 3.5 it would be nice to integrate mcp imaging capabilities

[sunasaji]

I found a workaround.
Add a step to find the full path of the image file using mcp/filesystem's search_files.
Below is an example prompt.

Use `mcp/minimal-image return_image` to get a image and obtain the filename.

Use `mcp/filesystem search_files` to find the full path of that filename by searching for "C:\Users\USER\.lmstudio\working-directories" with a pattern like "**/image-xxx.jpg".

Then, pass this path to `mcp/local-vision analyze_local_image` and transcribe the text. Set the timeout to 300 seconds.

https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem
https://pypi.org/project/mcp-local-vision/

However, since LM Studio already knows the full path to the working directory, this is clearly a redundant step and requires a dependency on mcp/filesystem and context pressure.
If LM Studio had a way to share the working directory with the model, it would be possible to have the LLM handle files with less context pressure.