# Reported issues for my-cool-proxy Pod holds 17 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [my-cool-proxy](/mcp/my-cool-proxy). ## Most discussed ### Dead sessions get cleaned up too slowly See title; this is particularly an issue when using stdio MCP servers or sampling. - stdio MCP servers aren't aggressively tidied up (this is a combination of long session lifetimes and server state isolation concerns preventing us from reusing processes). - In the sampling shim, if the configured ACP agent itself uses the gateway, that can create many stale sessions very quickly, particularly in the case of sampling-with-tools. The first issue on its own is relatively minor and shouldn't scal [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/14) · 2026-02-11 · closed · 3 comments ### Singleton MCP servers Support marking servers as singletons, meaning that a single process/server session can be safely used across multiple gateway sessions. Reduces memory overhead and session startup latency. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/23) · 2026-02-11 · open · 2 comments ### Decide what to do when sampling is only partially supported by a client Do we shim our more complete support in this case, even though the client's native integration might have a better UX? Do we add even more config for this? [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/19) · 2026-02-11 · closed · 2 comments ### Server is not leveraged effectively by Claude Code and Claude Desktop anymore Claude Code and Claude Desktop appear to no longer inject the `instructions` field into the context, which we use to steer the agent to use the gateway correctly. This is probably related to them both enabling tool search by default now. We should move that information into the `execute` tool description to handle this; upstream servers should then get indexed by tool search appropriately. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/93) · 2026-04-29 · closed · 1 comment ### Protocol-level errors crash the gateway ``` [11:06:53.576] ERROR (25587): Error calling github.search_code: err: { "type": "McpError", "message": "MCP error -32603: failed to search code with query '\"did not call\" tool retry discord': GET https://api.github.com/search/code?order=desc&page=1&per_page=5&q=%22did+not+call%22+tool+retry+discord&sort=indexed: 403 API rate limit exceeded for user ID 131398524. If you reach out to GitHub Support for help, please include the request ID F05B:2D2DE7:2399BBB:2468E00:69EE543D an [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/92) · 2026-04-26 · closed · 1 comment ### Maintain tool-details call state between restarts Currently, if the gateway restarts, `execute` starts to fail again warning that `tool-details` hasn't been called, confusing some agents. We should try to maintain that state so this doesn't happen. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/79) · 2026-02-24 · closed · 1 comment ### Fail fast if agent has not followed the tool discovery workflow Require the agent to have at least called `tool-details` before invoking `execute` with a given tool. We could go further and require the entire workflow, but `tool-details` is the most important part. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/56) · 2026-02-19 · closed · 1 comment ### Upstream tool errors can be ignored by the agent/interpreter MCP tools have an isError field in their tool results, which is true when the tool logic has encountered an error (this is distinct from an error RPC message, which is returned when the tool actually fails to execute due to e.g. not existing). Currently, agents can extract the tool result data without checking isError, resulting in unexpected behaviors when the tool result data is actually additional error context. To fix this, we should just throw an error with the full tool result and script [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/50) · 2026-02-16 · closed · 1 comment ## Most recent ### Append notice in tool result after restoring a session Our own session state is maintained but upstream sessions may not be, particularly for stdio servers. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/82) · 2026-03-12 · open · 0 comments ### Upstream server versions are prefixed with "v" even if they aren't numeric When connecting to the GitHub MCP server, the gateway logs this: ``` Preloaded info for server 'github': github-mcp-server vgithub-mcp-server/remote-... (54 tools) ``` It expects the version to always be semver-like when that isn't always going to be the case. We should probably just drop the "v" uniformly and let servers put whatever they want there. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/53) · 2026-02-17 · closed · 0 comments ### Emulate permissions over elicitation See title; this is important for people who don't filter high-risk tools out of servers. Requires shimming elicitation for clients that don't support it as well. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/49) · 2026-02-15 · open · 0 comments ### Declare tool annotations See title; we can't really do this for the `execute` tool, but we can do this for all the others. Most tools are read-only and idempotent. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/38) · 2026-02-12 · closed · 1 comment ### Support client-hosted tasks This one is kind of dumb and I'm not sure if it's possible because nothing uses this and clients can't optionally use tasks according to server capabilities. That is, if we broadcast support for client-hosted tasks, most servers using non-task elicitation and sampling will just straight-up break, so we need to somehow know if the server will understand client-hosted tasks without them calling us first. It'll only work well if we can always broadcast support for client-hosted tasks and servers a [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/31) · 2026-02-11 · open · 0 comments ### Get on the MCP Clients list No idea if they'll accept this but it's something to try after implementing all of the remaining shims - it'd be funny if they allowed it and I have no other reason for trying [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/30) · 2026-02-11 · open · 0 comments ### Validate and document execute tool timeouts I'm not actually sure if it has any business implementing timeouts as that's entirely the responsibility of the upstream servers, but if we do have timeouts in the execute tool (I forget) and want to keep them, we should document them clearly in the user docs. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/28) · 2026-02-11 · closed · 1 comment ### Shim support for elicitation if not natively supported This is a complicated one, as it requires some form of UI. Maybe we expose a regular webpage that we reconfigure via query parameters? We could leverage `open` to do this on-demand without user friction. This could also be a way to shim MCP Apps in the future, as well. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/20) · 2026-02-11 · open · 1 comment ### Revamp documentation for clarity The user documentation is already starting to get dense due to the amount of configuration options available. We should restructure it to focus on the most basic MCP server setup first, and then dig down into the additional config required for specialized features on different pages, maybe with a table of the key MCP features and docs for each one. The most basic setup should involve as little reading as possible. [Read the thread](https://github.com/karashiiro/my-cool-proxy/issues/17) · 2026-02-11 · closed · 0 comments The remaining reports are on [the project's issue tracker](https://github.com/karashiiro/my-cool-proxy/issues).