Article summary
Atomic Object Raleigh has several ongoing projects, all of which involve varying degrees of AI-assisted coding, as well as some creating agentic applications. Recently I asked other engineers in our office to share their thoughts on Model Context Protocol (MCP) Servers. MCP is a standard that lets AI tools connect to third-party systems (such as Linear, Figma, or Jira) without custom-building each integration.
Question: What are your thoughts on MCP servers?
Jordan Booker:
I liked that they tried to kind of create a standard for how to integrate all these third-party APIs with AI tooling. Unfortunately, I’ve had varying success with MCP servers. It seems like a lot of companies really wanted to jump on the bandwagon of AI adoption with it, but it doesn’t seem to be a priority anymore… I’ve found too, though, that like if there’s a CLI [tool], that works so much better than an MCP server because CLIs, the way they handle authentication…the way they handle documentation all work better for me, like…understanding what the agent is looking to do because I can look at the commands it’s running.
It’s already usually authenticated and I don’t have to manage that within Claude Code’s interface, whereas MCP servers, you’re having to go in and /MCP. That’s annoying. And so I would have just much rather had a CLI to do that. [However,] I’ve had really great success with the Linear MCP server for project management… So we, on my most recent project, erred towards using skills in combination with CLIs over MCP servers. The sole exception was the Linear MCP server.
Kyle Humphrey:
It felt like a solution that was created by AI and they aren’t really needed. We have CLIs, we have APIs. We have plenty of ways to interface with computers and data. We don’t need computers speaking English to each other. We need AI to help us speak to computers using English, and the computer should speak to each other using computer language…The cool thing is that I can use AI to write the SQL, but the SQL should speak to the computer programs. I don’t know. It’s like non-determinism keeps leaking into things, and I don’t think it’s necessary. Like, let’s [get] as fast as possible to deterministic results utilizing AI where it helps.
Andrew Marmorstein:
I haven’t had a chance to work with MCPs heavily, but from what I’ve gathered so far, I understand that it is trying to solve the problem of AI tools integrating with 3rd party systems. But we’ve been, you know, integrating third party systems for a while now with APIs largely just fine, with the exception of the fact that every large third-party tool seems to need to invent its own query language to interact with it. MCPs appear to be yet another attempt at solving a problem that we’ve already tried to solve a couple of different ways. And I don’t know if it’s necessarily better or not, but it’s popular.
Abby Peterson:
I like MCPs. and I’ve obviously caught through [various] different developer discussions that apparently MCPs are dead. Maybe I’m out of touch but it works plenty well for me, specifically the Figma MCP. As long as you have a skill set up so it knows what… actual tool commands to call. And I really like having it connected to Linear… or Jira to get content. Yeah, so I like those MCPs, but… you still need… rules and skills set up. I have a lot of independent structure. I don’t really let my sub-agents run [on their own]. They have to ask me, and I approve tool calls, so I guess maybe that’s where some MCP frustrations come from.
Four engineers, four different takes. There isn’t total consensus on the practicality of MCP servers; some agreed that they are an attempt to solve a problem that has already been addressed in other ways. Others felt they improved their workflow. As AI evolves, we’ll see whether MCPs hold up as the standard, or whether CLIs and skills take their place.