> I still haven't figured out MCP or how/why to use them or why to bother. You run servers. I guess. It's too complex for my smol brain to understand

I know this is self-deprecating humor, but you do NOT have a smol brain: MCP servers are not as needed anymore now that Claude Code supports "Skills". They are also very token hungry as their spec is not lazy-loaded like the skills.

It was / and still is very useful if you collaborate with other engineers or want to perform operations in a non-stochastic fashion.

MCP servers are a way to expose a set of APIs (openAPI spec) to an LLM to perform the listed operations in a deterministic fashion (including adding some auditing, logging, etc). LLMs are fine-tuned for tool calling, so they do it really well and consistently.

Examples:

- Documentation / Glossary: MCP server that runs somewhere that reads a specific MD file or database that is periodically updated: think "what are my team members working on" / "let me look up what this means in our internal wiki".

- Gating operations behind authentication: a MCP server that is connected to your back office and allows you to upgrade a customer's plan, list existing customers, surface current. Super useful if you're a solo-founder for example.

It's more like you want Claude to interact with X, and you go to see if there's an MCP server for it.

Claude could use the API directly but most MCP now comes with OAuth so you can let it act as you, in case API keys are hard to come by or chargeable. Sometimes with a good skill or a preconfigured CLI tool skills can be just as good if not far more powerful than an MCP server.

But the trigger you'd look for to decide to use an MCP is 'i wish Claude could access X'. My top examples:

- pulling designs from figma to implement them - fetching ticket context for a job from JIRA - getting a stack trace to investigate from Sentry

If you haven't grokked MCP yet don't bother now; it's on the way out. Instead do learn to write an AGENT.md file (create a CLAUDE.md file to point to it) then list all the tools you have at its disposal. It will probably know how to use them; it just needs to be told what's available.

I definitely relate with your sentiment and I like your term "configuration bankruptcy"

on MCP, the mental model that clicked for me is "giving claude access to tools it can call" so that instead of copy pasting from your database or API, claude can just... query it

playwright MCP for me is godsend

Nice way to put it. Skills feel great for shaping how Claude works inside a repo, while MCP really shines when you want it to talk to “live” systems : databases, test runs, CI, all that external state.

I thought skills were supposed to help with “giving claude access to tools it can call”. When would one use MCP over skills?

skills are basically markdown files that teach claude how to do something. they live in your repo and load on demand.

MCP is for when you need claude to actually interact with external systems like querying a database, hitting an API, etc...

I've not explicitly used skills or MCP, but have had zero issues with Claude calling apis via curl as an example. I'm not sure what the MCP server or skill is actually enabling at this point. If I wanted CC to talk to SQL Server, I'd have it open a nix-env with the tools needed to talk to the database. One of my primary initial claude.md entries has to do with us running on NixOS and that temporarily installing tools is trivial and it should do things in the NixOS way whenever possible. Since then it has just worked with practically everything I've thrown at it. Very rarely do I see it trying to use a tool that isn't installed anymore. CC even uses my local vaultwarden where I have a collection of credentials shared with it. All driven through claude.md.