Document MCP tool filter naming across SDKs

[syedkazmi14]

Fixes #869

This PR documents that MCP tools registered via mcp_servers are exposed to the runtime as <server-key>-<tool-name>, and adds consistent guidance across the SDKs for how to reference those tools in session tool filters and agent configs.

Changes included:

• Removed the Python-only MCP tool-name normalization change and related tests
• Documented the <server-key>-<tool-name> convention across the SDK READMEs
• Updated the relevant available_tools / excluded_tools / custom_agents / default_agent docs to explain when to use mcp:<server-key>-<tool-name> / ToolSet.addMcp() and when to use <server-key>-<tool-name> directly

[SteveSandersonMS]

Thanks for digging into this, and for the detailed writeup in #869. The repro is clear and this is a genuinely confusing failure mode (zero tools, no error, hooks never fire).

Before going further with the code change, I want to flag something that changes the right scope here: the <server-key>-<tool-name> convention is actually already documented in this SDK (and every other language SDK), just not in the place you were looking. See ToolSet.add_mcp() in python/copilot/_mode.py:

def add_mcp(self, tool_name: str) -> ToolSet:
    """Add an MCP tool pattern (e.g. "github-list_issues" or "*")."""

The same docstring/example exists in the nodejs, dotnet, java, go, and rust SDKs too (ToolSet.addMcp() in each). So available_tools=["mcp:my-server-list_tables"] (or ToolSet().add_mcp("my-server-list_tables")) already works correctly today. The gap is that this isn't mentioned in the README or in the SessionConfig/MCPRemoteServerConfig docstrings that people read when passing a plain list[str], which is exactly the scenario in your repro.

Given that, I think the right-sized fix here is docs-only, and should probably span all the SDKs rather than just Python, since the naming convention is a backend/CLI-level thing and every language hits the same trap:

• Add a line to each SDK's README (and the available_tools/excluded_tools/custom_agents/default_agent docstrings) explaining the <server-key>-<tool-name> convention and pointing to ToolSet.addMcp()/mcp: prefix as the reliable way to target MCP tools.

I'd rather not add the auto-alias-expansion logic in _mode.py/client.py. A few reasons:

• It only fixes Python, so JS/Go/Rust/Java/.NET users still hit the exact same silent failure.
• It changes runtime behavior silently (e.g., an excluded_tools entry that previously no-op'd against an MCP tool would now actually start excluding it), which could be a surprising behavior change for existing callers.
• It's solving via a guess (matching against configured mcp_servers.tools) something the SDK already lets users express exactly and unambiguously via mcp:<server-key>-<tool-name>.

Would you be up for narrowing this PR to the doc changes (README + docstrings) and applying the same wording across the other SDK directories? This is a good contribution, just want to make sure it lands in the most maintainable spot.

[syedkazmi14]

Thanks, that makes sense. I agree that silently expanding bare names in Python would introduce ambiguous behavior and leave the other SDKs inconsistent.

I’ve narrowed this PR to documentation, removed the normalization code and related tests, and applied consistent guidance across the SDK READMEs and the relevant available_tools, excluded_tools, custom_agents, and default_agent docstrings. The updated docs explain both the <server-key>-<tool-name> convention and the mcp: / ToolSet.addMcp() forms.

The warning for unmatched tool filters still seems potentially useful, but I agree that would be better handled separately and centrally so all SDKs receive the same behavior.