It would appear the HN hug knocked your host offline, given the 525 TLS Is Bogus and its 502 Bad Gateway friend

I managed to get it to load: https://archive.ph/7DALF

[flagged]

fine. Examples, what can I use this for?

I read through several of the top level pages, then SQLite, but still had no idea what was meant by "context" as it's a highly ambiguous word and is never mentioned with any concrete definition, example, or scope of capability that it is meant to imply.

After reading the Python server tutorial, it looks like there is some tool calling going on, in the old terminology. That makes more sense. But none of the examples seem to indicate what the protocol is, whether it's a RAG sort of thing, do I need to prompt, etc.

It would be nice to provide a bit more concrete info about capabilities and what the purposes is before getting into call diagrams. What do the arrows represent? That's more important to know than the order that a host talks to a server talks to a remote resource.

I think this is something that I really want and want to build a server for, but it's unclear to me how much more time I will have to invest before getting the basic information about it!

Here are a couple points of confusion for me:

1. The sampling documentation is confusing. "Sampling" means something very specific in statistics, and I'm struggling to see any connection between the term's typical usage and the usage here. Perhaps "prompt delegation" would be a more obvious term to use.

Another thing that's confusing about the sampling concept is that it's initiated by a server instead of a client, a reversal of how client/server interactions normally work. Without concrete examples, it's not obvious why or how a server might trigger such an exchange.

2. Some information on how resources are used would be helpful. How do resources get pulled into the context for queries? How are clients supposed to determine which resources are relevant? If the intention is that clients are to use resource descriptions to determine which to integrate into prompts, then that purpose should be more explicit.

Perhaps a bigger problem is that I don't see how clients are to take a resource's content into account when analyzing its relevance. Is this framework intentionally moving away from the practice of comparing content and query embeddings? Or is this expected to be done by indices maintained on the client?

I just want to say kudos for the design of the protocol. Seems inspired by https://langserver.org/ in all the right ways. Reading through it is a delight, there's so many tasteful little decisions.

One bit of constructive feedback: the TypeScript API isn't using the TypeScript type system to its fullest. For example, for tool providers, you could infer the type of a tool request handler's params from the json schema of the corresponding tool's input schema.

I guess that would be assuming that the model is doing constrained sampling correctly, such that it would never generate JSON that does not match the schema, which you might not want to bake into the reference server impl. It'd mean changes to the API too, since you'd need to connect the tool declaration and the request handler for that tool in order to connect their types.

Looking at https://github.com/modelcontextprotocol/python-sdk?tab=readm... it's clear that there must be a decision connecting, for example, `tools` returned by the MCP server and `call_tool` executed by the host.

In case of Claude Desktop App, I assume the decision which MCP-server's tool to use based on the end-user's query is done by Claude LLM using something like ReAct loop. Are the prompts and LLM-generated tokens involved inside "Protocol Handshake"-phase available for review?

I'd love to develop some MCP servers, but I just learned that Claude Desktop doesn't support Linux. Are there any good general-purpose MCP clients that I can test against? Do I have to write my own?

