Imagine building one API server that works everywhere, LSP did it for coders, is MCP next?

Before 2016, supporting programming languages in IDEs was messy.

Each editor had to build its own set of tools for every language it wanted to support.

Syntax highlighting, autocompletion, linting, they were all custom-built.

This led to a fragmented experience.

A language like JavaScript might feel smooth in one editor, but incomplete in another.

And if you used a terminal-based editor like VIM,
You were often left with limited tooling, or none at all.

That changed when @Microsoft introduced the Language Server Protocol (LSP).

Instead of editors and languages building integrations from scratch,
LSP created a standard way for them to communicate.

Languages could now provide a single LSP server,
And any editor with an LSP client could connect.

So instead of having to build a “Go plugin for VSCode” and a “Go plugin for Sublime,”

You’d just build a Go LSP server, and it works everywhere.For developers, this meant more consistent features across editors.

For language maintainers, it simplified the work of supporting new tools.

And for editors, it unlocked a long list of languages overnight.

Today, LSP is what makes tools like syntax highlighting and autocompletion feel seamless,

No matter which language you’re using, or which editor you prefer.

Here’s a simple visual to show the difference between pre-LSP and post-LSP setups:

Today, LSP has quietly transformed how development tools work.

Even niche programming languages can now deliver great developer experiences in popular editors.

They don’t need to strike direct deals with IDEs like VSCode or Cursor,
They just build an LSP server, and they’re in.

On the developer side, this shift matters too.

We no longer pick an IDE based on language support.

We choose based on the editor’s strengths,
Like Cursor’s interface or its AI capabilities.

That said, LSP adoption isn’t universal.

Some ecosystems, like JetBrains or Apple’s Xcode, still prefer their own protocols.

But for most, LSP is becoming the standard way editors and language tools connect.

Now, in 2025, MCP is entering the conversation.
And to us, it feels very familiar.

It wouldn’t be surprising if LSP’s structure helped inspire it.

Here’s the comparison:
Replace “programming languages” with third-party APIs like Stripe or Supabase,
And replace “IDEs” with AI chat clients, @Cursor , Claude, @OpenAI , @vercel , or @LangChainAI .
That’s what MCP looks like.

If MCP takes off, the impact could be huge.
Supabase wouldn’t need separate integrations for every AI client.

It would just build a @supabase MCP server,
And any MCP-compatible client could connect.
This could be a game-changer for small teams too.
They could offer full-featured tools to users on any AI platform,
Without maintaining five different integrations.

It might even make integration marketplaces obsolete.
If the experience is native across platforms,
Why would anyone need to browse and install plugins manually?

End users would benefit the most.

They’d get a consistent experience, no matter which AI tool they use.

We think MCP has real potential.

And with @AnthropicAI leading the way together with @State_Of_Mika.
It could become the new standard for linking third-party APIs with LLMs.

If you're curious how LSP solved a similar challenge,
Comment gMika and we’ll send you the guide.