Repository navigation
ClientSessionGroup has no routed read_resource / get_prompt (only call_tool) #3579
Description
Description
### What I ran into
`ClientSessionGroup` aggregates tools, resources, and prompts into one view, and
`call_tool(name, ...)` routes to the session that owns the tool. But that routing
exists only for tools. There's no equivalent way to read an aggregated resource
or fetch an aggregated prompt through the group.
### Why it matters
To read a resource or get a prompt, a caller has to track the owning
`ClientSession` themselves and bypass the group, which defeats the "one object,
one view" purpose of the abstraction. The asymmetry is surprising given
`call_tool` is already there.
### Proposed change
Add `read_resource(name, ...)` and `get_prompt(name, arguments, ...)` mirroring
`call_tool`: resolve the aggregate key (honoring `component_name_hook`) to the
owning session via resource/prompt reverse indexes, forward the real wire
URI/name, carry the same `allow_input_required` overloads, and clean the indexes
up on `disconnect_from_server`.
### Example
```python
result = await group.read_resource("Library.hours")
prompt = await group.get_prompt("Greeter.greet", {"name": "Ada"})
Activity
harshini2004-tech commentedon Sep 24, 2026
Hi! I'd like to work on this issue if it's available. I'm interested in understanding the
ClientSessionGrouprouting/indexing design and implementingread_resource()andget_prompt()with the corresponding tests. Happy to take this up if no one else is working on it.baselarw commentedon Sep 24, 2026
Thanks for the interest! I actually already have this implemented and tested —
PR #3577 has read_resource() and get_prompt() mirroring call_tool's routing,
with unit tests, in-memory end-to-end tests, and docs. It's currently
auto-closed by the repo's bot since I'm not yet assigned to this issue (not a
linking problem — the PR does reference #3579 correctly), but it'll reopen
automatically once a maintainer assigns me.
Since the work's already done, might be worth a maintainer taking a look at
#3577 rather than starting a second implementation from scratch — happy to
have you review it or help with anything else on this if you're interested in
the area.
Jaswanth1902 commentedon Oct 2, 2026