(Closest I can find is zed/cody but those aren't really general purpose)

How much did you use LLMs or other AI-like tools to develop the MCP and its supporting materials?

It seems extremely verbose. Why does the transport mechanism matter? Would have loved a protocol/standard about how best to organize/populate the context. I think MCP touches on that but has too much of other stuff for me.

For Rust, could one leverage the type + docs system to create such a server? I didn't delve into the details but one of the issues of Claude is that it has no knowledge of the methods that are available to it (vs LSP). Will creating such a server make it able to do informed suggestions?

Superb work and super promising! I had wished for a protocol like this.

Is there a recommended resource for building MCP client? From what I've seen it just mentions Claude desktop & co are clients. SDK readme seems to cover it a bit but some examples could be great.

Why not use GraphQL instead of inventing a whole new protocol?

Do you have a roadmap for the future of the protocol?

Is it versioned? ie. does this release constitute an immutable protocol for the time being?

The result that MCP server returned will be transfer to MCP host(Claude, IDEs, Tools), there are some privacy issues because the process is automatic after one-time permission provided.

For instance, when there is something wrong for MCP host, it query all data from database and transfer it to host, all data will be leaked.

It's hard to totally prevent this kind of problem when interacting with local data, But, Is there some actions to prevent this kind of situations for MCP?

Are there any resources for building the LLM side of MCP so we can use the servers with our own integration? Is there a specific schema for exposing MCP information to tool or computer use?

Super cool and much needed open-standard. Wondering how this will work for websites/platforms that don't have exposed API's (LinkedIn, for example)

What is a practical use case for this protocol?

For additional context the PyPi package: https://pypi.org/project/mcp/

And the GitHub repo: https://github.com/modelcontextprotocol

First, thank you for working on this.

Second, a question. Computer Use and JSON mode are great for creating a quasi-API for legacy software which offers no integration possibilities. Can MCP better help with legacy software interactions, and if so, in what ways?

Is there any way to give a MCP server access for good? Trying out the demo it asked me every single time for permission which will be annoying for longer usage.

Is it at least somewhat in sync with plans from Microsoft , OpenAI and Meta? And is it compatible with the current tool use API and computer use API that you’ve released?

From what I’ve seen, OpenAI attempted to solve the problem by partnering with an existing company that API-fys everything. This feels looks a more viable approach, if compared to effectively starting from scratch.

Seems from the demo videos like Claude desktop app will soon support MCP. Can you share any info on when it will be rolled out?

Was Cursor in any way an inspiration?

As someone building a client which needs to sync with a local filesystem (repo) and database, I cannot emphasize how wonderful it is that there is a push to standardize. We're going to implement this for https://srcbook.com

I've been implementing a lot of this exact stuff over the past month, and couldn't agree more. And they even typed the python SDK -- with pydantic!! An exciting day to be an LLM dev, that's for sure. Will be immediately switching all my stuff to this (assuming it's easy to use without their starlette `server` component...)

One thing I am having a hard time wrapping my head around is how to reliably integrate business logic into a system like this. Just hook up my Rails models etc. and have it use those?

Let’s say I’ve got a “widgets” table and I want the system to tell me how many “deprecated widgets” there are, but there is no convenient “deprecated” flag on the table—it’s defined as a Rails scope on the model or something (business logic).

The DB schema might make it possible to run a simple query to count widgets or whatever, but I just don’t have a good mental model of how these systems might work with “business logic” type things.

This is exactly what I've been trying to figure out. At some point the LLM needs to produce text, even if it is structured outputs, and to do that it needs careful prompting. I'd love to see how that works.

Very nice video, thank you.

His high level summary is that this boils down to a "list tools" RPC call, and a "call tool" RPC call.

It is, indeed, very smart and very simple.

We're definitely interested in extending MCP to cover remote connections as well. Both SDKs already support an SSE transport with that in mind: https://modelcontextprotocol.io/docs/concepts/transports#ser...

However, it's not quite a complete story yet. Remote connections introduce a lot more questions and complexity—related to deployment, auth, security, etc. We'll be working through these in the coming weeks, and would love any and all input!

Local only solves a lot of problems. Our infrastructure does tend to assume that data and credentials are on a local computer - OAuth is horribly complex to set up and there's no real benefit to messing with that when local works fine.

I'm honestly happy with them starting local-first, because... imagine what it would look like if they did the opposite.

> It would be a lot more interesting if I could connect this to my github in the web app and claude automatically has access to my code repositories.

In which case the "API" would be governed by a contract between Anthropic and Github, to which you're a third party (read: sharecropper).

Interoperability on the web has already been mostly killed by the practice of companies integrating with other companies via back-channel deals. You are either a commercial partner, or you're out of the playground and no toys for you. Them starting locally means they're at least reversing this trend a bit by setting a different default: LLMs are fine to integrate with arbitrary code the user runs on their machine. No need to sign an extra contact with anyone!

> It would be a lot more interesting if I could connect this to my github in the web app and claude automatically has access to my code repositories.

From the link:

> To help developers start exploring, we’re sharing pre-built MCP servers for popular enterprise systems like Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer.

For me it's complementary to openai's custom GPTs which are non-local.

