feat(mcpserver): expose public get_tool(name) on MCPServer

[arimu1]

Summary

Adds a public MCPServer.get_tool(name) -> Tool | None that delegates to the existing ToolManager.get_tool, so callers can look up a registered tool without using the private _tool_manager.

This completes the public tool registration surface next to add_tool() / remove_tool().

Use case (from #3162): after registration, update a tool's inputSchema (e.g. attach oneOf / discriminated action schemas) via the returned tool's mutable parameters dict.

tool = mcp.get_tool("act")
if tool is not None:
    tool.parameters = {...}  # advertised on tools/list

Fixes #3162

Notes on issue discussion

Maintainer asked whether customizing inputSchema at registration time would be enough. This PR still implements the issue's proposed API (get_tool) because:

1. It is the minimal CRUD completion (add / get / remove)
2. It enables post-registration inspection and mutation without new registration kwargs
3. An optional input_schema= override on add_tool / @tool remains a possible follow-up and is orthogonal

Test plan

• test_get_tool_returns_registered_tool_or_none
• test_get_tool_exposes_mutable_parameters_for_schema_updates
• Neighboring TestServerTools add/remove tests still pass
• ruff + pyright clean on touched files

uv run --frozen pytest \
  tests/server/mcpserver/test_server.py::test_get_tool_returns_registered_tool_or_none \
  tests/server/mcpserver/test_server.py::test_get_tool_exposes_mutable_parameters_for_schema_updates \
  -q

AI disclosure

Assisted by AI (Grok / Cursor) for implementation and tests; human-reviewed before submit.

[github-actions]

This PR has been closed automatically. It's still a draft, but we close those early so you don't put in more time only to have it closed the moment you mark it ready.

This repo only keeps pull requests open when they come from a maintainer, or from a contributor a maintainer has assigned to the linked issue, and this PR doesn't link an open issue yet.

• If you're already assigned to an issue for this, add Fixes #<n> to the description and the PR will reopen on its own.
• If there's no issue yet, please open one instead: what you ran into, why it matters for your use case, and a minimal reproduction. That context is super important to us and is what we use to decide what to prioritise.
• If there's an issue but you're not assigned, add Fixes #<n> anyway so they're linked, then engage on the issue itself by confirming the repro or describing the approach you'd take. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. If you are assigned, this PR reopens automatically.

You're welcome to keep pushing commits here (just avoid force-pushing, since GitHub can't reopen a rewritten branch), but that on its own won't get the PR reviewed or the issue assigned, and realistically most auto-closed PRs stay closed. There's no need to open a new PR either way.

CONTRIBUTING.md has the full reasoning, but in short:

• We're a small team with very little capacity to review community PRs right now.
• Many recent PRs are AI-generated with little human review, and reviewing one carefully still costs a maintainer as much time as it ever did. A well-described issue is usually more useful to us than the code.

Maintainers: reopen, remove missing-issue-link, or add bypass-issue-check to override.