There is not a lot to learn to understand the basics, but maybe one step that's not necessarily documented is the overall workflow and why it's arranged this way. You mentioned the LLM "using web search" and it's a related idea: LLMs don't run web searches themselves when you're using an MCP client, they ask the client to do it.
You can think of an MCP server as a process exposing some tools. It runs on your machine communicating via stdin/stdout, or on a server over HTTP. It exposes a list of tools, each tool has a name and named+typed parameters, just like a list of functions in a program. When you "add" an MCP server to Claude Code or any other client, you simply tell this client app on your machine about this list of tools and it will include this list in its requests to the LLM alongside your prompt.
When the LLM receives your prompt and decides that one of the tools listed alongside would be helpful to answer you, it doesn't return a regular response to your client but a "tool call" message saying: "call <this tool> with <these parameters>". Your client does this, and sends back the tool call result to the LLM, which will take this into account to respond to your prompt.
That's pretty much all there is to it: LLMs can't connect to your email or your GitHub account or anything else; your local apps can. MCP is just a way for LLMs to ask clients to call tools and provide the response.
1. You: {message: "hey Claude, how many PRs are open on my GitHub repo foo/bar?", tools: [... github__pr_list(org:string, repo:string) -> [PullRequest], ...] }
2. Anthropic API: {tool_use: {id: 123, name: github__pr_list, input:{org: foo, repo: bar}}}
3. You: {tool_result: {id: 123, content: [list of PRs in JSON]} }
4. Anthropic API: {message: "I see 3 PRs in your repo foo/bar"}
that's it.
If you want to go deeper the MCP website[1] is relatively accessible, although you definitely don't need to know all the details of the protocol to use MCP. If all you need is to use MCP servers and not blow up your context with a massive list of tools that are included with each prompt, I don't think you need to know much more than what I described above.
Maybe it's because of the example, but if the LLM knows the GitHub CLI and I bet it knows it, shouldn't it be able to run the commands (or type them for us) to count the open PRs on foo/bar?
However I see the potential problem of the LLM not knowing an obscure proprietary API. The traditional solution has been writing documentation, maybe on a popular platform like Postman. In that case the URL of the documentation could be enough, or an export in JSON. It usually contains examples too. I dread having to write and maintain both the documentation for humans and the MCP server for bots.
It can and it does especially combined with skills (context files). It can hit REST APIs with CURL just fine. MCP is basically just another standard.
Where it comes in handy has mostly been in distribution honestly. There's something very "open apis web era" about MCP servers where because every company rushed to publish them, you can write a lot of creative integrations a bit more easily.
I had tried `delta` a few years ago but eventually went with `diff-so-fancy`[1]
The two are kind of similar if I remember correctly, and both offer a lot of config options to change the style and more. I mostly use it for diffs involving long lines since it highlights changes within a line, which makes it easier to spot such edits.
I have an alias set in `~/.gitconfig` to pipe the output of `git diff` (with options) to `diff-so-fancy` with `git diffs`:
Yes, the blue and orange dots are from the water and parks Nodes and Ways in the OSM data.
It doesn't look like the orange and blue colors are part of the theme definitions, so the rendering library may be using some default values. This is why they are rendered in the same color on images using different theme files.
The March 2025 blog post by Anthropic titled "Tracing the thoughts of a large language model"[1] is a great introduction to this research, showing how their language model activates features representing concepts that will eventually get connected at some later point as the output tokens are produced.
The associated paper[2] goes into a lot more detail, and includes interactive features that help illustrate how the model "thinks" ahead of time.
Is this only about remote MCP servers? The instructions all seem to contain a URL, but personally almost all the MCP servers I'm running locally are stdio based and not networked. Are you planning to support those in some way?
There's also this new effort by Anthropic to provide a packaging system for MCP servers, called MCPB or MCP Bundles[1]. A bundle is a zip file with a manifest inside it, a bit like how Chrome extensions are structured (maybe VSCode extensions too?).
Is this something you're looking to integrate with? I can't say I have seen any MCPB files anywhere just yet, but with a focus on simple installs and given that Anthropic introduced MCP in the first place, I wouldn't be surprised if this new format also got some traction. These archives could contain a lot more data than the small amount you're currently encoding in the URL though[2].
That's a good point, we really think that the future of MCP servers are remote servers, as running "random" software that has little to no boundaries, no verification or similar shouldn't be a thing. Is there a specific reason, you prefer stio servers over http servers? Which servers are you using?
> Is there a specific reason, you prefer stio servers over http servers?
Yes: the main reason is that I control which applications are configured with the command/args/environment to run the MCP server, instead of exposing a service on my localhost that any process on my computer can connect to (or worse, on my network if it listens on all interfaces).
I mostly run MCP servers that I've written, but otherwise most of the third party ones I use are related to software development and AI providers (e.g. context7, Replicate, ElevenLabs…). The last two costs me money when their tools are invoked, so I'm not about to expose them on a port given that auth doesn't happen at the protocol level.
Most software we install locally is at least distributed via a trusted party (App Store, Play Store, Linux package repos, etc) and have a valid signatur (Desktop & Mobile) or are contained in some way (containers, browser extensions, etc..).
In the case of MCP, remote servers at least protect you from local file leakages.
They're not just from AI-generated text. Some of us humans use en dashes and em dashes in the right context, since they're easy to type on macOS: alt+hyphen and alt+shift+hyphen respectively.
On both iOS and modern Android I believe you can access them with a long press on hyphen.
Does Dia support configuring voices now? I looked at it when it was first released, and you could only specify [S1] [S2] for the speakers, but not how they would sound.
There was also a very prominent issue where the voices would be sped up if the text was over a few sentences long; the longer the text, the faster it was spoken. One suggestion was to split the conversation into chunks with only one or two "turns" per speaker, but then you'd hear two voices then two more, then two more… with no way to configure any of it.
Dia looked cool on the surface when it was released, but it was only a demo for now and not at all usable for any real use case, even for a personal app. I'm sure they'll get to these issues eventually, but most comments I've seen so far recommending it are from people who have not actually used it or they would know of these major limitations.
The following CSS equivalent worked for me, using the "Custom CSS by Denis" Chrome extension[1]:
ytd-rich-grid-renderer div#contents {
/* number of video thumbnails per row */
--ytd-rich-grid-items-per-row: 5 !important;
/* number of Shorts per row in its dedicated section */
--ytd-rich-grid-slim-items-per-row: 6 !important;
}
I first tried it with the "User JavaScript and CSS" extension, but somehow it didn't seem able to inject CSS on YouTube. Even a simple `html { border: 5px solid red; }` would not show anything, while I could see it being applied immediately with the "Denis" CSS extension.
If someone can recommend a better alternative for custom CSS, I'd be interested to hear it. I guess Tampermonkey could work, if you have that.
The main alternative to LVGL seems to be TouchGFX[1], at least that's the one I've seen mentioned the most in conversations around UI libraries for microcontrollers.
As you wrote these aren't made for desktop apps, but you can use desktop apps to help with UI development using these libraries.
For LVGL there's SquareLine Studio[2], I used it a few years ago and it was helpful. For TouchGFX there's TouchGFXDesigner[3], I haven't used it myself and it seems to run only on Windows.
You can think of an MCP server as a process exposing some tools. It runs on your machine communicating via stdin/stdout, or on a server over HTTP. It exposes a list of tools, each tool has a name and named+typed parameters, just like a list of functions in a program. When you "add" an MCP server to Claude Code or any other client, you simply tell this client app on your machine about this list of tools and it will include this list in its requests to the LLM alongside your prompt.
When the LLM receives your prompt and decides that one of the tools listed alongside would be helpful to answer you, it doesn't return a regular response to your client but a "tool call" message saying: "call <this tool> with <these parameters>". Your client does this, and sends back the tool call result to the LLM, which will take this into account to respond to your prompt.
That's pretty much all there is to it: LLMs can't connect to your email or your GitHub account or anything else; your local apps can. MCP is just a way for LLMs to ask clients to call tools and provide the response.
1. You: {message: "hey Claude, how many PRs are open on my GitHub repo foo/bar?", tools: [... github__pr_list(org:string, repo:string) -> [PullRequest], ...] } 2. Anthropic API: {tool_use: {id: 123, name: github__pr_list, input:{org: foo, repo: bar}}} 3. You: {tool_result: {id: 123, content: [list of PRs in JSON]} } 4. Anthropic API: {message: "I see 3 PRs in your repo foo/bar"}
that's it.
If you want to go deeper the MCP website[1] is relatively accessible, although you definitely don't need to know all the details of the protocol to use MCP. If all you need is to use MCP servers and not blow up your context with a massive list of tools that are included with each prompt, I don't think you need to know much more than what I described above.
[1] https://modelcontextprotocol.io/docs/learn/architecture
reply