I was a designated expert for a few shifts on the MCP booth at Microsoft Build 2025. Some people call it booth duty, it’s not glamorous; you stand there waiting for people to come and ask questions.

However, because Satya and others were constantly giving demos and mentioning MCP every few seconds, this was one of the most visited booths. I got my fair share of people.

I didn’t think I needed to do yet another blog post about MCP, after all, there are already hundreds of resources out there, but in the spirit of recollection, here are the most common questions I got this week. I hope some people find it useful.

The MCP Booth at Microsoft Build 2025

What is MCP?

The most common question I received was either, “What is MCP?” or, “I think I understand MCP, but I want to confirm.”

I first answered as an analogy:

Then I used to get:

But WHAT is MCP? Is MCP like HTTP? Is it an app? A layer?

People seems to get confused by the word protocol, so I reiterated that it was not a network protocol.

How it works?

You implement an MCP server that exposes tools (APIs, functions, or resources) and follows the MCP protocol for message exchange. MCP defines a standard way for agents (like AI assistants or bots) to communicate and perform actions. Agents connect to your server, discover available tools, and send or receive messages using the defined endpoints. Sessions are maintained (often via Server-Sent Events for remote servers), and agents can poll or stream updates. An MCP client can, for example, ping at regular intervals to retrieve new tools.

It can work in two ways—local or remote—but the specification and the way to expose tools (APIs, functions, prompts, or resources) are the same: the MCP protocol for message exchange.

How much does MCP cost? How can I enable it in my Azure Portal?

MCP does not cost anything. It’s an open specification—anyone can implement it, either as a client or a server. There is nothing to enable in the Azure Portal (one customer even asked me to look for MCP there); instead, you host an MCP server yourself, such as in a Web App, HTTP service, or Azure Functions.

How can I bring my whole legacy data or 100 tables of databases to MCP?

You don’t.

Before jumping to answer this question (or similar ones), I drill down into the why. What is the purpose? In MCP, like any other tool (GraphQL, BigData, OpenAPI, etc.), it is just one more tool. What you really need to define—and this depends on your scenario—are questions like: Who is the consumer? How are you limiting data to certain parts? Are they only reading or writing? How fast do you need it? How are you partitioning? What level of granularity do you want to expose (entire tables, specific queries, or business operations)? How will you handle data privacy and compliance requirements? What monitoring or auditing will you need for agent access to your data?

You don’t need to expose your entire database. Instead, you create MCP tools that wrap the specific actions or queries you want agents to perform (e.g., “GetCustomerById" or “ListOrders"). MCP is about exposing capabilities, not raw data.

Bringing the data is fairly straightforward, but we should think on the why before jumping to the solution. I expect tools like Microsoft Fabric to provide MCP servers soon, so hopefully this part is solved.

How can I do (X) type of authentication?

MCP itself doesn’t mandate a specific authentication method. You can use standard HTTP authentication mechanisms (OAuth, API keys, JWT, user/password, Microsoft Entra, etc.) at your endpoints. If you’re using an existing Agent MCP client (like VSCode, Cursor, Copilot Connectors), you’re limited to the auth mechanisms it supports. For custom scenarios, you can handle authentication externally and pass tokens to your local MCP server.

I often used extreme examples to illustrate this. For instance, if you needed a unique authentication mechanism—say, verifying a user by having them dance and sing on video—you would handle that authentication externally in your own app. After validating the user, you would store the resulting tokens and pass them to your local MCP server.

I compared this to how az login (the Azure CLI utility) works: it opens a browser for authentication, stores credentials locally, and then uses them to connect to Azure. Similarly, your local MCP server can manage custom authentication, store tokens, and allow tools like VSCode to use those tokens for access. This is essentially how the Azure MCP server operates.

While this approach can be cumbersome—since it may require users to install software locally—solutions like Docker have helped streamline the process. In the future, I expect VSCode and other agentic clients to offer more integrated authentication options. You could even create a VSCode extension for your custom authentication method and pass the tokens into the configuration’s $input field.

How can I be the official MCP server for X?

There’s no central registry for “official" MCP servers, but you can list your server at the official server list for visibility. Discovery is organic and depends on each MCP client implementation. In the future, agent platforms (e.g Copilot Studio) may have their own directories or marketplaces.

What is the difference between OpenAPI (or REST API, or SOAP, etc.) and MCP? Why can’t I just use OpenAPI?

Sure you can. You can expose OpenAPI schemas to agents, and many people do this to enable agent actions. However, MCP is fundamentally different and simpler, representing a new paradigm.

OpenAPI describes REST APIs for both humans and machines, but it doesn’t define how agents should dynamically discover, interact with, or invoke tools. MCP, on the other hand, is purpose-built for agent-to-agent or agent-to-tool communication, with conventions for discovery, invocation, and session management. While OpenAPI is focused on CRUD operations and endpoint definitions (and most of the time single stateless requests), MCP is more intent-driven—its tools are designed to map directly to user intents rather than just exposing low-level endpoints.

In few words, OpenAPI is schema-first and stateless, while MCP is intent-first and session-aware.

For example, in a typical REST API for an e-commerce scenario, you might need to call several endpoints to complete a checkout (e.g., GET /products, GET /product/{id}, POST /cart, PUT /cart/checkout). In MCP, you could expose a single tool like addProductToCartAndCheckout, which encapsulates the entire user intent in one action. This makes MCP tools more aligned with how agents interpret and fulfill user requests.

In practice, I’ve added C# annotations to an existing HTTP REST API and was able to expose both REST and MCP interfaces from the same service, serving different types of clients. However, to get the most out of MCP, you should design your tools thoughtfully; just as you wouldn’t map business entities 1:1 to database tables or REST endpoints, you shouldn’t map every REST endpoint directly to an MCP tool. The goal is to expose meaningful capabilities that match user or agent intents.

Can I use MCP to communicate between Agent-to-Agent?

Absolutely. MCP is designed to support agent-to-agent communication. For example, you could have one agent dedicated to handling CRM-related intents (such as Salesforce requests). This agent might expose a single MCP tool (like “CRM handler”), which receives natural language requests from other agents. The CRM agent then uses MCP to communicate with the underlying Salesforce MCP server and fulfill the request. Because MCP is a protocol and specification, you can extend it to fit custom scenarios and workflows, enabling flexible agent-to-agent interactions.

How does an agent know which MCP tool to call?

I don’t have insights over how internally VSCode or other MCP clients handle that call. Of course, if you implement your own MCP client you would have complete control over it. What I know is that description is super important. It is a shame, that you cannot provide few-shots to VSCode yet, or other tools to make it more deterministic. I could think in 3 strategies of how to route calls:

  1. NLP, tokenizing, using utterances and trying to detect the user intent. Not different that how LUIS and bot framework use todo it.
  2. Vector embeddings, storing the MCP tools in a vector embeddings database, and finding the closest one to the user request.
  3. LLM matching, asking to an LLM to find the closest match (which is at the end an expensive modification of vector embeddings).

Customers and people seems to try to find to make it more deterministic.

Where do I start?

We shared this repo as the holy grail of MCP and recommend looking at the sample implementations. Try exposing a simple tool (like a “hello world" function) as an MCP server, then connect an agent to it. Don’t be misled by the name “beginners” in the title, “mcp-for-beginners” repo is comprehensive, covering everything from the basics to advanced concepts and early insights from real-world implementation.

Is it good to invest in MCP for my company?

If you want to make your services accessible to AI agents or participate in the growing ecosystem of agent-based automation, MCP is a good investment. It’s open, flexible, and designed for interoperability. Early adoption can be advantageous.

How do I distribute my MCP server to users/developers/customers? How can they find me?

You can publish your MCP server’s endpoint and documentation on your website, developer portal, or relevant directories. As the ecosystem grows, more discovery mechanisms will emerge (like registries or marketplaces). For now, clear documentation and outreach are key. Some share configuration files (like mcp.json for VSCode) directly with developers (I don’t recommend this).

Anthropic is actively collaborating on the development of an official MCP Registry, as outlined in the MCP roadmap. This registry aims to provide a centralized directory for MCP servers, making it easier for agents and developers to discover, register, and connect to available MCP endpoints. While this would allow to have private registries, or it will be only a public one, I don’t know.

Final thoughts

MCP isn’t complicated, but it does require intentional design. The key is to focus on exposing meaningful capabilities, not just raw data or low-level endpoints. Think in terms of what an agent should be able to do, not just what your API can do.

The ecosystem is evolving fast. What feels like a hack today might be a best practice tomorrow. We’re already seeing early patterns emerge, like wrapping business operations as tools, using MCP for agent-to-agent orchestration, and integrating with developer environments like VSCode.

Experimentation isn’t just encouraged—it’s essential. Try building a small MCP server, wire it up to an agent, and see what happens. You’ll learn more in a weekend of tinkering than in a week of reading docs. There is no better way to understand and click with MCP than by experimenting with it hands-on.

And if you’re still unsure where to start, just remember: “hello world" (or better, “water my plants!”) is a valid MCP tool.

If you have more questions or want to jam on ideas, reach out. I’d love to hear what you’re building.