What's use case for this?

what’s crazy about it?

Yeah this was a huge foot gun

What risk do you foresee arising out of perverse incentives in this case?

This is a really, really, good point.

Devil's advocating for conversation's sake: at the end of the day, the user and client app want very little persistent data coming from the server - if nothing else than the client is expecting to store chats as text, with external links or Potemkin placeholders for assets like files.

Our thinking is that prompts will generally be a user initiated feature of some kind. These docs go into a bit more detail:

https://modelcontextprotocol.io/docs/concepts/prompts

https://spec.modelcontextprotocol.io/specification/server/pr...

… but TLDR, if you think of them a bit like slash commands, I think that's a pretty good intuition for what they are and how you might use them.

It's just function calling with a new name and a big push from the LLM provider, but this time it's in the right direction. Contrast with OpenAI's "GPTs", which are just function calling by another name, but pushed in the wrong direction - towards creating a "marketplace" controlled by OpenAI.

I'd say that thing you're feeling comes from witnessing an LLM vendor, for the first time in history, actually being serious about function calling and actually wanting people to use it.

LLMs can potentially query _something_ and receive a concise, high-signal response to facilitate communications with the endpoint, similar to API documentation for us but more programmatic.

This is huge, as long as there's a single standard and other LLM providers don't try to release their own protocol. Which, historically speaking, is definitely going to happen.

One of the biggest issues of LLM is that they have a lossy memory. Say there is a function from_json that accepts 4 arguments. An LLM might predict that it accepts 3 arguments and thus produce non-functional code. However, if you add the docs for the function, the LLM will write correct code.

With the LLM being able to tap up to date context (like LSP), you won't need that back-and-forth dance. This will massively improve code generations.

This is definitely a huge deal - as long as there's a good developer experience - which IMHO we're not there yet!

We're still in the process of thinking through and fleshing out full details for remote MCP connections. This is definitely a good idea to include in the mix!

This looks pretty awesome.

Would love to chat with you if you are open about possible collab.

I am frank [at] glama.ai

Possibly marginally, but the "server" components here are ideally tiny bits of glue that just reformat LLM-generated JSON requests into target-native API requests. Nothing interesting "should" be happening in the context protocol. Examining the source may provide you with information on how to get to the real API for the service, however.

Hm, this shouldn't be the case, something Odd is happening here. Normally restarting the app should do it, though on Windows it is easy to think you restarted the app when you really just closed the main window and reopened it (you need to close the app via File => Qui)

My guess is more can be done locally. Then again I only understand ~2 of this and aider.

I think OpenAI spec function calls are to this like what raw bytes are to unix file descriptors

It's not about the interface to make a request to a server, it's about how the client and server can interact.

For example:

When and how should notifications be sent and how should they be handled?

---

It's a lot more like LSP.

Same reason in Emacs we use lsp-mode and eglot these days instead of ad-hoc flymake and comint integrations. Plug and play.

it's a bit of a hack but the web UI of ChatGPT has a limited amount of memories you can use to customize your interactions with it.

I’ve gone looking for services like this but couldn’t find much, any chance you can link to a few platforms?

After a quick look it seemed to me like they're trying to standardize on how clients call servers, which nobody needs, and nobody is going to use. However if they have new Tools that can be plugged into my LangChain stuff, that will be great, and I can use that, but I have no place for any new client/server models.

There’s clearly a need for this type of abstraction, hooking up these models to various tooling is a significant burden for most companies.

Putting this out there puts OpenAI on the clock to release their own alternative or adopt this, because otherwise they run the risk of engineering leaders telling their C-suite that Anthropic is making headway towards better frontier model integration and OpenAI is the costlier integration to maintain.

True, but you could also frame this as a way for Anthropic to try and break that trend. IMO they've got to try and compete with OpenAI, can't just concede that OpenAI has won yet.

I wonder if they'll have any luck convincing other LLM vendors, such as Google, Meta, xAI, Mistral, etc, to adopt this protocol. If enough other vendors adopt it, it might still see some success even if OpenAI doesn't.

