How should we debug mcp's? What is the recommended approach?

[alainkaiser]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hi guys, first of all thank you very much for your effort regarding the csharp-sdk 🚀 I love working with it.
The one thing which I am not 100% how to approach is Testing / Debugging locally. My typical workflow looks something like this:

• Project setup
• Tools / Prompts development
• Integrate it locally into Claude or Cursor for testing via the following sample config:

    "sitewerk-debug-mcp": {
      "command": "/usr/local/share/dotnet/dotnet",
      "args": [
        "run",
        "--project",
        "/Users/alainkaiser/Documents/source/sitewerk/ai/sitewerk-mcp/Sitewerk.Mcp/Sitewerk.Mcp/Sitewerk.Mcp.csproj"
      ]
    }

Everything works as expected with this flow. But I would love to have support via the Debugger in my IDE (Rider) to be able to work/debug with Breakpoints and all the nice stuff. I tried several things already to make this work but couldn't find a working solution (attaching Rider to existing Processes etc.).

Do you guys have some experience with that? How should I approach this? Is it even possible?

Thanks for your feedback!

[altinoren]

I would also like to hear about people's workflow on debugging. I'm on Windows, using VS Code. Attaching to process after Claude starting never loads symbols no matter what I do. The latest launch.json I tried:

`
{

"version": "0.2.0",

"configurations": [

  {

    "name": ".NET Core Attach with Symbols",

    "type": "coreclr",

    "request": "attach",

    "processId": "${command:pickProcess}",

    "justMyCode": false,

    "symbolOptions": {

      "searchPaths": [

        "${workspaceFolder}\\Server\\bin\\Debug\\net9.0",

      ],

      "loadAllSymbols": true,

      "enableSearchPath": true

    },

    "logging": {

      "engineLogging": true

    }

  }

]

}
`

I load the project in Visual Studio 2022 on the side, attach to the running process from it and it works though. So currently I use both to develop and debug at the same time :)

[alainkaiser]

@altinoren Interesting that it works with Visual Studio. How does the Configuration in Claude looks like on your end? Similar to mine? In Rider on Mac, I can't get it working sadly...

[schaveyt]

@alainkaiser @altinoren As recommended by the modelcontextprotocol pages, debugging section, I complete skip the "fancy" clients and use the purpose-built inspector app

My workflow:

For a Remote SSE MCP Server

1. From vscode, run in c# debug as with any .net cli exe
2. From terminal, run npx @modelcontextprotocol/inspector
3. Then invoke the tool with argument directly 🚀

For local STDIO MCP server

1. From terminal, run npx @modelcontextprotocol/inspector details here
2. Set Transport to STDIO and make the inspector launch you exe
3. From vscode, debug via attached to .net process

[alainkaiser]

@schaveyt Thanks for your inputs, will try it like that in a quiet minute :)

[rukhsarahmad-gep]

@schaveyt I am using the same but i am facing one issue in debugging to remote SSE endpoint . lets SSE endpoint https://xyz.com/mcpservice/sse - SSE connect work fine but next call for message it change or we can say message endpoint change to https://xyz.com/message which raise issue endpoint not found. is there anyway to mention message endpoint or some sort of configuration to resolve this ? ideally it should be https://xyz.com/mcpservice/message

[schaveyt]

I'm not following. If using SSE and then the endpoint http://localhost:5129/sse using the inspector tool it just works.

[sonomirco]

What I currently have is a desktop app that I use to test the tools and their functions, and debug them directly.
Then I use the inspector to debug them as tools.
Sometimes I used the log from the client to evaluate how the tools were called.

What do you think of having an eval solution like these two?
https://www.mcpevals.io/
https://github.com/dylibso/mcpx-eval