Goose has integrated a new mechanism for handling Model Context Protocol (MCP) tools, targeting how their schemas are presented to the model. The implementation, detailed in Goose PR #13378, adds a deferred loading strategy. This story concerns the merged Goose code change; it does not establish a separate tagged product release or a change to the MCP protocol itself.
By default, Goose keeps its existing eager behavior, where tool schemas are provided to the model. Deferral is opt-in. When GOOSE_TOOL_DEFERRAL=lookup is set, Goose lists available MCP tool names in the system prompt rather than providing their schemas immediately. The model can call enable_tools with exact tool names; the selected schemas become available on the next response. The merged implementation validates those names against model-visible MCP tools. If any requested name is unknown or app-only, the enable request fails as a whole. Lookup is the only implemented strategy; the PR does not add search or wildcard matching.
For builders, this creates an explicit selection step between seeing a tool’s name and seeing its schema. That can matter when designing an agent workflow: a tool not enabled is not among the schemas the model can use for its next response. But this is a change in schema availability, not a new authorization layer. Calling enable_tools does not execute a tool or grant permission to run it. The enable call uses Goose’s existing permissions, hooks and result-recording path, and a later tool execution still requires ordinary permissions. Knowing how to call a tool and being allowed to call it remain separate conditions.
The configuration also permits selected MCP tools to remain eager through GOOSE_TOOL_DEFERRAL_ALWAYS_LOAD, a comma-separated list of exact model-visible names. Entries may include extension prefixes; surrounding whitespace is trimmed. These exceptions matter only with deferral enabled and do not bypass availability or visibility checks. Platform tools stay eager, while code mode keeps its own catalog. If the setting is unset, the existing eager behavior remains; the new workflow does not silently become the default.
Enabled names are recovered from successful, paired enable-tool requests and responses in conversation history. The lifecycle test exercises enabling, reconstruction and compaction, then checks that /clear removes the enabled state. The PR includes an eager-override test scenario that verifies an always-loaded MCP tool can execute, another MCP tool remains deferred, and an app-only tool remains hidden. For an agent that resumes from history, the enable state follows persisted conversation results; clearing that history requires the model to enable a tool again if it is needed.
There is a specific validation caveat. The PR notes that test and clippy commands were run on an earlier implementation, but were not rerun after the final global-settings and eager-override revision. Formatting and diff checks did pass after those changes. The final revision therefore lacks those post-change test and clippy reruns. No measured token savings, performance gain, adoption or broad rollout is established by the PR, and none is needed to describe the implementation.
The practical significance is narrow but consequential for workflow design: Goose can make schema exposure an explicit, exact-name step while leaving permission enforcement where it was. Builders evaluating the change should keep those two layers distinct and account for the extra selection step, rather than treating deferred schemas as either an execution capability or evidence of a measured efficiency improvement.