I’m pretty new to this so curious for the answers as well. But as far as I understand a MCP server enables you to connect different applications to your vibe-coding journey. For example: keep track of your worklog, write documentation on your wiki, generate social media posts about your coding progress etc.

It basically gives you the capabilities to easily extend the LLMs capabilities by providing it different kinds of tools, whether it be reading resources or performing certain update tasks.

Almost like an API for LLM driven actions.

Instead of looking at the code behind your web site, you can just have it browse the web and login to your site for itself. Instead of telling it about your database, just have it login and look at the structure itself.

It’s just a new way to vibe integrate with a bunch of server data or api without hand crafting individual integrations. 90% of the hype is due to developer fomo

internal website scraping.

everything that didnt have an api i could integrate with, but does have a janky website is now something i can put into a locally-run workflow.

its not a panacea since i cant deploy it anywhere beyond my colleagues dev machines, but it enables a tone of automation that was otherwise a.big commitment, both from my team, and each of those janky website owners.

it was possible to do this website scraping before, but nobody was thinking about it in a plug and play manner

It's a pseudo-plugin system for chatbots, specifically the popular ones (Claude, chatgpt).

It is presented as a scalable way to provide tools to LLMs but that's only if you assume every use of LLMs is via the popular chatbot interfaces, which isn't the case.

Basically it's Anthropic's idea for extending their chatbot's toolset into desktop apps such as Google drive and others who may wish to make their software capabilities integrated into chatbots as tools.

Of course as with everything in tech, especially AI related, it has been cargo-culted to be the second coming of the messiah while all nuances about its suitability/applicability is ignored.

Text-to-text LLMs can only do one thing: output text.

These other capabilities that chat tools provide are actually extras built on top of the output sequence:

- reading and editing files

- searching the web

- executing commands

If your favorite chat tool (ChatGPT, Gemini, Claude, Cursor, whatever) already has all the tools you want, then you don't need to add more via an MCP server.

If you're trying to get back into full-stack javascript or python engineering, you get to practice writing your own authentication layers and self-managing any dependencies you use for edge cases that don't make sense when you're normally working on backend.

It's great! crazy eyes all seriousness though, it's a terrible solution for the "vibe" space in terms of how careless people are about it. There are thousands of "who-knows-who-made-this" servers for major integrations out there.

I use Tidewave which is a package for my Elixir app, and it allows the LLM to get access to some internals of my app. For example, Tidewave exposes tools to inspect the database schema, internal hex documentation for packages, introspection to see what functions are available on a module, etc.

While I’m not “vibe” coding, it is nice to be able to ask human language questions and have the LLM query the database to answer questions. Or while working on a feature, I can ask it to delete all the test records I created, etc. I can do that in a repl myself, but it’s sometimes a nice shortcut.

Note, this only runs in dev, so it’s not querying my production database or anything.

Basically, they can be a way to expose additional data or tools to the LLM.

having it in your cv would net you a good raise?

MCP lets your agent actually do things, rather than just write things. Think controlling some other software via APIs.

MCP is the programmatic link between traditional programming (deterministic) and a new style of programming using LLMs (non-deterministic)

Ignoring for a moment all of the other functions that MCP can allow an agent to do (open a webpage, query a database, run another agent, execute local commands etc) and only focussing on the use of MCP to provide context, the big advantage of MCP over RAG is that a RAG system needs to be built and maintained: you need to extract your content, vectorise it, store it in a database, query it, update it etc etc. With MCP, you just point it at your database and the agent gets up-to-date info.

If you use LLM CLI tools like Claude Code you can let model just call shell commands directly instead of MCP. Or does MCP have some advantage even in the scenario?

Not much.

I'm using Claude Code - with some MCP installed - so you would assume that whole MCP thing would work with an agentic product from the makers of this standard. In 9 out of 10 cases where a MCP would make sense to use - it doesn't know when to call the MCP. And yes, i've done all the claude.md crap. There is no transparency in this protocol about how AI would know when to call an MCP (besides direct prompting). To cut short - it's not reliable.

An mcp lets an agent call functions. These can in turn even issue queries to an LLM. E.g. an agent can issue natural language queries to a database by calling a function query("what is the answer to life, the universe and everything?") and the function will return "42" to the agent.

Lots of good comments here. I'll just share two Cursor/Windsurf/whatever prompts:

> Let's create new feature XYZ. Use Postgres MCP to verify the schema of relevant tables instead of making assumptions.

> Use Supabase MCP to see if user@domain.com has the correct permissions to have the Create Project button present in the UI.

NOTE: only run Supabase MCP with the --read-only, doing otherwise will lead to a bad time.

I think 90% of the hype could be understood if you look at things from a non-coder's perspective. All of this tooling helps non-engineers with building AI applications, because they don't know how to code.

They don't know how to write a simple function to call a REST API, store the results in an database, etc. etc. So they need this tooling.

There's also the fact that humans love to abstract things, even when the thing they're trying to abstract already does the job fairly well (see: Kubernetes, GraphQL)

It's a standard way to provide LLMs tools. Build a single MCP server. Your server's tools can be used by any LLM that supports tool calling.