[lxcxjxhx]

Fixes #3846

---

Four ClientSession methods document only their input-required kwargs, so the rendered reference hides the arguments a caller has to pass. The block was written once for the newer kwargs and copied to the neighbours.

Method	Documented	Added
send_request	metadata	request, result_type, request_read_timeout_seconds, progress_callback
read_resource	3 kwargs	uri (the only parameter without a default), meta
call_tool	4 kwargs	name, arguments, read_timeout_seconds, progress_callback, meta
get_prompt	3 kwargs	name, arguments, meta

On the overload question raised in the issue: mkdocs.yml sets no show_overloads option, so mkdocstrings renders the overload signatures and takes the docstring from the implementation — the blocks belong on the implementation, which is where they are. I did not add Args blocks to the @overload stubs; that would duplicate four copies of the same text.

Verification

• AST comparison against the previous head with docstrings excluded: identical, so only the docstrings changed.
• Every parameter of the four methods now appears in its Args: block (checked by parsing the module with ast).
• pytest tests/client/test_session.py → 94 passed.
• ruff check and ruff format --check on the file: pass.

Credit to media-ctrl for reproducing this on main and for widening the scope from four methods to the surrounding copies.

I did not add the "walk the public client methods and assert every parameter appears in Args" test suggested in the issue — that is a behaviour change for the test suite and worth its own PR if you want it. Say so and I will open it.

[github-actions]

This PR has been closed automatically. 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 you aren't currently assigned to #3846.

If a maintainer assigns you to #3846, this PR reopens on its own and there's nothing more you need to do here. Assignment is a maintainer call based on capacity; comments that only ask to be assigned don't factor in. What does help is engaging on the issue itself by confirming the repro, explaining why it matters for your use case, or describing the approach you'd take.

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.