Fixing Gemini CLI Error Discovering Prompts From GitHub MCP Error -32601

Introduction

Hey guys, let's dive into a quirky issue some of us have been encountering with the Gemini CLI – specifically, the "Error discovering prompts from github: MCP error -32601: prompts not supported". This error popped up after the merge of #4828, which aimed to load and use MCP server prompts as slash commands in the CLI. But don't worry, we're going to break it down, understand why it happens, and explore some potential solutions. So, buckle up and let's get started!

The main problem, as the error message suggests, lies in the way the Gemini CLI attempts to discover prompts from certain GitHub MCP servers. This process involves making a request to the server for a list of available prompts. However, not all MCP servers are created equal; some, like the "repos/readonly" server, simply don't support prompts. This discrepancy leads to the dreaded MCP error -32601, which essentially means the CLI is asking for something the server can't provide. It's like ordering a pizza at a burger joint – you're bound to be disappointed. The error message itself is triggered within the discoverPrompts function in the mcp-client.ts file of the Gemini CLI's codebase. This function attempts to retrieve prompts from a specified MCP server, and if it encounters an error, it logs a message to the console. However, the current error handling logic doesn't quite cover all the bases, leading to this somewhat noisy error message.

The root cause of the issue lies in the configuration of the mcpServers setting within the ~/.gemini/settings.json file. Specifically, the error is triggered when the httpUrl is set to "https://api.githubcopilot.com/mcp/x/repos/readonly". This particular MCP server, as its name suggests, is focused on repository-related information and doesn't include predefined prompts. In contrast, if the httpUrl is set to "https://api.githubcopilot.com/mcp/x/issues/readonly", the error doesn't occur. This is because the "issues/readonly" MCP server does, in fact, offer predefined prompts. To put it simply, the CLI is trying to fetch prompts from a server that doesn't have them, hence the error. This behavior highlights the importance of understanding the capabilities of different MCP servers and configuring the Gemini CLI accordingly.

Diving Deeper into the Error

To really grasp what's going on, let's dissect the error message and the code involved. The error message, "Error discovering prompts from github: MCP error -32601: prompts not supported," is pretty self-explanatory. It tells us that the CLI tried to discover prompts from the GitHub MCP server but encountered an error because prompts are not supported by that particular server. The MCP error -32601 is a specific error code indicating that the requested method (in this case, retrieving prompts) is not implemented or supported by the server. Think of it as the server saying, "Hey, I don't do that here!". This error is not necessarily a critical issue that prevents the CLI from functioning, but it can be annoying and misleading for users who see it.

Now, let's peek under the hood at the code where this error originates. The discoverPrompts function, located in packages/core/src/tools/mcp-client.ts, is responsible for fetching prompts from an MCP server. This function first attempts to make a request to the server using the mcpClient.request method, specifically requesting the prompts/list endpoint. If the server supports prompts, it should respond with a list of available prompts. However, if the server doesn't support prompts, it will return an error, which is caught in the catch block of the discoverPrompts function. The current error handling logic checks if the error message includes "Method not found," which is a common error when a method is not supported. However, the MCP error -32601 falls outside this check, causing the error message to be logged to the console. It's like the code is only looking for one specific type of error and missing another one that means essentially the same thing.

The configuration in ~/.gemini/settings.json plays a crucial role in triggering this error. The mcpServers setting allows users to specify different MCP servers to connect to. In this case, the user has configured the CLI to connect to the GitHub MCP server using the "httpUrl": "https://api.githubcopilot.com/mcp/x/repos/readonly". As we discussed earlier, this particular server doesn't support prompts. When the CLI starts up, it attempts to discover prompts from all configured MCP servers, including the "repos/readonly" server. This leads to the discoverPrompts function being called, the mcpClient.request failing, and the MCP error -32601 being thrown. It's like the CLI is dutifully following its instructions, even though one of those instructions leads to an error message.

Proposed Solutions and Their Merits

Okay, so we've identified the problem and understand its roots. Now, let's talk solutions. The original poster of this issue, kudos to them, proposed two potential fixes, and they're both pretty solid. Let's break them down and see why they work.

The first solution is a straightforward tweak to the error handling logic in the discoverPrompts function. Currently, the code checks if the error message includes "Method not found" and only suppresses the error logging if it does. The proposed solution expands this check to also ignore errors with the message "MCP error -32601: prompts not supported". This is a simple and effective way to silence the error message without addressing the underlying issue. It's like putting a band-aid on the problem – it covers it up, but doesn't necessarily fix it.

This approach is easy to implement and requires minimal code changes. It directly targets the symptom of the problem (the error message) and prevents it from being displayed to the user. However, it's important to note that this solution doesn't actually fix the underlying issue. The CLI is still attempting to discover prompts from a server that doesn't support them, which might not be the most efficient approach. It's kind of like ignoring a warning light in your car – the light might go away, but the problem could still be there.

