Foundry Agent Refusing to Use Tools

Question

Foundry Agent Refusing to Use Tools

Abanes, Cameron A 80

I am currently working an a foundry agent, but it is refusing to use any of the tools that I have connected to it. It previously was able to use these tools, and I haven't made any changes to its connectivity with them. I currently have a custom MCP server, a Azure Databricks Genie space and a knowledge base which points to several indexes in an Azure AI Search service.

Even when I explicitly instruct the agent to use these tools (ie "Dev: Use the xxxx-knowledge base to answer this question" or "use the MCP server to give me a reading on x") it does not use them. It'll actually make up readings and data, and when I point out that it's doing that it'll say something along the lines of "sorry, I'll use it next time". My instructions also explicitly state to only use tools, and if it can't to alert the user.

I have tried stripping back my instructions to see if it was too restrictive (namely safety & privacy & scope limitations, solely for testing purposes) but no luck.

When I send the initial prompt to the agent (ie "hello"), I can see under traces that there are three "mcp_list_tools" blocks that are called, each corresponding to one of my connected tools. Here is an example from one of them.

{
  "name": "mcp_list_tools",
  "context": {
    "trace_id": "conv_8e5aebf7b721ebc000XBNWPMtYxsUH5uBfnzvMPqvpEwVWmPIB",
    "span_id": "mcpl_8e5aebf7b721ebc0006a1ee6c118cc8190a1170ba1da2585ea",
    "conversation_id": "conv_8e5aebf7b721ebc000XBNWPMtYxsUH5uBfnzvMPqvpEwVWmPIB"
  },
  "kind": "Tool",
  "parent_id": "resp_8e5aebf7b721ebc0006a1ee6c0a82c81908935d0951cf53615",
  "attributes": {
    "span_type": "Tool",
    "duration": 0,
    "type": "mcp_list_tools",
    "id": "mcpl_8e5aebf7b721ebc0006a1ee6c118cc8190a1170ba1da2585ea",
    "agent_reference": {
      "type": "agent_reference",
      "name": "XYZ",
      "version": "44"
    },
    "response_id": "resp_8e5aebf7b721ebc0006a1ee6c0a82c81908935d0951cf53615",
    "partition_key": "8e5aebf7b721ebc000",
    "server_label": "AzureDatabricksGenieCustom",
    "tools": []
  },
  "start_time": "2026-06-02T14:20:49.000Z",
  "end_time": "2026-06-02T14:20:49.000Z",
  "status": {
    "status_code": "OK"
  }
}

Copilot said that the "tools" brackets being empty could be a problem.

Has anyone else had a similar problem? Is there any way to test whether the connection to the tool itself is broken or if it's just a problem with agent instructions?

0 comments

Answer accepted by question author

Karnam Venkata Rajeswari 4,435 Microsoft External Staff Moderator

Hello @Abanes, Cameron A ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

The current evidence indicates that the issue is occurring during tool discovery rather than tool invocation. The empty tools: [] result is the strongest indicator that no callable tools are being exposed to the runtime.

After reviewing the behavior and trace output, the most significant observation is the successful execution of the mcp_list_tools operation with an empty tool collection.This indicates that the tool discovery request is completing successfully, but no callable tools are currently being exposed to the agent runtime.

When tools are not available in the runtime tool list, the agent cannot invoke them, even when instructions explicitly request tool usage. In that situation, the model may generate responses based on its own knowledge, which aligns with the observed behavior of returning generated readings or data instead of invoking the configured MCP server, Azure Databricks Genie space or knowledge base.

The common causes for this behavior can include:

Tool registration issues
Authentication or authorization problems
Connection configuration issues
Tool metadata or schema issues
Changes within the connected tool service itself

The trace data provides the strongest indication.

Tool discovery occurs before the model decides whether a tool should be invoked. Since the runtime is currently returning tools: [] there are no callable tools available for selection.

As a result:

Explicit instructions such as "use the MCP server" cannot succeed until tools are successfully discovered.
Additional prompt tuning is unlikely to resolve the current behavior.
Troubleshooting needs to be focused first on tool discovery and connectivity.

Please check if the following steps help-

