fix(mcpserver): ignore the return annotation when finding the context parameter

[hishammoizuddin]

Fixes #3298

What's wrong

find_context_parameter() loops over everything typing.get_type_hints() returns. That
mapping includes the function's return annotation under the special "return" key, which
isn't a parameter.

So a handler annotated -> Context (or a union containing it) gets recorded as having a
context parameter named "return", and the context is injected under that name when the
handler is called. return is a keyword and can't be declared as a parameter, so the call
always fails — registration succeeds and the breakage only shows up at invocation time.

It isn't only tools: prompts and resource templates resolve their context through the same
function. Reverting just context_injection.py and exercising one of each:

TOOL     is_error: True | Error executing tool tool_fn: tool_fn() got an unexpected keyword
argument 'return'
PROMPT   RAISED: MCPError Internal server error
RESOURCE RAISED: MCPError Error creating resource from template res://x

The fix

Drop the "return" key before scanning the hints, so only real parameters are considered.

Why this should be safe

Every path that previously resolved to "return" failed at invocation, so nothing could
have been depending on it — this only turns a guaranteed failure into working behaviour.

Handlers that have both a real Context parameter and a Context return annotation were
already fine, because get_type_hints() yields parameters before return (you get
['a', 'ctx', 'b', 'return'] for def f(a, ctx, b) -> Context). I've pinned that ordering
in a test so a later refactor can't quietly break it.

Tests

New tests/server/mcpserver/test_context_injection.py:

• the positive path (a parameter annotated Context is found)
• -> Context isn't reported as a parameter
• -> Context | None isn't reported as a parameter
• a real Context parameter still wins when the return annotation is also Context
• end-to-end through Client(server) for a tool, a prompt and a resource template

Five of the seven fail without the src/ change.

./scripts/test passes (100% branch coverage, strict-no-cover clean), ruff and pyright
are clean on the changed files, and the new tests pass on 3.10 and 3.14.

Related PRs

No overlap with #3236 or #2623, which touch the same module for unrelated reasons. I
test-merged both against this branch and neither conflicts.

---

Disclosure: I used AI assistance (Claude Code) for this change. I've reviewed it myself
and can explain it.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[github-actions]

Thanks for the contribution. This repository only keeps pull requests open when they're linked to an issue that a maintainer has assigned to the author — CONTRIBUTING.md explains why and how we work. This PR has been closed for now because you aren't currently assigned to #3298.

If a maintainer would like this change as a PR from you, they'll assign you to #3298 and this PR will reopen automatically — there's nothing more you need to do. (If you opened the issue, this PR already shows up on its timeline.)

There's no need to open a new PR — this one will be reopened. While it's closed, please push any updates as new commits rather than force-pushing, since GitHub can't reopen a PR whose branch has been rewritten.

Maintainers: reopening this PR, removing the missing-issue-link label, or adding bypass-issue-check bypasses the check.