-
Notifications
You must be signed in to change notification settings - Fork 33
Foundry Agent Service + Search KB MCP tool fails with masked errors (401/405) during agent invocation #5
Copy link
Copy link
Open
Description
Summary
When following the Episode 1 cookbook to connect Foundry Agent Service to an Azure AI Search knowledge base via MCP, agent invocation fails in responses.create(...) with tool_user_error. We observed multiple failures that appear to be partially masked by Foundry, making root cause diagnosis difficult.
cc: @farzad528 (Farzad Sunavala)
Environment
- Repo:
microsoft/iq-series - Notebook:
1-Foundry-IQ-Unlocking-Knowledge-for-Agents/cookbook/foundry-iq-cookbook.ipynb - API versions used in notebook:
- Search KB MCP endpoint:
api-version=2025-11-01-preview - Project connection ARM call:
api-version=2025-10-01-preview
- Search KB MCP endpoint:
- SDKs:
azure-search-documents==11.7.0b2azure-ai-projects
What we observed
1) Initial retrieval errors (direct KB retrieve path)
- Serialization issue fixed by using:
retrieval_reasoning_effort=KnowledgeRetrievalLowReasoningEffort()
- Then got
404from model endpoint due to AOAI endpoint format (.../openai/v1suffix). Normalizing to base resource endpoint fixed this. - Then got
401indicating missing data action for principal:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx(managed identity for search service)
2) Step 5 (Foundry Agent + MCP tool) errors
- First failure:
Connection 'earth-kb-mcp-connection' not found.- Root cause: project mismatch between
FOUNDRY_PROJECT_ENDPOINTandFOUNDRY_PROJECT_RESOURCE_ID(resolved by aligning both to same project).
- Current failure after project alignment:
Error encountered while enumerating tools from remote server .../knowledgebases/earth-knowledge-base/mcp. Details: Response status code does not indicate success: 405 (Method Not Allowed).
Key diagnostics
- Connection now exists in the same Foundry project and points to:
https://xxxx.search.windows.net/knowledgebases/earth-knowledge-base/mcp?api-version=2025-11-01-preview
- Manual protocol checks against MCP endpoint:
GETto MCP endpoint ->405- JSON-RPC
POSTtools/listto same endpoint -> succeeds and returnsknowledge_base_retrieve
This suggests a transport/protocol mismatch in tool enumeration path (or a masked underlying permission error) when Foundry invokes the remote MCP server.
Request
Could the team please investigate the Foundry↔Search MCP integration behavior here, especially:
- Whether Foundry tool enumeration is using an unsupported method/headers for this MCP endpoint.
- Whether Foundry is masking underlying authorization failures from Search and surfacing only generic
405 tool_user_error. - Any required role assignments specifically for project managed identity vs search managed identity in this integration path.
Happy to provide additional logs/correlation IDs if needed.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels