How to Debug your MCP Server

So maybe you've gone through the Epic AI MCP workshop and you're like, oh man, this is so sweet. I'm going to build my own MCP server. And you get to your editor, and maybe you copy some of the code from the MCP workshop so you're all ready. But now you're changing things and you're like, wait, how did you get the inspector up and running? Because the Epic Workshop app actually does all of that for you and manages it for you as you're going through the whole exercise.

It's a wonderful experience, but now you're left to your own resources. What do you do? And also you want to use an LLM to actually interact with your MCP server. How do you set that up? So that's what I want to show you, so you can be really effective in building and working with your MCP servers right away.

So here we have a simple MCP server that is just adding two numbers together. And the way that we have this set up is we've got a dev script. So I can run that, npm run dev. And that's going to output that the MCP server is running on standard IO but I can't interact with it in this way I have to have a client that hooks up to it and interacts with it well it just so happens that the model context protocol inspector is exactly what you're looking for. Now, there are actually other MCP clients that you could use that even work right in the terminal.

In fact, even the model context protocol inspector has a CLI that you can interact with your MCP server as well. There's also fast agent that you can take a look at, but I want to use a web interface. I'm a web guy. I like user interfaces. So what we're going to do is we're going to say npm run inspect.

And that is going to use the MCP inspector binary that is available from the model context protocol inspector. So I open this up, and now, there it is. That's the inspector UI that I was looking for. So I want a standard I-O. That's what we're working with.

In the future, you'll probably want server-sent events or streamable API or HTTP. But we're going to go with standard I O. And our command is just what we used to run our server right here. So we're going to use npm. And then our arguments for npm are run dev.

Well, if we try that, that actually does work because we happen to be running the MCP server or running the inspector directly in the same directory where our packages or where our repository is. And so as long as we're doing that then we're just fine But we're gonna see how that's not going to work in every context right here But here we are we can say list tools we can add we can say here's 45 plus 23 great. It's 68 how wonderful and Here you can go to resources prompts ping sampling all that stuff right in the MCP inspector. Pretty cool. Now, I want to actually interact with this with a large language model, maybe in cursor because I'm already in cursor and I'm using that.

So The way that you configure that is you go to your cursor settings and you go to MCP, you say add new global MCP server, and then we're going to say MCP example. And here, cursor knew what I was going to do, maybe because I've been practicing this. But we have NPM, and I added silent to this because we don't want to actually confuse the output of our or the client who's going to be listening to standard io and if npm is spitting out a bunch of stuff it could confuse it. So we add silent, now NPM is not going to spit out a bunch of extra information about what script it's running. And then we're also adding this prefix.

And because we don't actually know where NPM is going to be invoked from, what the working directory is. And so with prefix, we can be very specific and say, hey, this should run in the MCP example directory. And so wherever we are with the cursor, it's always going to run this dev script in this directory. That's what the prefix flag does. So that's what you need to do there.

And then run dev. Great. And so if we close this, we're going to get our MCP example. It shows up right there. Now, sometimes this will actually start out as red, and that's super annoying and ugly.

Oh, no, it says client could not connect or something. All you do is hit the refresh and it will restart the server and it should work from there. I'm not sure why it starts out sometimes as red, but just hitting refresh is good. And actually if you make any changes to your server, then you need to hit restart as well because what this is doing is it just spawns this process. It knows nothing about NPM.

It doesn't know even, like, as far as it knows, we're running a Docker container or something. So it actually doesn't know anything about what's going on under the hood. It can't automatically refresh as you change files and stuff. And so When you change a file, you hit the little Reload button, and it will spawn a new process for you. And now we can say, please add 4462123.

And it should pick up our tool. And we can inspect what it's doing in here. And we can see our result. And there we are, 569. Awesome.

So with that, we can now interact with our MCP server using an LLM. Unfortunately, as the date of this recording, May 8th, 2025, Cursor does not support anything other than tools. And so if you wanted to test out prompts and resources then you're kind of stuck. Except we can use Cloud and we can configure Cloud to do this. So let's open up Cloud and inside of Cloud you can actually open up the settings.

That's a command comma on a Mac. And we can go to Developer and Edit Config. And that's going to open up your File Explorer to where this config file is. For me, this is the location. And here you're going to configure it.

And guess what? It actually looks a lot like the configuration here. So we're going to copy this, paste it right there. And now we have to actually restart Cloud for this to work. So I'm going to quit Cloud, open up Cloud again.

And we're going to get a nice error here. And the reason we're getting this error is because on my system, however I'm launching Cloud, does not have access to NPM. So when it tries to spawn a NPM process, it doesn't know what NPM is. So it just blows up. This is really annoying and really unfortunate.

And I could figure out how to get it so that I launch Cloud in such a way that it has access to NPM, even when I launch it from Raycast like I am. Or I can just use the terminal. And that's what I do all the time. It's really annoying, but it works just fine. So we're going to open Cloud from the terminal.

And now, npm is in the path. And so it knows where to find npm to actually run that command. So now I can search for my code and tools. And boom, I've got the Add tool. And I can say, please add one, blah, blah, blah, blah, blah, to whatever.

Yeah, whatever. And Cloud thinks that it knows how to add numbers together and it probably is right. So hopefully you don't run into this with your own tools that are actually real. But let's say, please use the add tool to make it use my tool so I can test it out. And we can see what the result is right here.

And that works out just fine. And here's the unfortunate thing. Every time you make a change to your MCP server, you've got to close down Cloud, open it up again. It's a big pain, but it is what it is. There could be a way to make it a live refresh, or maybe we can just use the watch flag or something, but I found I don't really trust it.

And so I just would rather close it down, open it up again, and that's my typical workflow when working with the MCP server. So I hope that is helpful to you as you get into developing your own MCP servers. Of course, in a typical practical application, you're probably wanting to host this remotely and so you need to add authentication and all of that and there's more to talk about from that. But if you're just getting into this and you just want to be able to run an MCP server and practice and play around with it in these different tools, this is how you get that started.