This template is for Azure DevOps Remote MCP Server feedback only.
Important
Internal Microsoft users: Do NOT file issues here. Please use the internal Teams channel to share your feedback.
Issue Type
Select the option that best describes your issue.
Tool(s)
repo_file (action: get_content)
Description
repo_file with action: get_content on the remote server returns an EmbeddedResource
whose uri is a repo-relative path with no URI scheme (e.g. /package.json). Clients built
on the MCP Python SDK v1 reject the entire response with a pydantic ValidationError, so
file content cannot be read at all through a Python MCP client or gateway.
The local server v2.9.0 returns plain TextContent for the same file and does not have
this problem. The two implementations have diverged.
Actual response (remote)
{"type": "resource",
"resource": {"uri": "/package.json", "mimeType": "text/plain", "blob": "e30K"}}uri is a bare repo-relative path. Per RFC 3986 a URI requires a scheme, so this is not a
URI — which is what strict clients reject.
This was captured by talking to https://mcp.dev.azure.com/{org} directly over
Streamable HTTP with no proxy or gateway in the path — a plain initialize →
notifications/initialized → tools/call handshake with an Entra bearer token. The
payload is byte-identical to what is observed through a gateway, so nothing downstream is
reshaping it.
The local server does not have this problem
Local Azure DevOps MCP Server v2.9.0, same org, repo, path and file, driven over stdio:
{"result":{"content":[{"type":"text","text":"{}\n"}]},"jsonrpc":"2.0","id":2}Plain TextContent — no resource block, no base64, no URI. This validates under every MCP
SDK, Python included.
Side by side:
|
Local v2.9.0 |
Remote |
| Content type |
text |
resource |
| Encoding |
UTF-8 |
base64 |
uri |
none |
/package.json (schemeless) |
| Python SDK v1 client |
works |
ValidationError |
The payloads carry identical content — remote's e30K base64-decodes to {}\n, byte-for-byte
what local returns. Only the envelope differs.
This template is for Azure DevOps Remote MCP Server feedback only.
Important
Internal Microsoft users: Do NOT file issues here. Please use the internal Teams channel to share your feedback.
Issue Type
Select the option that best describes your issue.
Tool(s)
repo_file(action:get_content)Description
repo_filewithaction: get_contenton the remote server returns anEmbeddedResourcewhose
uriis a repo-relative path with no URI scheme (e.g./package.json). Clients builton the MCP Python SDK v1 reject the entire response with a pydantic
ValidationError, sofile content cannot be read at all through a Python MCP client or gateway.
The local server v2.9.0 returns plain
TextContentfor the same file and does not havethis problem. The two implementations have diverged.
Actual response (remote)
{"type": "resource", "resource": {"uri": "/package.json", "mimeType": "text/plain", "blob": "e30K"}}uriis a bare repo-relative path. Per RFC 3986 a URI requires a scheme, so this is not aURI — which is what strict clients reject.
This was captured by talking to
https://mcp.dev.azure.com/{org}directly overStreamable HTTP with no proxy or gateway in the path — a plain
initialize→notifications/initialized→tools/callhandshake with an Entra bearer token. Thepayload is byte-identical to what is observed through a gateway, so nothing downstream is
reshaping it.
The local server does not have this problem
Local Azure DevOps MCP Server v2.9.0, same org, repo, path and file, driven over stdio:
{"result":{"content":[{"type":"text","text":"{}\n"}]},"jsonrpc":"2.0","id":2}Plain
TextContent— no resource block, no base64, no URI. This validates under every MCPSDK, Python included.
Side by side:
textresourceuri/package.json(schemeless)ValidationErrorThe payloads carry identical content — remote's
e30Kbase64-decodes to{}\n, byte-for-bytewhat local returns. Only the envelope differs.