Skip to main content

Debugging your MCP integration

As the list of available tools keeps growing, sooner or later something will not work and some debugging becomes necessary. In this post I look into ways to troubleshoot your MCP integration.

Let's dive in!

To understand what we need to debug you need to be aware of the architecture of an MCP integration. It follows a client-server architecture, where AI models can request data through a host with an MCP client (e.g. GitHub Copilot, Claude Desktop, …) from MCP servers, which then retrieve relevant information from local or remote sources.

This means that when a problem occurs that there (at least) 2 places to look at.

Debugging the MCP client

Let’s start by looking into the client. The way you need to debug the client is completely dependent on the host. I’ll focus on GitHub Copilot and Claude Desktop.

GitHub Copilot

When VSCode encounters an error while trying to interact with an MCP server, you get a red error indicator in the Chat window:

Click on the icon and choose Show Output from the dropdown menu.

This will open up the logs in the Output window.

 Remark: Another option is to run MCP: List Servers from the Command Palette, select the server, and then choose Show Output.

Claude Desktop

The ‘go to’ location in case of troubles with MCP support in Claude Desktop is the MCP log file. This file can be found by going to File –> Developer –> Open MCP Log file… in Claude Desktop:

This log file contains a lot of information:

  • Server connection events
  • Configuration issues
  • Runtime errors
  • Message exchanges

 

Debugging the MCP server

The way to troubleshoot and debug a specific MCP server will completely depend on the MCP server implementation. So there are no strict rules or guidelines I could share here.

But I do want to point out the MCP inspector tool. This tool allows you to test and debug your MCP server.

When using SSE

When using SSE, you can  install and run the tool  directly through npx:

npx @modelcontextprotocol/inspector

This will start the tool on a specific local URL ( http://127.0.0.1:6274 in our example).

Browse to that location to open the Inspector.

Now we can connect to our MCP server by specifying the SSE transport and specifying the URL of our MCP server:

Click on Connect afterwards connect to the MCP server.

Now you can go to Tools and click on List Tools to get the list of available tools and even give a tool a try:

When using STDIO

When using STDIO, you can include the command to start the MCP server when installing and running the tool:

npx @modelcontextprotocol/inspector <command> <arg1> <arg2>

The rest of the experience remains the same.

More information

Debugging - Model Context Protocol

Use MCP servers in VS Code (Preview)

Inspector - Model Context Protocol

Labels:

Popular posts from this blog

.NET 8–Keyed/Named Services

A feature that a lot of IoC container libraries support but that was missing in the default DI container provided by Microsoft is the support for Keyed or Named Services. This feature allows you to register the same type multiple times using different names, allowing you to resolve a specific instance based on the circumstances. Although there is some controversy if supporting this feature is a good idea or not, it certainly can be handy. To support this feature a new interface IKeyedServiceProvider got introduced in .NET 8 providing 2 new methods on our ServiceProvider instance: object? GetKeyedService(Type serviceType, object? serviceKey); object GetRequiredKeyedService(Type serviceType, object? serviceKey); To use it, we need to register our service using one of the new extension methods: Resolving the service can be done either through the FromKeyedServices attribute: or by injecting the IKeyedServiceProvider interface and calling the GetRequiredKeyedServic...
Read more

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.
Read more

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...
Read more