Anthropic's MCP: First impressions as a developer
I jumped in and created a MCP server to connect to my personal data stored on Verida. Here's my initial experience.
Two days ago, Alex Albert from Anthropic AI formally announced the Model Contex Protocol:
“An open standard we've been working on at Anthropic that solves a core challenge with LLM apps - connecting them to your data.
No more building custom integrations for every data source. MCP provides one protocol to connect them all.”
It’s important to make a clarification here:
Model Context Protocol doesn’t negate the need to build custom integrations for every data source. MCP is a protocol that enables a LLM to have a common pathway to integrate with every data source. The integrations still need to be built for each data source.
I thought I’d try it out to see how well it worked and if it was a viable way to connect my data in Verida (email, calendar, google docs, telegram messages etc.) to Claude.
Here’s a detailed breakdown of my experience.
Background research
I started by skimming through the MCP documentation, starting with the Getting Started guide. I am familiar with using Claude via AWS Bedrock, so planned on integrating directly there, however it became clear that MCP is only supported on Claude desktop as of today:
After groking the architecture, it realized I would need to create a MCP server, then configure Claude desktop to know about my server. Not too difficult I thought.
So I jumped into the documentation on creating my first MCP server with typescript.
Creating a MCP server
After reading the MCP server for typescript example I learned there are different types of interfaces in the protocol such as; resources, prompts, tools. I clearly needed a “tool” to enable querying my data, but wasn’t sure about the other interfaces.
I decided to take a closer look at the Typescript SDK in Github and discovered a collection of example servers. As I had the basic concepts in mind, modifying an existing server would probably be easier.
I found a PostgreSQL example server, this seemed perfect as a starting point. Reading the code, it provides two key interfaces:
Resources: This lists the available database tables available to be queried, presumably so Claude knows about them.
Tools: The actual “query” tool to extract data from the database for Claude to process.
I proceeded to spend the next hour creating a new Github repo with this PostgreSQL server as a starting point. I added the Verida SDK as a dependency in the package.json and copied some existing code to query my private data stored on Verida.
After some usual wrangling with typescript build processes, I finally had something that I hoped would be close to working.
Now, how to test?
Testing my MCP server
For the most part, the MCP documentation is quite good. It clearly has large gaps, where there are placeholders for future content, but the current content is clear and concise. There’s a clear section on debugging and it points out they’ve built a really great inspector to help with testing your MCP server.
I spun up the inspector in no time and opened it in my local browser.
I could easily navigate to see the “Resources” I had exposed. I could also navigate to “Tools” and manually execute my “query” tool.
This is where I hit my first real issue. Debugging currently sucks. The documentation has some basic dot points on development workflow. Basically, you have change your code, rebuild your code, reconnect the inspector, then test again.
There is no ability (that I’m aware of) to attach my IDE to a debugger for real-time debugging. There is also no ability to console.log output to see what’s going on in the server as this causes problems with Claude.
As such, my debugging ended up being throwing Errors to get insight into values of variables on the code and those Errors propagated up to the inspector for me to review. Very slow and cumbersome, but I assume Anthropic are working on a better flow here.
I was able to work through my issues and ended up with my two interfaces fully tested and working via the MCP inspector:
Schema resources: List all the available database schemas that can be queried
Query tool: Run a database query against one of the database schemas
Connecting my MCP server with Claude
As mentioned above, MCP is only supported on the Desktop version of Claude (which I didn’t have). I downloaded, signed in and was ready to test.
First, I needed to configure Claude Desktop to know about my MCP server. In the Claude Desktop settings there is a “Developer” section, which can open a JSON configuration file where you enter your MCP configuration.
This was pretty straightforward to do, and once I restarted Claude, the settings showed my MCP server was available.
However, I hit a snag:
Claude was showing this error message with no further information. According to the MCP documentation there should be logs on my local computer to help debug, however I have none.
After a lot of mucking around, I realized there was an issue with my schema resources endpoint which I fixed. Now, after restarting Claude Desktop it appeared I was connected properly.
There is a little tool icon that appears:
Clicking that icon shows information about the MCP tools that are connected.
Ok, I’m all set, now let’s test this out
Using Claude with my MCP Server
Unfortunately, this is where things started to fall down.
Claude really struggled to discover my server and use it, even with my increasingly specific attempts to use it.
I started with something simple, summarize my recent calendar entries.
It’s clear here that Claude couldn’t make the connection between me asking for “calendar entries” and the CALENDAR database schema that was available via my MCP Server.
I thought I’d ask it what it know about the connected MCP servers, but alas it doesn’t seem to know:
I tried to be much more explicit and ask for information about the available schema resources, but that didn’t work either:
I tried a different approach and use more keywords:
Now, this did work! (sort of).
This prompt appeared asking for my approval to allow the query tool to run:
I accepted, but as you can see from the screenshot above, it failed to return any results. This is because calendar_entries is not the correct schema name, it should be CALENDAR (which is returned from my MCP server resources endpoint).
At this point, I’m unclear if the inability for Claude to establish the link between the schema resources (CALENDAR) and the query tools is something I haven’t done well enough in my MCP server or is more an issue with Claude.
So, I decided to be very very explicit with running a query:
So, this is much better. You can see it has sent a MCP server tool request with the correct schemaName of CALENDAR, and then it even tried a different variation when that didn’t work.
But.. it didn’t work and this is where I gave up (for now).
The query was clearly executing in the MCP server, but was returning an error in the top right of Claude desktop:
As mentioned above, I have no logs available on my local machine to give more insight on this error.
I replicated the exact same CALENDAR query using the MCP inspector console and it works perfectly every time, which is rather confusing.
Summary
MCP seems promising. The concept of a common interface for connecting LLM’s to external data sources is going to be really important moving forward.
I had some issues with debugging and getting things to work, however I expect those things to be improved over time. All things considered, it was a fairly good developer experience for a first release of a new protocol.
I am concerned about the lack of Claude’s ability to recognize that a prompt can use an available tool and the challenges of linking that tool precisely enough to make it work correctly. It’s not really viable to be asking Claude very specific questions to use a tool, it really needs to seamlessly integrate it with your usage.
This was my first attempt at using MCP, so it’s quite possible I missed a few things that could have improved my server and produced better results. That being said, this is a warts and all breakdown after spending a couple of hours playing with MCP and I expect it would be similar to the experience of other developers trying MCP for the first time.