MCP server

How an MCP server works

MCP is an open standard that connects AI applications to external systems: to data, tools and ready-made prompts. On one side is the application the agent works in, such as Claude Code. It connects to each server you add separately. On the other side is the MCP server, the program that offers those tools and that data.

An MCP server can run on the same computer as the application or on the network:

• Local. The application starts the server on the same computer and talks to it over the process’s standard input and output (stdio). Such a server usually serves one client.
• Remote. The server runs at a network address, and the application connects to it over HTTP (the Streamable HTTP transport). Such a server usually serves many clients. A client can identify itself with, for example, a token in the request header, and the standard recommends getting that token through an OAuth sign-in.

The application finds out which tools a server has by asking it for their list (tools/list). Each tool has a name, a description and the list of arguments it expects. The application gathers the tools of all the connected servers and offers them to the language model. When the model decides a task needs a tool, the application sends a call (tools/call) with the name and the arguments to the right server, and the result comes back into the conversation with the model. The tool list does not have to stay fixed: it can depend, for example, on the user’s permissions.

MCP server vs API

An API (application programming interface) is the general way one program uses another: a set of operations, each with its own address, arguments and reply format. A developer reads its documentation and writes code that calls it, separately for every service. An MCP server is an interface too, but one made for AI applications. It describes its tools in one common format, each with a name, a description and its arguments, and the application reads that list from the server itself. The language model then decides which tool to call and when, with no code written for that one service.

So the two do not compete. An MCP server often calls an existing API behind the scenes and turns its operations into tools an agent understands. An API serves programs and the developers who write them, an MCP server serves an AI agent that chooses its tools while it works.

In featureloom, an MCP tool that does what the app also does runs the same code on the server, with the same checks: create_plan saves a plan just as creating one in the app does. The MCP server adds what an agent needs: tool descriptions that tell it how to work with plans. The server refuses a call to any tool outside the rights of the person who connected the agent. You connect Claude Code, Codex or Cursor to featureloom without writing any code.

How to use an MCP server

You use an MCP server from an AI application, such as Claude Code, Codex or Cursor. In general it takes four steps:

1. Choose the server. Each one gives the agent the tools of one service or system, and it runs on your computer or at a network address.
2. Add it to the application. You add a local server with the command that starts it and a remote one with its address, usually with one command in the terminal or an entry in the application’s settings file.
3. Sign in if the server asks. A remote server usually needs a token or a sign-in through the browser (OAuth).
4. Describe the task in plain words. The agent sees the server’s tools and calls them itself when the task needs them.

Using an MCP server takes no programming. Code is needed to build a server, not to use a ready-made one.

featureloom’s MCP server is remote, so there is nothing to install. In the app, an AI assistant connected to featureloom is called a console. You open Integrations, press Connect console on the Your consoles card and choose your console. For Claude Code or Codex, you copy the connect command with its secret and paste it in your system terminal. On a computer with a browser you can also use a connect command with no secret and confirm the connection by signing in through the browser. The sign-in then returns to the console on your computer and nowhere else. The Cursor editor connects with the Add to Cursor button. Cursor CLI gets an entry with no secret for its file ~/.cursor/mcp.json, which you copy from the same window, and signs in through the browser with agent mcp login featureloom. From then on, you give the agent a plan with the command from the plan, and it calls featureloom’s tools itself.

The MCP server in featureloom

featureloom runs a remote MCP server at one address: https://mcp.featureloom.com/mcp (Streamable HTTP). It is used by consoles, the AI assistants connected to featureloom, such as Claude Code, Codex or Cursor on your computer. Each console sends its credential in the Authorization: Bearer header and acts with the rights of the person who connected it.

Every console gets the reading tools, such as list_plans, get_plan and next_plan. The rest depend on the person’s rights: Realizes plans, Writes plans, Edits prompts and Deletes permanently. A new person has Realizes plans from the start, and an administrator grants the other rights on the People screen. The server refuses a call to a tool outside those rights. The MCP tools page describes all the tools and their rights.

Your organization’s prompts work as commands in Claude Code, Codex and Cursor. The command from a plan, such as featureloom realizer INV-14, gives the agent in one call the prompt with your team’s process, the whole plan document and the documents of the delivered plans it directly depends on.