Issue on ask then poll Remote MCP Server connected under FoundryIQ

Hello Ken,

Greetings! Thanks for raising this question in the Q&A forum.

What you are seeing is expected behavior given how the MCP Server knowledge source currently works in Azure AI Search, not a bug in your configuration. The root cause is that an MCP Server knowledge source performs a single round of tool selection and invocation per subquery. At query time, the LLM configured in the knowledge base reviews the configured tools, selects which ones to call based on the user query, and generates the arguments for each call, and Azure AI Search then invokes the selected tools on the MCP server and returns the results as ranked references. There is no iterative tool calling loop inside a single retrieve operation where the model can look at the result of one tool call and decide to issue a follow up call.

This is exactly why the ask then poll pattern breaks. The Genie MCP server's intended flow requires the caller to see the conversation_id and response_id from genie_ask, then repeatedly call genie_poll_response until status indicates completion. Azure AI Search's knowledge base orchestration calls genie_ask once as a single tool invocation, gets back the JSON payload, and treats that as the final reference content for the subquery. It never loops back to call genie_poll_response because that would require multi turn reasoning over tool outputs within the same retrieval call, which this preview feature does not implement yet. Increasing retrieval reasoning effort from low to medium will not change this, since reasoning effort controls query planning and rewriting, not whether the engine chains multiple tool calls together.

Here is how to work around this until native ask then poll support is available:

1. Wrap Genie behind an adapter MCP server Stand up a small intermediary MCP server (an Azure Function or Container App works well) that exposes a single synchronous tool, for example genie_ask_and_wait. Internally this adapter calls genie_ask on the real Genie MCP server, then loops on genie_poll_response until the status reaches a terminal state, and only then returns the final answer back to the caller. Point your Azure AI Search MCP Server knowledge source at this adapter instead of the Genie server directly.

Set maxRuntimeInSeconds generously on the retrieve request Since the adapter in step 1 will block while polling internally, make sure the retrieve call allows enough time for the full ask and poll cycle to complete.

POST https://<service-name>.search.windows.net/knowledgebases/<kb-name>/retrieve?api-version=2025-11-01-preview
{
  "messages": [...],
  "knowledgeSourceParams": [
    {
      "knowledgeSourceName": "<your-mcp-knowledge-source>",
      "maxRuntimeInSeconds": 120
    }
  ]
}

1. Confirm you are on the correct preview API version MCP Server knowledge sources are only available starting with the 2026-05-01-preview REST API. If your project is still pointed at an older preview, the knowledge source may behave unpredictably for tool selection in addition to the ask then poll gap.
2. Submit feedback for native multi step tool chaining Since this is a preview capability and the gap you found is a real product limitation rather than a misconfiguration, raising it through the Azure AI Search feedback channel on GitHub helps the product group prioritize support for asynchronous, poll based MCP tools in a future revision.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.