The second solution is more comprehensive and addresses the root cause of the issue. It proposes checking the MCP server's capabilities before attempting to discover prompts. According to the Model Context Protocol (MCP) specification, servers that support prompts must declare the prompts capability during initialization. The Gemini CLI can use the mcpClient.getServerCapabilities() method to retrieve the server's capabilities and check if the prompts capability is present. If it's not, the CLI can simply skip the prompt discovery process for that server. This is a more proactive approach that prevents the error from occurring in the first place. It's like fixing the leaky faucet instead of just putting a bucket underneath it.

This solution is more robust and aligns better with the MCP specification. It ensures that the CLI only attempts to discover prompts from servers that actually support them, which is more efficient and avoids unnecessary error messages. However, this approach requires more code changes and a deeper understanding of the MCP specification and the Gemini CLI's architecture. It's a bit more work upfront, but it leads to a cleaner and more reliable solution in the long run. The original poster suggested two ways to implement this solution: either by conditioning the call to discoverPrompts() in the connectAndDiscover() function or by adding a check within the discoverPrompts() function itself. Both approaches would achieve the same result, but the latter might be slightly more modular and easier to maintain.

A Deeper Dive into the Superior Solution

Let's really unpack why the second solution, checking server capabilities, is the superior approach. It's not just about silencing an error message; it's about building a more robust and efficient system. Think of it like this: imagine you're planning a trip. Option one is to drive to every possible destination and see if there's anything interesting there. Option two is to consult a map and only drive to places that are known to have attractions. Which option is more efficient? Obviously, consulting the map first is the smarter choice.

That's essentially what the second solution does. By checking the server's capabilities, the Gemini CLI is consulting a "map" before attempting to discover prompts. It's only trying to fetch prompts from servers that have declared they support them. This avoids unnecessary requests and prevents the MCP error -32601 from ever occurring. It's a more proactive and efficient approach that aligns with the principles of good software design.

Furthermore, this solution adheres to the Model Context Protocol (MCP) specification. The MCP specification clearly states that servers that support prompts must declare the prompts capability. By checking for this capability, the Gemini CLI is following the rules of the protocol and ensuring interoperability with different MCP servers. This is important for long-term maintainability and compatibility. It's like speaking the same language as other systems – it makes communication much smoother.

Another advantage of this solution is its flexibility. If, in the future, a new MCP server is added that supports prompts but doesn't declare the prompts capability, the CLI will still function correctly. The error message will be displayed, alerting the user to a potential issue. This allows for graceful handling of unexpected situations and makes the system more resilient to change. It's like having a safety net – it catches you when things don't go as planned.

In contrast, the first solution, simply suppressing the error message, is more of a short-term fix. While it does address the immediate problem of the error message being displayed, it doesn't prevent the underlying issue from occurring. The CLI is still attempting to discover prompts from a server that doesn't support them, which is inefficient and could potentially lead to other issues down the line. It's like treating the symptom without addressing the disease.

Practical Implications and Real-World Scenarios

So, we've established that checking server capabilities is the better solution, but let's think about how this plays out in the real world. Imagine you're a developer using the Gemini CLI to interact with various MCP servers. You might be working with servers that provide information about code repositories, issue trackers, or even internal company knowledge bases. Each of these servers might have different capabilities, and some might support prompts while others don't.

If the Gemini CLI simply suppresses the error message, you might be left wondering why prompts aren't working on a particular server. You might spend time troubleshooting the issue, only to realize that the server simply doesn't support prompts. This can be frustrating and time-consuming. It's like trying to use a tool that's not designed for the job – you might get it to work eventually, but it's going to be a struggle.

On the other hand, if the Gemini CLI checks server capabilities, you'll have a much smoother experience. The CLI will only attempt to discover prompts from servers that support them, and you'll avoid the unnecessary error message. This makes the CLI more user-friendly and efficient. It's like having the right tool for the job – it makes the task much easier and more enjoyable.

Furthermore, consider the scenario where you're developing a tool that integrates with the Gemini CLI. If the CLI is simply suppressing the error message, your tool might not be able to accurately determine which servers support prompts. This could lead to unexpected behavior or errors in your tool. It's like building a house on a shaky foundation – it might look good on the surface, but it's not going to last.

By checking server capabilities, the Gemini CLI provides a more reliable and predictable interface for other tools to interact with. This makes it easier to build integrations and extend the functionality of the CLI. It's like building a house on a solid foundation – it provides a stable base for future development.

Conclusion: Choosing the Right Path

In conclusion, the "Error discovering prompts from github: MCP error -32601: prompts not supported" might seem like a minor annoyance, but it highlights an important principle in software development: address the root cause, not just the symptoms. While simply suppressing the error message is a quick fix, checking server capabilities is the more robust and efficient solution. It aligns with the MCP specification, avoids unnecessary requests, and provides a more reliable and predictable experience for users and developers alike.

So, the next time you encounter a similar issue, remember to think critically about the underlying problem and choose the solution that provides the most long-term value. It might take a little more effort upfront, but it will pay off in the end. And hey, that's what being a great developer is all about, right? Keep those code clean and keep those errors at bay, guys!