Giving an agent a tool does not make it use the tool

Yaman Ahlawat developed Banshee, a local audio interface and Model Context Protocol server designed to let coding agents converse with developers eyes-free through system-wide dictation, speech synthesis, and voice input. According to yamanahlawat.in's report, integrating tools into an agent's runtime environment does not ensure the underlying model will choose to execute them. While the server exposed three distinct capabilities—ask_user, speak_status, and listen_for_prompt—the author observed that autonomous agents routinely bypassed the audio tools and defaulted to rendering plain text prompts on the terminal screen.

This analysis examines how client architectures, prompt placement, and context proximity govern tool utilization across coding assistants such as Claude Code, GitHub Copilot CLI, OpenCode, Codex, Antigravity, and Pi. The breakdown details why language models favor plain text output channels over external remote procedure calls, demonstrates three distinct configuration layers used to steer runtime choices, and highlights systemic inconsistencies observed when running identical toolsets across distinct agent platforms and directory environments.

Giving an agent a tool does not make it use: what actually changed

Testing began after Banshee's three-tool suite operated reliably in manual checks, yet failed to trigger autonomously when deployed across new programming tasks. The server's ask_user function was designed to vocalize a prompt, hold until speech synthesis finished playing, open a microphone stream for the user's spoken response, and return the transcript back to the model. In Banshee's dedicated repository, Claude Code selected the audio tool on every query. When relocated to a clean directory on the identical workstation, the same agent consistently reverted to writing text inquiries directly on the monitor.

Investigations into the server logs revealed the local daemon operated without defects, ruling out runtime server failures and tool parameter errors. The author noted that early testing during screen demos faltered because dictated instructions directed the agent to explain proposed changes in writing rather than pose a question. However, even with unambiguous interrogative tasks and a compact three-tool surface that eliminated tool-selection overload, models persistently printed queries to stdout instead of calling the registered ask_user handler.

Giving an agent a tool does not make it use: how it works

Language models inherently treat standard text streams as their default communication channel, making written output the path of least resistance during token generation. Directing an agent to also repeat text aloud causes duplication, producing both screen output and an extraneous speech call. Effective guidance requires routing constraints that restrict written tokens strictly to code snippets, paths, commands, and tables, while ordering all user-directed queries into the ask_user tool. Developers can place these behavioral rules across three distinct operational layers within an agent's runtime stack.

The first insertion point resides within the Model Context Protocol initialize response under the instructions field, which Claude Code ingests alongside serverInfo to set session-wide directives. A revision dated 2026-07-28 relocates this optional field to the server/discover endpoint. The second layer uses specific tool descriptions, which sit closer to the model's immediate tool-calling decision space than server-level declarations. When conflicting instructions existed between the handshake and tool documentation, closer tool definitions overrode higher-level rules. The third mechanism employs a local Stop hook in Claude Code that executes a shell verification script, refusing to let turns terminate unless the turn executed either speak_status or ask_user.

Giving an agent a tool does not make it use: why it matters now

Architectural assumptions that language models will instinctively invoke specialized communication endpoints over plain text fail under standard operating conditions. Because external tools require the model to actively recognize, select, and structure function arguments, text streams will consistently dominate generation passes unless specifically restrained. Even when server-wide parameters are fully parsed, conflicting phrases in adjacent tool documentation can redirect calls toward unintended endpoints like speak_status without producing an execution error.

Relying solely on system-level prompts or initialization handshakes yields inconsistent enforcement across development sessions. Hooks provide a programmatic fallback by blocking model turns until tool calls occur, but they cannot evaluate semantic correctness, permitting spoken status confirmations to slip past alongside written queries. Furthermore, testing demonstrated that identical model binaries behaving as expected inside an established codebase failed to invoke identical tools when run within an unconfigured directory, exposing how fragile tool selection remains when decoupled from local workspace instructions.

Giving an agent a tool does not make it use: who is affected

Software engineers integrating MCP servers across coding agents face wide variations in tool execution behavior depending on the client harness. In empirical testing with Banshee, Pi invoked voice interactions on every run because it bypassed the MCP abstraction entirely, communicating with the local daemon over a Unix socket governed by Pi's proprietary configuration files. Claude Code executed the audio tools consistently within Banshee's local repository, yet failed in clean directories unless forced by client-side execution hooks.

Other clients displayed varying levels of compliance under identical server conditions. OpenCode triggered voice interactions most of the time without additional prompting, whereas Antigravity, Codex, and GitHub Copilot required manual user directives before invoking the tools. When queried directly from an empty workspace to verify if the server's initialization instructions were present in memory, Claude Code quoted the 20-word phrase accurately, whereas Copilot CLI returned negative confirmations before updating only when rules were embedded directly into the ask_user documentation string.

Giving an agent a tool does not make it use: what to watch

Developers monitoring client-server integrations cannot treat direct model responses as reliable audits of context window contents. When re-tested with an identical query two days later, GitHub Copilot CLI refused to inspect its instructions, stating it could not disclose hidden developer directives. This refusal demonstrated that earlier negative assertions did not verify the absence of instructions, but rather reflected shifting safety alignments within client shells that hide system metadata from introspection.

Future implementations will need to account for structural changes introduced in the 2026-07-28 MCP specification update, which replaces the initialize phase with server/discover mechanisms. As client platforms continue to evolve their proprietary gating rules and system prompts, engineers cannot rely solely on conversational directives to ensure tool adoption. Combining precise, non-conflicting tool descriptions with client-side execution gates remains the primary method for preventing autonomous agents from falling back to default text outputs.