upvote
I avoid most MCPs. They tend to take more context than getting the LLM to script and ingest ouputs. Trying to use JIRA MCP was a mess, way better to have the LLM hit the API, figure out our custom schemas, then write a couple scripts to do exactly what I need to do. Now those scripts are reusable, way less context used.

I don't know, to me it seems like the LLM cli tools are the current pinnacle. All the LLM companies are throwing a ton of shit at the wall to see what else they can get to stick.

reply
I have had some positive experiences using the Jira and Confluence MCPs. However, I use a third-party MCP because my company has a data centre deployment of Jira and Confluence, which the official Atlassian MCP does not support.

My use case was for using it as an advanced search tool rather than for creating tickets or documentation. Considering how poor the Confluence search function is, the results from Confluence via an MCP-powered search are remarkably good. I was able to solve one or two obscure, company-specific issues purely by using the MCP search, and I'm convinced that finding these pages would have been almost impossible without it.

reply
Fully agree.

MCP servers were also created at a time where ai and llms were less developed and capable in many ways.

It always seemed weird we'd want to post train on MCP servers when I'm sure we have a lot of data with using cli and shell commands to improve tool calling.

reply
It’s telling the best MCP implementations are those which are a CLI to handle the auth flow then allow the agent to invoke it and return results to stdout.

But even those are not better for agent use than the human cli counterpart.

reply
I hate MCP servers

That said the core argument for MCP servers is providing an LLM a guard-railed API around some enterprise service. A gmail integration is a great example. Without MCP, you need a VM as scratch space, some way to refresh OAuth, and some way to prevent your LLM from doing insane things like deleting half of your emails. An MCP server built by trusted providers solves all of these problems.

But that's not what happened.

Developers and Anthropic got coked up about the whole thing and extended the concept to nuts and bolts. I always found the example servers useless and hilarious.[0] Unbelievably, they're still maintained.

[0]: https://github.com/modelcontextprotocol/servers/tree/main/sr...

reply
How do you segregate the CLI interface the LLM sees versus a human? For example if you’d like the LLM to only have access to read but not write data. One obvious fix is to put this at the authz layer. But it can be ergonomic to use MCP in this case.
reply
I’ve been testing with an ENV variable for a cli tool for LLMs that I’m making. Basically, I have a script that sets an ENV variable to launch the TUI that I want and that ENV variable changes the behavior for LLMs if they run it (changes the -h output, changes the default output format to json to make it easier to grep)
reply
Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.
reply
MCP provides a real-world benefit. Namely anyone of any skill level who can create agents is able to use them. CLI? Nope.
reply
Tools eat up so much context space, too. By contrast the shell tool is trained into Claude.
reply
This was my gut from the beginning. If they can't do "fully observable" or "deterministic" (for what is probably a loose definition of that word) -- then, what's the point?
reply