glossary//mcp-server
MCP server
An MCP server is any endpoint that speaks MCP's JSON-RPC contract over Streamable HTTP to expose tools a language model can discover and invoke.
Server is the misleading half of the name. It suggests a second process, a port, a container, one more thing to deploy and monitor. MCP requires none of that. What makes something an MCP server is the contract it speaks: JSON-RPC over Streamable HTTP, a list of tools a model can discover, and a way to call one by name and receive a result.
That is the difference from a plain API server or microservice. Those are defined by where they run and who calls them. An MCP server is defined by what it answers to, and the deployment shape stays open.
The server is a route
One process, one file puts it under exactly that heading: the MCP server is just a route. M.O.T. exposes 26 MCP tools behind one handler at /api/mcp that speaks JSON-RPC over Streamable HTTP and dispatches each tool name into the same TypeScript library the ticket UI already calls. mot_create_ticket runs the exact code path the web form runs. memory_context reads the same tables the dashboard reads.
The essay argues against a default it lists out loud: a vector database for search, an MCP server to expose the tools, five services, five things to deploy, five things to monitor, five things to keep in sync. Collapsing that to one route removes a deployment and a network hop for anything that reads a ticket or writes a memory, and the tools behave the same either way.
The tools are the interface
Vectors in the file shows what the contract buys you later. Adding vector search with sqlite-vec gave a new mode parameter to three MCP tools, chat_search, entity_search and memory_recent. The parameter defaults to "fts", so every existing caller behaves exactly as before, and no new service appeared to hold the vectors. The tool names and their old behaviour stayed put while the implementation changed.
The practical test is not how the endpoint is hosted. It is whether a model can list the tools, call one by name, and receive the result in its context. If that holds, you have an MCP server, even when it is only a route handler inside an app you were already running.