An MCP Server for Building Software: Let Claude or Cursor Create, Build and Run Your Product
Orkosi Team · · 5 min read
Every assistant that matters in 2026 can call tools, and most of them agree on how: the Model Context Protocol, or MCP. If you have added a connector to Claude or an MCP server to Cursor, you have used it. This article explains what an MCP server is in plain words, why it is the right door for a platform that builds software, and what a good one looks like when the job is "create my product and ship the work".
What an MCP server is
An MCP server is a small program that tells an assistant three things: here are my tools, here is what each one needs as input, here is what it answers. The assistant asks for the list once, then calls tools by name while it works, the same way it would call a calculator or a search. The protocol is JSON over a connection; the connection is either a local process on your machine or a URL on the internet.
The part that makes MCP useful rather than merely tidy: the assistant chooses when to call a tool. You say "add a login page to my product" and the assistant decides that this is a create_task call with a title and a description it writes itself. You do not type commands; you talk.
Why a build platform should speak MCP
A platform that builds and hosts software has a handful of verbs: who am I, create a product, list products, create a task, read a task, how much have I spent. Those verbs are exactly a tool list. Exposed through MCP, they let any assistant become a front door to the platform without the platform writing one integration per assistant. Claude on the web, Claude Desktop, Cursor, Windsurf, Zed and the next tool nobody has heard of yet all get the same tools on the same day.
For you, it means the thing you already use to think becomes the thing you use to build. For the platform, it means the same limits apply as everywhere else, because each tool call is a call to its ordinary API with your key.
The tool list that covers the whole job
A good set is short enough to remember and complete enough to never need the web mid-flow:
- whoami: the workspace, the plan, the scopes of the key, the credit balance, how many products exist. The assistant should call it first.
- create product / list products / get product / update product / archive product: the product is the unit everything attaches to. Create gives it a URL at once. Archive never deletes.
- create task / list tasks / get task: a task is a work order the platform plans, builds, tests and deploys. The assistant writes the description; the platform does the rest and reports status.
- costs: what has been spent. An assistant that can read this will warn you before creating ten tasks.
Everything else (keys, billing, team, hosting settings) belongs in the web hub, signed in as a person. Keeping it out of the tool list is a feature: a runaway assistant can create tasks it should not have, which costs credits; it cannot invite strangers or change your card.
Remote or local
MCP servers come in two shapes. A remote server is a URL; you give the assistant the URL and your API key as a header, and nothing is installed. This is the one to use from a laptop or from Claude on the web. A local server is a program the assistant starts on your machine; it is useful when the tools need your files, which "build my product" does not. For a build platform, remote is the default and local is a convenience for teams that run the platform's code.
Two technical details worth knowing when you set one up. Remote servers should be stateless: every request complete on its own, so a retry or a load balancer never breaks a session. And the assistant needs a key to call them; a platform that offers signup by API lets the assistant get that key itself, from a single call with your name, your email and your agreement to the terms.
Setting it up with Claude and Cursor
Claude on the web: Settings, Connectors, add a custom connector, paste the server URL and the authorization header with your key. Claude lists the tools and uses them in any conversation where you ask it to.
Claude Desktop or Cursor: add the server to the MCP configuration file. For a remote server that is the URL and the header; for a local one it is the command to run and the key in its environment. Restart the client and ask it to call whoami.
Getting the key without the hub: ask the assistant to call the platform's signup endpoint first (name, email, terms accepted), keep the key it returns, then add it to the connector. You set your password later from the verification email.
What a session looks like
"Call whoami." The assistant reports: free plan, one product allowed, a hundred credits. "Create a SaaS called Fieldbook for field biologists to log observations offline." The assistant creates the product and gives you the URL. "First task: a sign-in page with magic links; second: an observations list that works offline and syncs." Two tasks, two proper descriptions, two ids. Later: "What is Fieldbook doing?" The assistant reads both tasks and says the first is deployed to preview and the second is in review. You never opened a terminal.
Checklist for choosing a platform's MCP server
- The tool list covers identity, products, tasks and cost, and nothing dangerous.
- Remote and stateless, with the API key as a plain header.
- The same limits as the web: scopes on the key, rate limits per plan, a product cap on the free plan, credits you can read.
- A signup call so the assistant can get a key for you.
- A web hub where everything the assistant did is visible and yours.
Orkosi publishes exactly this: a remote MCP server, a signup call that returns a scoped key, and the same ten tools for every MCP client. The reference for the assistant is at orkosi.com/docs/public-api.