It was possible without MCP, but arguably this convention made the whole thing a bit more reliable and consistent. It also provides some safe guards against how people might get this data alternatively. People can now ask "What was the ocean acidity like for January 2016 to March 2017 in the Salish Sea? And Claude will reliably draw up a graph for all stations in the Salish Sea monitoring this parameter, report which values have or have not been QC'd, show a map of the stations' locations, etc.
It works better than a skill. It allows me to integrate a protected endpoint more easily for the end users. It only knows about read-only endpoints. No risk of people handing credentials to Claude to make it easier. Overall it makes it pretty seamless to bundle a bunch of domain knowledge into the server, providing access and empowerment to a team of scientists who can but would really prefer not to write API queries when they have one-off questions about our data.
It could also be done with a CLI or something, but, the goal is to provide a powerful interface using simpler tools. An API or CLI would defeat the purpose.
[–] mattlondon 2 days ago
[–] steve_adams_86 2 days ago
That aside, the MCP middleman in this case provides a few things:
1. Most importantly, it models and enforces the complex domains of the API and underlying data in a way that most people can't easily, so it maps English requests to sensible queries effortlessly. Claude uses discovery endpoints and constructs queries in seconds, is instructed to check parameters about each endpoint, and generally handles a lot of domain-specific concerns that users typically won't have a full grasp of.
Imagine a sensor network with dozens of stations and thousands of sensors. Which one should you query, for which type of data? What parameters does it take? How granular is the data? These are easy to keep track of if you're familiar with the station and have some API requests on hand that you lean on frequently. It's much harder when you want to know things about an area or type of sensor data you're less familiar with. The MCP server solves for this quite well. You can write things like "How much chlorophyll was in the ocean in the summer months of 2025 near Victoria, BC?" and it can map that to stations, then to sensors (some named chlorophyll, some named fluorometers, some named after the manufacturer's model name, etc). And yes, this can be done with a skill, but my experimentation with this was disappointing. The MCP server provides far more consistent results.
2. Less important, but the API doesn't presently differentiate between users. They have access or they don't. The writable endpoints should not be accessible to Claude, so handing it a token is not acceptable. The MCP server ensures Claude's use of the token is limited. This takes less work than rebuilding auth for the API. We could use a read-only proxy instead, but on its own, this wouldn't help my team much.
3. The API already does return consistent results. The problem lies more in the direction of knowing how to query it.
I suppose a followup point is that the code driving the MCP server is testable and provides some guarantees about the system's behaviour, which allowed me to progressively improve its end results and determinism. I don't know how to do that with skills. I'm also solving a problem for less technical users, so I can't set them loose with a skill and a terminal to begin with.
I ask Claude these sort of things all the time and it writes its own SQL queries or writes its own API client to query multiple sources. Is that not a better approach to remove the MCP middleman?