Feature Request: session-scoped tool inventory API (list MCP-discovered tools loaded into a session)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- csharp, go, python, typescript
- Domain
- api, backend-api-design, developer-experience
Research direction
Start by reading the createSessionRpc implementation and the existing session.rpc.{mcp,skills,plugins,extensions}.list() wrappers. Check CONTRIBUTING for Python, Go, and .NET parity requirements, and review api.schema.json even though the server-side RPC handler is outside this repository. Done means the supported SDK bindings expose a consistent session-scoped tools.list result, subject to the internal RPC becoming available.
Written by the indexing model from the issue text.
Description
Problem
No public API enumerates the tools loaded into a session — built-ins merged with MCP-discovered tools from SessionConfig.mcpServers. Closest existing surfaces don't cover it:
client.rpc.tools.list({ model? })is server-scoped — built-ins only, no session-loaded MCP tools.session.rpc.mcp.list()returns server connection status (name,status,error?,source?), not tools or counts per server.session.mcp_servers_loadedevent fires once on session startup but carries the same server-status-only payload — no tool list.session.mcp_server_status_changedcarries{ serverName, status }only.session.tools_updatedevent payload is just{ model: string }.
A session can report mcp.status: "connected" and still expose zero tools (wrong CLI flags, version mismatch, schema error) — there's no SDK-side way to detect this.
Why it's needed
- Operational visibility. Confirm before the first turn that an MCP server actually contributed the expected tools, not just that its process started.
- Diagnostic UIs. Surface per-server tool counts to operators of BYOK / multi-MCP deployments.
- Test assertions. Verify a given MCP wiring exposes the expected tool set without spawning a parallel
tools/listprobe. - Parity with prior MCP clients. Other MCP integrations (e.g.
@ai-sdk/mcp) expose discovered tools as an enumerable map; consumers migrating to copilot-sdk lose this.
Contribution scope
api.schema.json ships from the closed @github/copilot npm package (the public github/copilot-cli repo is just the installer). The server-side RPC handler must live in the internal CLI — external contributors can only touch SDK bindings/wrappers in this repo, not the underlying RPC implementation.
Proposed solution
Add a session-scoped tools.list RPC, mirroring the existing client.rpc.tools.list() but reflecting per-session config:
// in createSessionRpc:
tools: {
list: async (): Promise<SessionToolsListResult> =>
connection.sendRequest("session.tools.list", { sessionId }),
handlePendingToolCall: /* unchanged */,
}
export interface SessionToolsListResult {
tools: Tool[]; // namespacedName populated for MCP tools (e.g. "playwright/browser_navigate")
}
Returns built-ins (post-excludedTools/availableTools filtering) + MCP-contributed tools. Consistent with existing session.rpc.{mcp,skills,plugins,extensions}.list() shape. Parity in Python/Go/.NET per CONTRIBUTING.
A leaner alternative: enrich McpServer with toolCount?: number and/or tools?: string[]. Less consistent with the existing pattern but lighter.
Related
- #944 — same underlying gap, surfaced as a question.
- #735 — adjacent (manipulating session tool set without teardown).
Environment
@github/copilot-sdk@0.3.0
- Dominant language
- Java
- Stars
- 10.5k
- Forks
- 1.5k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 130
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/copilot-sdk
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2760 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2759 ·
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 85/100
github/copilot-sdk#2758 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
github/copilot-sdk#2709 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
github/copilot-sdk#2673 ·
All issues in github/copilot-sdk
Similar issues
-
certification
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Openbug ecr
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Needs: Triage Type: Feature request
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AntennaPod/AntennaPod#8794 ·
-
awaiting triage bug Causes friction Hop Gui P1 P2 Transforms
Difficulty 2/5 1-3 hours Newbie friendliness 75/100