Debugging MCP Service Registration Issues in Cursor IDE

Hello everyone, I'm Kason. Many of you are already using Cursor in your daily coding. Recently, I encountered an issue with "registered MCP services not being called" while using Cursor. After thorough investigation, I determined it was a bug in Cursor itself. This article discusses the debugging process, which was quite interesting.

What is MCP? Large language models (LLMs) have only multimodal (text, video, images...) output capabilities and cannot use external tools, such as: unable to access the internet, unable to query data from databases, unable to operate browsers. To give LLMs the "ability to use external tools," we need to build the following process:

The blue part of the process is the "LLM expressing what it wants to do," while the green part is "actually doing it." The blue part was first implemented by OpenAI and called Function Call (later renamed Tool Call). Other mainstream LLMs have followed this functionality (Claude calls it Tool use).

We can see that the blue part is a specification for defining "how LLMs express what they want to do." For example, here's how Claude defines a Tool use for calling a method named get_weather to get weather information:

{
"name": "get_weather",
"description": "获取指定地区的天气",
"input_schema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "指定地区，比如：北京市"
},
"unit": {
"type": "string",
"enum": ["摄氏度", "华氏度"],
"description": "温度单位，“摄氏度”或“华氏度"
}
},
"required": ["location"]
}
}

As for where the get_weather method is and how to execute it (the green part), the Tool use specification doesn't define this, causing the green part implementation to be very chaotic. For example, if both of us implemented "chatboxes that can search the internet," the "internet search" functionality couldn't be replaced between us because our implementations have different parameters, outputs, and calling methods.

MCP (Model Context Protocol) emerged to standardize the green part. It's a client-server architecture specification and data transmission specification, along with specific implementations. As long as you follow the MCP specification, all implementations of "internet search" (and any other green parts) can be replaced with each other.

The problem I encountered was simple - I implemented a "weather query service" according to the MCP official documentation, and it successfully registered in Cursor:

But when I mentioned "weather-related questions," Cursor didn't call the weather MCP:

First, I suspected my MCP service itself had issues. So I registered the weather MCP in Cline (an open-source version of Cursor):

When I asked "What's the weather like in Shanghai?" we can see that Cline successfully called the weather MCP:

This indicates the weather MCP itself is fine. Next, how does Cline trigger MCP? Since it's open source, it's easy to debug its running process. Simply put, when we input anything in Cline, Cline's system prompt includes two pieces of information: first, your input (e.g., "What's the weather like in Shanghai?"), and second, a very long Cline environment information (consuming 10,000+ tokens).

This environment information mainly includes: "Basic Introduction" - defining assistant identity and basic behavior, "Tool Use" - detailed explanation of available tools and their usage methods, "MCP Services" - introduction to MCP's role and registered MCPs, "File Editing" - explanation of file editing tool usage methods, etc.

The weather MCP definition appears in the "MCP Services" section, so Cline (essentially the underlying LLM) knows when to call it. Since Cursor is closed source, we can only obtain necessary information from the side. First, by capturing Cursor Composer mode requests and analyzing the system prompt, we find that the overall token consumption is less than 1/10 of Cline's system prompt.

Although it doesn't explicitly mention MCP-related content, it mentions the "Tool Calling" specification. Following this specification, we find that in the tools field (the previously mentioned Tool use), Cursor defines many tools, such as codebase_search, read_file, run_terminal_cmd, list_dir, grep_search, edit_file, file_search, delete_file, reapply, and diff_history.

Cursor Composer Agent can develop projects because it relies on these tools. Additionally, all MCPs registered in Cursor also appear here as tools. For example, we can see that besides weather MCP, I also registered a Sequential Thinking MCP:

In Cursor's LLM request, the tools field contains a tool named mcp__sequentialthinking. From this, we can discover the problem - both weather and Sequential Thinking successfully registered, but the request didn't include weather-related Tool use. This is why Cursor sometimes cannot successfully call MCP - it didn't include that MCP as Tool use in the request, so the LLM naturally doesn't know there's an MCP available to call.

Currently, Cursor has a bug in MCP service registration, causing some successfully registered MCP services not to be included as Tool use when requesting LLMs. This is the reason why Cursor cannot successfully call MCP.

PS: If you're interested in Cursor's system prompts, you can like this article. If there are enough likes, I'll write another article analyzing Cursor's various (Chat, Composer) system prompts.

References

[1]

MCP Official Documentation: https://modelcontextprotocol.io/introduction