Linking a chat provider should not force the MCP Go SDK into the build

Type: feature request.

Need

A tool that links a chat provider but has no MCP surface should be able to ship without the MCP Go SDK.

Use case

go-tool-base spec 0202 makes the mcp feature a link kind so a regulated tool can ship without gitlab.com/phpboyscout/go/mcp and the SDK. Verifying it on a scaffold with the ai feature and claude-local linked (2026-09-18), the SDK is still in the build after the mcp link is removed:

$ go mod why github.com/modelcontextprotocol/go-sdk/internal/authutil
gitlab.com/phpboyscout/branchgen/cmd/branchgen
gitlab.com/phpboyscout/go/chat-anthropic
gitlab.com/phpboyscout/go/chat-mcptools
github.com/modelcontextprotocol/go-sdk/mcp

chat-anthropic v0.14.2 requires chat-mcptools v0.1.1 (its mcptools.go), which imports the SDK, so every tool that links the Claude provider carries github.com/modelcontextprotocol/go-sdk whether or not it uses the chat side's MCP tool bridge. The same likely holds for the other provider modules; only chat-anthropic was measured.

Expected outcome

Linking a chat provider does not by itself put the SDK in the build. The MCP tool bridge becomes something a tool opts into (the estate's link pattern, or a separate module the host imports), so go version -m on a tool with a provider and no bridge lists no modelcontextprotocol module.

Non-goals

Changing the bridge's behaviour for tools that do use it; anything on the go/mcp side, which is already framework-free.