github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-15 12:36:27 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24413] issue: Azure AI Search Knowledge Base MCP returns uri: null in EmbeddedResource, causing Pydantic validation failure (v0.9.2) #107287

New Issue
Closed
opened 2026-05-18 06:01:59 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-18 06:01:59 -05:00
Owner
Copy Link

Originally created by @cryptomonkey2020 on GitHub (May 6, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24413

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

0.9.2

Ollama Version (if applicable)

N/A

Operating System

Linux (Azure Container Apps)

Browser (if applicable)

Chrome 136.0

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When an Azure AI Search Knowledge Base MCP endpoint returns tool results with type: "resource" content blocks, OpenWebUI should extract the resource.text field and pass the data to the LLM. The v0.9.2 changelog states this is fixed: "MCP resource content handling. MCP tool results with the resource content type are now correctly detected and their resource.text payload is extracted."

Actual Behavior

OpenWebUI v0.9.2 throws 84 Pydantic validation errors when calling knowledge_base_retrieve on an Azure AI Search Knowledge Base MCP endpoint. The error occurs because Azure returns "uri": null in the EmbeddedResource.resource object, and the MCP SDK (mcp==1.26.0) requires uri to be a valid URL string (type AnyUrl).

Error:
84 validation errors for CallToolResult
content.0.EmbeddedResource.resource.TextResourceContents.uri
URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType
content.0.EmbeddedResource.resource.BlobResourceContents.uri
URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType
content.0.EmbeddedResource.resource.BlobResourceContents.blob
Field required type=missing, ...
This is related to #24038 but is a different failure mode. Issue #24038 reported that resource content was silently dropped (v0.9.1). The v0.9.2 fix now recognizes the resource type but fails at Pydantic validation because Azure sends a spec-violating "uri": null.

Root cause: Azure AI Search Knowledge Base MCP endpoint returns:

{"type": "resource", "resource": {"uri": null, "mimeType": "application/json", "text": "..."}}
The MCP spec (2025-03-26) defines uri as required (type: "string", format: "uri") in ResourceContents. Azure sends null, which the Python MCP SDK correctly rejects.
This is an Azure bug (spec violation), but OpenWebUI should handle it gracefully rather than crashing with 84 validation errors. The fix in process_tool_result() should catch validation errors on CallToolResult and fall back to extracting resource.text manually from the raw dict before Pydantic validation is attempted.

### Steps to Reproduce

## Prerequisites
- Open WebUI v0.9.2 (Docker image: `ghcr.io/open-webui/open-webui:v0.9.2`)
- An Azure AI Search service (any paid tier: Basic, Standard, etc.)
- A Knowledge Base created on that search service (via Azure AI Foundry or REST API)
- The Azure Search admin API key for the service
This bug affects **any** Azure AI Search Knowledge Base MCP endpoint. You do not need a specific index or dataset -- any Knowledge Base will reproduce it.

## Step-by-step Reproduction

### Step 1: Verify the Azure KB MCP endpoint returns `uri: null` (independent of Open WebUI)
Run this curl command, replacing `<SERVICE_NAME>`, `<KB_NAME>`, and `<API_KEY>` with your own values:
```bash
curl -s -X POST \
  "https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview" \
  -H "api-key: <API_KEY>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
Expected: HTTP 200 with MCP handshake response. Then call the tool:
curl -s -X POST \
  "https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview" \
  -H "api-key: <API_KEY>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"knowledge_base_retrieve","arguments":{"queries":["test"]}}}'
Observe the response (SSE format). Every content item has "uri": null:
event: message
data: {"result":{"content":[{"type":"resource","resource":{"uri":null,"mimeType":"application/json","text":"{...}"}}]},"id":2,"jsonrpc":"2.0"}
This proves the bug exists at the Azure API level before Open WebUI is involved.

Step 2: Deploy Open WebUI v0.9.2
docker run -d \
  --name open-webui \
  -p 8080:8080 \
  -e WEBUI_AUTH=false \
  ghcr.io/open-webui/open-webui:v0.9.2
Wait for startup (~30 seconds). Open http://localhost:8080 in Chrome.

Step 3: Add the Azure KB MCP endpoint as a Tool Server
1. Navigate to: Admin Panel → Settings → Tools
2. Click "+" (Add) to add a new tool server connection
3. Configure with these exact values:
   Type;MCP (Streamable HTTP)
   Name;CCC-SCRAPER (or any name)
   URL; https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview
   Auth Type;Bearer
   API Key;Your Azure Search admin API key
4. Click Verify — should succeed (tool discovery works, the error only occurs during tool invocation)
5. Click Save
Step 4: Create a model/agent with the tool enabled
1. Go to Workspace → Models → Create a Model
2. Select any base model (e.g., GPT-4o, Claude, etc.)
3. Under Tools, enable the CCC-SCRAPER tool server (specifically knowledge_base_retrieve)
4. Save the model
5. 
Step 5: Trigger the bug
1. Open a New Chat using the model created in Step 4
2. Send any message that will trigger the knowledge base tool, e.g.:
      What are the latest updates?
   3. The model will call knowledge_base_retrieve with queries
Step 6: Observe the error
The tool result displayed in the chat shows:
84 validation errors for CallToolResult
content.0.TextContent.type
  Input should be 'text' [type=literal_error, input_value='resource', input_type=str]
content.0.TextContent.text
  Field required [type=missing, input_value={'type': 'resource', 'res...}, input_type=dict]
content.0.EmbeddedResource.resource.TextResourceContents.uri
  URL input should be a string or URL [type=url_type, input_value=None, input_type=NoneType]
content.0.EmbeddedResource.resource.BlobResourceContents.uri
  URL input should be a string or URL [type=url_type, input_value=None, input_type=NoneType]
content.0.EmbeddedResource.resource.BlobResourceContents.blob
  Field required [type=missing, ...]
...(repeats for each content item returned by Azure, typically 6-10 items = 60-84 errors)

### Logs & Screenshots

### Error displayed in chat (full text from UI):
84 validation errors for CallToolResult
content.0.EmbeddedResource.resource.TextResourceContents.uri
  URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType
content.0.EmbeddedResource.resource.BlobResourceContents.uri
  URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType
content.0.EmbeddedResource.resource.BlobResourceContents.blob
  Field required type=missing, input_value={'uri': None, 'mimeType':... "ocrText": null\r\n}'}, input_type=dict
content.1.EmbeddedResource.resource.TextResourceContents.uri
  URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType
...(repeats for each content item)

### Root cause proof -- Azure sends `uri: null` (violates MCP spec):
Direct curl to the Azure KB MCP endpoint shows the raw response:
```bash
curl -s -X POST \
  "https://<service>.search.windows.net/knowledgebases/<kb>/mcp?api-version=2025-11-01-Preview" \
  -H "api-key: <KEY>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"knowledge_base_retrieve","arguments":{"queries":["test"]}}}'
Response (SSE event):
{
  "type": "resource",
  "resource": {
    "uri": null,
    "mimeType": "application/json",
    "text": "{\"uid\": \"240d1a58e4e3_...\", \"snippet\": \"...\", ...}"
  }
}


All 8 content items have "uri": null. The MCP spec (2025-03-26) requires uri to be a non-null string with format "uri" (ResourceContents.uri is required). The Python MCP SDK mcp==1.26.0 enforces this with Pydantic's AnyUrl type, which correctly rejects None.
Container logs (startup shows v0.9.2 healthy):
v0.9.2 - building the best AI user interface.
INFO:     Started server process [1]
INFO:     Waiting for application startup.
INFO     | open_webui.main:lifespan:709 - Initializing tool servers...
INFO     | open_webui.main:lifespan:727 - Initialized 3 tool server(s)
The validation error does not appear in container logs -- it surfaces only in the chat UI response because the exception is caught and returned as the tool result string.

### Additional Information

_No response_
Originally created by @cryptomonkey2020 on GitHub (May 6, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24413 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version 0.9.2 ### Ollama Version (if applicable) N/A ### Operating System Linux (Azure Container Apps) ### Browser (if applicable) Chrome 136.0 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When an Azure AI Search Knowledge Base MCP endpoint returns tool results with `type: "resource"` content blocks, OpenWebUI should extract the `resource.text` field and pass the data to the LLM. The v0.9.2 changelog states this is fixed: "MCP resource content handling. MCP tool results with the resource content type are now correctly detected and their resource.text payload is extracted." ### Actual Behavior OpenWebUI v0.9.2 throws 84 Pydantic validation errors when calling `knowledge_base_retrieve` on an Azure AI Search Knowledge Base MCP endpoint. The error occurs because Azure returns `"uri": null` in the `EmbeddedResource.resource` object, and the MCP SDK (`mcp==1.26.0`) requires `uri` to be a valid URL string (type `AnyUrl`). **Error:** 84 validation errors for CallToolResult content.0.EmbeddedResource.resource.TextResourceContents.uri URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType content.0.EmbeddedResource.resource.BlobResourceContents.uri URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType content.0.EmbeddedResource.resource.BlobResourceContents.blob Field required type=missing, ... This is related to #24038 but is a **different failure mode**. Issue #24038 reported that `resource` content was silently dropped (v0.9.1). The v0.9.2 fix now recognizes the `resource` type but fails at Pydantic validation because Azure sends a spec-violating `"uri": null`. **Root cause**: Azure AI Search Knowledge Base MCP endpoint returns: ```json {"type": "resource", "resource": {"uri": null, "mimeType": "application/json", "text": "..."}} The MCP spec (2025-03-26) defines uri as required (type: "string", format: "uri") in ResourceContents. Azure sends null, which the Python MCP SDK correctly rejects. This is an Azure bug (spec violation), but OpenWebUI should handle it gracefully rather than crashing with 84 validation errors. The fix in process_tool_result() should catch validation errors on CallToolResult and fall back to extracting resource.text manually from the raw dict before Pydantic validation is attempted. ### Steps to Reproduce ## Prerequisites - Open WebUI v0.9.2 (Docker image: `ghcr.io/open-webui/open-webui:v0.9.2`) - An Azure AI Search service (any paid tier: Basic, Standard, etc.) - A Knowledge Base created on that search service (via Azure AI Foundry or REST API) - The Azure Search admin API key for the service This bug affects **any** Azure AI Search Knowledge Base MCP endpoint. You do not need a specific index or dataset -- any Knowledge Base will reproduce it. ## Step-by-step Reproduction ### Step 1: Verify the Azure KB MCP endpoint returns `uri: null` (independent of Open WebUI) Run this curl command, replacing `<SERVICE_NAME>`, `<KB_NAME>`, and `<API_KEY>` with your own values: ```bash curl -s -X POST \ "https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview" \ -H "api-key: <API_KEY>" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}' Expected: HTTP 200 with MCP handshake response. Then call the tool: curl -s -X POST \ "https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview" \ -H "api-key: <API_KEY>" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"knowledge_base_retrieve","arguments":{"queries":["test"]}}}' Observe the response (SSE format). Every content item has "uri": null: event: message data: {"result":{"content":[{"type":"resource","resource":{"uri":null,"mimeType":"application/json","text":"{...}"}}]},"id":2,"jsonrpc":"2.0"} This proves the bug exists at the Azure API level before Open WebUI is involved. Step 2: Deploy Open WebUI v0.9.2 docker run -d \ --name open-webui \ -p 8080:8080 \ -e WEBUI_AUTH=false \ ghcr.io/open-webui/open-webui:v0.9.2 Wait for startup (~30 seconds). Open http://localhost:8080 in Chrome. Step 3: Add the Azure KB MCP endpoint as a Tool Server 1. Navigate to: Admin Panel → Settings → Tools 2. Click "+" (Add) to add a new tool server connection 3. Configure with these exact values: Type;MCP (Streamable HTTP) Name;CCC-SCRAPER (or any name) URL; https://<SERVICE_NAME>.search.windows.net/knowledgebases/<KB_NAME>/mcp?api-version=2025-11-01-Preview Auth Type;Bearer API Key;Your Azure Search admin API key 4. Click Verify — should succeed (tool discovery works, the error only occurs during tool invocation) 5. Click Save Step 4: Create a model/agent with the tool enabled 1. Go to Workspace → Models → Create a Model 2. Select any base model (e.g., GPT-4o, Claude, etc.) 3. Under Tools, enable the CCC-SCRAPER tool server (specifically knowledge_base_retrieve) 4. Save the model 5. Step 5: Trigger the bug 1. Open a New Chat using the model created in Step 4 2. Send any message that will trigger the knowledge base tool, e.g.: What are the latest updates? 3. The model will call knowledge_base_retrieve with queries Step 6: Observe the error The tool result displayed in the chat shows: 84 validation errors for CallToolResult content.0.TextContent.type Input should be 'text' [type=literal_error, input_value='resource', input_type=str] content.0.TextContent.text Field required [type=missing, input_value={'type': 'resource', 'res...}, input_type=dict] content.0.EmbeddedResource.resource.TextResourceContents.uri URL input should be a string or URL [type=url_type, input_value=None, input_type=NoneType] content.0.EmbeddedResource.resource.BlobResourceContents.uri URL input should be a string or URL [type=url_type, input_value=None, input_type=NoneType] content.0.EmbeddedResource.resource.BlobResourceContents.blob Field required [type=missing, ...] ...(repeats for each content item returned by Azure, typically 6-10 items = 60-84 errors) ### Logs & Screenshots ### Error displayed in chat (full text from UI): 84 validation errors for CallToolResult content.0.EmbeddedResource.resource.TextResourceContents.uri URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType content.0.EmbeddedResource.resource.BlobResourceContents.uri URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType content.0.EmbeddedResource.resource.BlobResourceContents.blob Field required type=missing, input_value={'uri': None, 'mimeType':... "ocrText": null\r\n}'}, input_type=dict content.1.EmbeddedResource.resource.TextResourceContents.uri URL input should be a string or URL type=url_type, input_value=None, input_type=NoneType ...(repeats for each content item) ### Root cause proof -- Azure sends `uri: null` (violates MCP spec): Direct curl to the Azure KB MCP endpoint shows the raw response: ```bash curl -s -X POST \ "https://<service>.search.windows.net/knowledgebases/<kb>/mcp?api-version=2025-11-01-Preview" \ -H "api-key: <KEY>" \ -H "Content-Type: application/json" \ -H "Accept: application/json, text/event-stream" \ -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"knowledge_base_retrieve","arguments":{"queries":["test"]}}}' Response (SSE event): { "type": "resource", "resource": { "uri": null, "mimeType": "application/json", "text": "{\"uid\": \"240d1a58e4e3_...\", \"snippet\": \"...\", ...}" } } All 8 content items have "uri": null. The MCP spec (2025-03-26) requires uri to be a non-null string with format "uri" (ResourceContents.uri is required). The Python MCP SDK mcp==1.26.0 enforces this with Pydantic's AnyUrl type, which correctly rejects None. Container logs (startup shows v0.9.2 healthy): v0.9.2 - building the best AI user interface. INFO: Started server process [1] INFO: Waiting for application startup. INFO | open_webui.main:lifespan:709 - Initializing tool servers... INFO | open_webui.main:lifespan:727 - Initialized 3 tool server(s) The validation error does not appear in container logs -- it surfaces only in the chat UI response because the exception is caught and returned as the tool result string. ### Additional Information _No response_
GiteaMirror added the bug label 2026-05-18 06:01:59 -05:00
GiteaMirror commented 2026-05-18 06:02:07 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 6, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟢 #24038 issue: MCP tool results with resource content type are silently dropped
    This is the closest prior report of MCP resource content handling in Open WebUI. It describes the same tool-result shape (type: resource) and shows the v0.9.1 behavior that likely led to the v0.9.2 change, making it directly related as the predecessor issue.
    by jojays · bug

  2. 🟣 #20629 Issue #20629
    This closed issue is about MCP server response failures in Open WebUI. While not the same validation error, it is another MCP response-handling bug and may provide context on how Open WebUI parses or surfaces malformed MCP results.
    by unknown

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4389791835 --> @owui-terminator[bot] commented on GitHub (May 6, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟢 [#24038](https://github.com/open-webui/open-webui/issues/24038) **issue: MCP tool results with resource content type are silently dropped** *This is the closest prior report of MCP `resource` content handling in Open WebUI. It describes the same tool-result shape (`type: resource`) and shows the v0.9.1 behavior that likely led to the v0.9.2 change, making it directly related as the predecessor issue.* *by jojays · `bug`* 2. 🟣 [#20629](https://github.com/open-webui/open-webui/issues/20629) **Issue #20629** *This closed issue is about MCP server response failures in Open WebUI. While not the same validation error, it is another MCP response-handling bug and may provide context on how Open WebUI parses or surfaces malformed MCP results.* *by unknown* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-18 06:02:08 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 8, 2026):

This is an Azure bug, they send uri: null which violates the MCP spec; the MCP SDK correctly rejects it, so please report this to Azure or the MCP SDK to add a lenient parsing mode.

<!-- gh-comment-id:4408360640 --> @tjbck commented on GitHub (May 8, 2026): This is an Azure bug, they send uri: null which violates the MCP spec; the MCP SDK correctly rejects it, so please report this to Azure or the MCP SDK to add a lenient parsing mode.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#107287
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?