Evaluation logs show that a GitHub Copilot agent is frequently calling a web search tool to look up information that already exists in the repository's internal documentation. This is causing slow, expensive runs. What tuning action should be taken?
Select an answer to reveal the explanation.
Short Explanation and Infographic
If your employee keeps calling 411 to find your company's own phone number, you don't raise their phone budget — you give them the internal directory. Refining tool access means replacing the expensive external tool with a purpose-built internal one that gives the agent exactly what it needs.
Full explanation below image
Full Explanation
Tool access refinement is a key tuning lever when evaluation reveals that an agent is using the wrong tool for a given task. The issue here is that the agent has a general-purpose web search tool but needs a specialized internal documentation search capability.
Why A is correct: Disabling web search eliminates the costly misuse. Adding an MCP tool that indexes and searches internal documentation gives the agent a targeted, fast, and cost-effective way to find the information it needs. This is a direct tool access refinement: remove what isn't appropriate, add what is.
Why B is wrong: Increasing the token budget would make the problem more expensive, not less. The agent would make even more web searches. Budgets should be set after behavior is correct, not used to accommodate bad behavior.
Why C is wrong: Adding instruction-based guidance ('avoid web search') is a soft control that may not be reliable. The agent may still choose web search when it 'thinks' it's appropriate. A hard control — removing the tool — is more reliable than an instructional preference.
Why D is wrong: Moving to a pure prompt-based architecture removes all tool capabilities, which would prevent the agent from doing its job at all. The problem is tool selection, not tool-use architecture.