Also, I wonder if you could build some kind of open source mapping layer from their protocol to OpenAI's. That way OpenAI could support the protocol even if they don't want to.

"OpenAI API" is not a "standard" though. They have no interest in making it a standard, otherwise they would make it too easy to switch AI provider.

Anthropic is playing the "open standard" card because they want to win over some developers. (and that's good from that pov)

That’s only because they were first.

Here, Anthropic is first. If everyone starts using MCP today, any alternative OpenAI comes out with in a few months time probably won’t be able to dislodge it.

> 80% market share

where do you get that number?

Yeah, we’re using it a lot at Sourcegraph. There are some extra APIs it offers beyond what MCP offers, such as annotations (as you can see on the homepage of https://openctx.org). We worked with Anthropic on MCP because this kind of layer benefits everyone, and we’ve already shipped interoperability.

My team and I have a desktop product with a very similar architecture (a central app+UI with a constellation of local servers providing functions and data to models for local+remote context)

If this protocol gets adoption we'll probably add compatibility.

Which would bring MCP to local models like LLama 3 as well as other cloud providers competitors like OpenAI, etc

Cody (VS Code plugin) is supporting MCP https://sourcegraph.com/blog/cody-supports-anthropic-model-c...

I would probably more think of it as LSP for LLM applications. It is enabling data integrations, but the current implementations are all local.

Vector embeddings are entirely unrelated to this.

This is about tool usage - the thing where an LLM can be told "if you want to run a SQL query, say <sql>select * from repos</sql> - the code harness well then spot that tag, run the query for you and return the results to you in a chat message so you can use them to help answer a question or continue generating text".

it doesnt feed the whole DB into the context, it gives Claude the option to QUERY it directly

let Claude answer questions about your files and even modify them

data security is the reason i'd imagine they're letting other's host servers

Your point about boilerplate is key, and it’s why I think MCP could work well despite some of the concerns raised. Right now, so many of us are writing redundant integrations or reinventing the same abstractions for tool usage and context management. Even if the first iteration of MCP feels broad or clunky, standardizing this layer could massively reduce friction over time.

Regarding the standalone servers, I suspect they’re aiming for usability over elegance in the short term. It’s a classic trade-off: get the protocol in people’s hands to build momentum, then refine the developer experience later.

Presumably this doesn't apply to the standard being released here, nor any of its implementations made available. Each of these appears to have its own permissible license.

OpenAI and many other companies have virtually the same language in their T&Cs.

Eh the actual MCP repos seem to just be MIT licensed; AFAIK every AI provider has something similar for their core services as they do.

I think open-sourcing your tech for the common person while leaving commercial use behind a paywall or even just against terms is completely acceptable, no?

Here's the play:

If integrations are required to unlock value, then the platform with the most prebuilt integrations wins.

The bulk of mass adopters don't have the in-house expertise or interest in building their own. They want turnkey.

No company can build integrations, at scale, more quickly itself than an entire community.

If Anthropic creates an integration standard and gets adoption, then it either at best has a competitive advantage (first mover and ownership of the standard) or at worst prevents OpenAI et al. from doing the same to it.

(Also, the integration piece is the necessary but least interesting component of the entire system. Way better to commodify it via standard and remove it as a blocker to adoption)

The secret sauce part is the useful part -- the local vector store. Anthropic is probably not going to release that without competitive pressure. Meanwhile this helps Anthropic build an ecosystem.

When you think about it, function calling needs its own local state (embedded db) to scale efficiently on larger contexts.

I'd like to see all this become open source / standardized.

So they want an open protocol, and instead of say collaborating with other people that provide models like Google, Microsoft, Mistral, Cohere and the opensource community, they collaborate with an editor team. Quite the protocol. Why should Microsoft implement this? If they implement their own protocol, they win. Why should Google implement this? If they implement their own protocol, they win too. Both giants have way more apps and reach in inside businesses than Anthropic can wish.

Looks like I need to create a rust extension wrapper for the mcp server I created for Claude?

RPC for LLMs with the first client being Claude Desktop. ;-)

Twitter doesn't work anymore unless you are logged in.

https://unrollnow.com/status/1861079762506252723