Verifying tool discovery across all connected sources Review traces for:
- Custom MCP server
- Azure Databricks Genie connection
- Knowledge Base / Azure AI Search connection
Confirm whether:
- All integrations return empty tool lists, or
- Only a specific integration is affected
This will help determine whether the issue is isolated or shared across multiple tool connections.
Validating project connections, authentication, and permissions Please verify:
- Project connection status
- OAuth consent and authentication configuration
- Managed identity assignments
- Service principal permissions
- Databricks workspace access permissions
- Azure AI Search access permissions
Testing tool discovery outside of the agent runtime Validate whether the MCP server is exposing tools independently of the agent. Compare results:
- If tools are returned externally but Foundry continues to return tools: [], the investigation should focus on the connection layer, runtime integration, or agent configuration.
- If no tools are returned externally, the investigation should focus on the MCP server implementation and tool registration process.
Reviewing server-side logs Review logs for:
- Authentication failures
- Authorization failures
- Tool registration issues
- Tool manifest generation failures
- Databricks Genie initialization issues
- Recent deployment or dependency changes
A service can remain reachable while still failing to publish tools successfully.
Validating tool definitions and metadata If any connected service has recently been updated or redeployed, confirm:
- Tool definitions are still present
- Tool names have not changed
- Metadata remains valid
- Configuration changes are not filtering or excluding tools
Confirming the active agent version The traces indicate that a specific published agent version is being used. Recommended validation:
- Confirm the expected tool configuration exists in the active version.
- Create a new agent version with the same tool set.
- Start a fresh conversation and compare traces.
This helps rule out stale configuration or publishing issues.
Creating a minimal validation scenario Create a new test agent containing:
- A single tool
- Minimal instructions
- A simple validation request
If the test tool appears successfully, the issue is likely specific to the original configuration. If the same behavior occurs, focus should move to project configuration, authentication or runtime integration.
Reattaching or recreate tool connections If discovery continues to return empty results:
- Recreate the MCP connection
- Recreate the Databricks Genie connection
- Reattach the knowledge base connection
This can help eliminate stale metadata or connection state issues.
Validating Azure AI Search knowledge base connectivity For the knowledge base integration, verify:
- Search connection availability
- Index accessibility
- Managed identity permissions
- Private networking configuration
- Retrieval-related traces

The following references might be helpful , please check them out

Please let us know if the response was helpful

Thank you

Please "Accept" the answer with an "Upvote" if the response was helpful. This will be benefitting other community members who face the same issue.

0 comments

1 additional answer

Your answer

Answer 1

The empty tools: [] in the mcp_list_tools trace indicates the agent is not seeing any tools from that MCP server (and likely from the other connections as well). In that state, the model has nothing it can call, so it falls back to answering from its own knowledge and “hallucinates”, even if instructions say to use tools.

Use the following checks to isolate whether this is a connection/toolbox issue or an instruction/model issue.

Verify the toolbox can see tools

For MCP and other remote tools, tools/list returning zero tools is a primary symptom of connection or manifest issues.

If using the Foundry toolbox:
- Call tools/list for the MCP server and Databricks Genie connection.
- If tools/list returns zero tools for MCP or A2A tools, the likely cause is invalid or missing connection credentials for the remote MCP server or A2A agent.
- Fix:
  - Verify the project_connection_id exists in the Foundry project and that credentials are correct.
  - Test connectivity by calling the MCP server directly with the same auth.
  - If using managed identity (PMI, agent identity, or MI), verify the correct RBAC role assignments for the caller on the target resource.

For OpenAPI tools, if tools/list returns zero tools, validate the OpenAPI spec (must be valid OpenAPI 3.0/3.1 with proper paths, operationId, and parameter schemas).

Fix MCP server definition issues

If the MCP server is reachable but tools are not exposed correctly, Foundry can reject the tool schema.

Common MCP issues:

"Invalid tool schema" occurs if:
- The MCP server definition uses anyOf or allOf, or
- A parameter accepts multiple types.
Fix:
- Update the MCP server definition to avoid anyOf/allOf and multi-type parameters.
- Redeploy and reattach the MCP server to the agent.

Confirm MCP auth and project connection

If the MCP server returns Unauthorized or Forbidden:

Confirm the MCP server supports the chosen authentication method.
Verify credentials stored in the project connection are valid and up to date.
For services like GitHub, use least-privilege tokens and rotate them regularly.

Validate server_label and allowed_tools

Even if the MCP server is connected, the model may not call tools if they are filtered out:

Ensure server_label and server_url in the MCP configuration match what the agent expects.
If allowed_tools is set:
- Confirm the tool names exactly match what the MCP server exposes.
- Tool names are case-sensitive and must follow the MCP specification (no whitespace or special characters).
- Temporarily remove allowed_tools and re-run tools/list to confirm the full tool list.

Check region/model support for tools

If Foundry reports “tool not supported” or silently omits tools:

Tool availability requires support from both the model and the region.
Check the region availability table and the model support table; if either shows No for a tool, it cannot run.
Confirm the model is actually deployed in the project and region being used.
If necessary, try a different region or a different model deployment that supports the required tools (for example, Code Interpreter is not available in some regions).

Use tool_choice to force tool usage once tools are visible

After confirming that tools/list returns the expected tools and traces show non-empty tools arrays:

Set tool_choice to required so the model must call one or more tools.
Keep instructions clear and specific about when to use each tool (for example, “Use the knowledge base for any question that requires indexed document content”).
Review run traces again to confirm tool calls and inspect tool inputs/outputs.

Distinguish connection issues from instruction issues

If mcp_list_tools spans continue to show "tools": [], the problem is with tool discovery/connection (MCP server, Databricks Genie, or toolbox configuration), not instructions.
Once mcp_list_tools shows a non-empty tools list but the model still does not call tools:
- Use tool_choice = required.
- Simplify instructions to emphasize tool usage.
- Confirm no conflicting settings (such as tool_choice = none).

By first ensuring tools/list and mcp_list_tools return actual tools, then enforcing tool_choice = required, it becomes clear whether the issue is connectivity/toolbox configuration or agent behavior.

References: