Thoughts On MCP Servers
Feb 10, 2026
I have been unable to avoid the whole put AI into stuff at work. No surprise there, really. Not entirely unwelcome, either. Fact is, our clients are using LLM-based AI assistants such as Microsoft Copilot to interact with the world, and one of the tenants of marketing is to meet clients where they work.
So how can we provide access to our resources to AI assistants? This field changes at a pace that makes one's head spin and makes settling on a stable solution difficult, but MCP servers are probably a reasonably safe bet. MCP here stands for Model Context Protocol, the idea being that MCP servers can be used to augment the context of an AI assistant to help answer user queries. Accordingly, I've been digging into MCP servers in the past month. I'm putting down my current thoughts about them here as a forcing function to try to impose some structure on the chaos.
To a first approximation, an MCP server is just an app (when run locally) or a web application server (when exposed online) that does the equivalent of exposing a bunch of API endpoints. These endpoints are called tools. Some LLMs are trained to be able to invoke such tools made available through MCP servers, in order to help answer user queries. Cool. That's the tag line at least. But that brings up a bunch of questions.
Question 1: what do I mean by exposing a bunch of API endpoints? Well, they're not endpoints in the strict sense of REST API endpoints exposed as routes accessible through HTTP requests. Instead, those endpoints are exposed through a single HTTP endpoint (in the case of an MCP server available online) that uses JSON-RPC to send and response to requests. A client can send JSON-RPC requests to the endpoint, and get a JSON-RPC response. So it's a single HTTP endpoint that can be used to send specially formatted queries and get specially formatted responses. A bit like GraphQL if you've ever used that. Note that just like you do not generally write a web application server by hand but instead rely on a framework such as Express, you do not generally generally write an MCP server by hand but instead rely on an SDK, such as this one for Typescript. Same idea: instead of defining routes exposed through a REST API, you define tools exposed through JSON-RPC. Aside from the fact that they are using JSON-RPC, there is nothing particularly special about MCP servers. They are another form of online API.
Question 2: how does an LLM-based AI assistant know which endpoints are available through an MCP server? That's actually one of the pieces that I find cool. These endpoints are discoverable. There is a standard request you can send to the endpoint to get a list of all available tools, along with details of the parameters that each tool accepts and the format of the tool's response. An LLM-based AI assistant trained on tool calling can use this information to determine if one of the tools available through the MCP server can help in answering the current user query, construct the request, and actually call the tool to get a response back. This is the old dream of a self-documenting discoverable API resurrected in this LLM era.
Question 3: how do I control what tools the LLM-based AI assistant calls? You can't. At least, not easily. The LLM will use the description you associate with each tool and which gets returned as part of the which tools do you have available? query, and you get to control that description and make it as precise as possible, but in the end, the LLM will decide if the tool is appropriate to the query, using its own internal logic. That's the part I've found the trickiest to get right when building MCP servers for our use case: determining what form the tools need to take to help the LLM make the right decision. As an added difficulty bonus, the usability of the tools you expose will depend drastically on the model underpinning the AI assistant calling the MCP server. If it uses one of the large state-of-the-art models, it should be able to handle pretty much anything. For smaller models though, the kind of model you would self-host, then the structure of the tools and the quality of the descriptions will have more of an impact.
Question 4: how are models trained to call tools, anyway? I found this nice write-up useful to help me understand what's going on there.
Question 5: couldn't we generate an MCP server automatically around an existing REST API? Yeah, that sounds like it should be doable, right? I suspect it's not too hard to wrap any REST API equipped with an OpenAPI specification as an MCP server. Imagine writing an OpenAPI MCP server that can load the /openapi.json file of a REST API and automatically expose tools for the endpoints described there. I think the only thing missing there are the LLM-readable descriptions. By the time you read this, I wouldn't be surprised somebody will have created that MCP server.
I don't have an MCP server to show you because, you know, proprietary blabbity blah. But you can check out an example such as this MCP server for time written in Python, that exposes two tools:
get_current_time to return the current timeconvert_time to convert a given time to a different timezone
Of course, most state-of-the-art AI assistants will already know how to do this natively, without requiring access to an MCP server. But for smaller models, that ability is not a given.
This post was written entirely by a human.
The Dwarf (by Pär Lagerkvist)
I have been unable to avoid the whole put AI into stuff at work. No surprise there, really. Not entirely unwelcome, either. Fact is, our clients are using LLM-based AI assistants such as Microsoft Copilot to interact with the world, and one of the tenants of marketing is to meet clients where they work.
So how can we provide access to our resources to AI assistants? This field changes at a pace that makes one's head spin and makes settling on a stable solution difficult, but MCP servers are probably a reasonably safe bet. MCP here stands for Model Context Protocol, the idea being that MCP servers can be used to augment the context of an AI assistant to help answer user queries. Accordingly, I've been digging into MCP servers in the past month. I'm putting down my current thoughts about them here as a forcing function to try to impose some structure on the chaos.
To a first approximation, an MCP server is just an app (when run locally) or a web application server (when exposed online) that does the equivalent of exposing a bunch of API endpoints. These endpoints are called tools. Some LLMs are trained to be able to invoke such tools made available through MCP servers, in order to help answer user queries. Cool. That's the tag line at least. But that brings up a bunch of questions.
Question 1: what do I mean by exposing a bunch of API endpoints? Well, they're not endpoints in the strict sense of REST API endpoints exposed as routes accessible through HTTP requests. Instead, those endpoints are exposed through a single HTTP endpoint (in the case of an MCP server available online) that uses JSON-RPC to send and response to requests. A client can send JSON-RPC requests to the endpoint, and get a JSON-RPC response. So it's a single HTTP endpoint that can be used to send specially formatted queries and get specially formatted responses. A bit like GraphQL if you've ever used that. Note that just like you do not generally write a web application server by hand but instead rely on a framework such as Express, you do not generally generally write an MCP server by hand but instead rely on an SDK, such as this one for Typescript. Same idea: instead of defining routes exposed through a REST API, you define tools exposed through JSON-RPC. Aside from the fact that they are using JSON-RPC, there is nothing particularly special about MCP servers. They are another form of online API.
Question 2: how does an LLM-based AI assistant know which endpoints are available through an MCP server? That's actually one of the pieces that I find cool. These endpoints are discoverable. There is a standard request you can send to the endpoint to get a list of all available tools, along with details of the parameters that each tool accepts and the format of the tool's response. An LLM-based AI assistant trained on tool calling can use this information to determine if one of the tools available through the MCP server can help in answering the current user query, construct the request, and actually call the tool to get a response back. This is the old dream of a self-documenting discoverable API resurrected in this LLM era.
Question 3: how do I control what tools the LLM-based AI assistant calls? You can't. At least, not easily. The LLM will use the description you associate with each tool and which gets returned as part of the which tools do you have available? query, and you get to control that description and make it as precise as possible, but in the end, the LLM will decide if the tool is appropriate to the query, using its own internal logic. That's the part I've found the trickiest to get right when building MCP servers for our use case: determining what form the tools need to take to help the LLM make the right decision. As an added difficulty bonus, the usability of the tools you expose will depend drastically on the model underpinning the AI assistant calling the MCP server. If it uses one of the large state-of-the-art models, it should be able to handle pretty much anything. For smaller models though, the kind of model you would self-host, then the structure of the tools and the quality of the descriptions will have more of an impact.
Question 4: how are models trained to call tools, anyway? I found this nice write-up useful to help me understand what's going on there.
Question 5: couldn't we generate an MCP server automatically around an existing REST API? Yeah, that sounds like it should be doable, right? I suspect it's not too hard to wrap any REST API equipped with an OpenAPI specification as an MCP server. Imagine writing an OpenAPI MCP server that can load the /openapi.json file of a REST API and automatically expose tools for the endpoints described there. I think the only thing missing there are the LLM-readable descriptions. By the time you read this, I wouldn't be surprised somebody will have created that MCP server.
I don't have an MCP server to show you because, you know, proprietary blabbity blah. But you can check out an example such as this MCP server for time written in Python, that exposes two tools:
get_current_timeto return the current timeconvert_timeto convert a given time to a different timezone
Of course, most state-of-the-art AI assistants will already know how to do this natively, without requiring access to an MCP server. But for smaller models, that ability is not a given.