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...)

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.

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)

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?

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?

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?

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.

What is a practical use case for this protocol?

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?

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!

> 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.

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.

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

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.

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

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

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

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.

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

https://unrollnow.com/status/1861079762506252723