# How to Ship an MCP Server So AI Assistants Can Use Your Product > How to ship an MCP server: pick 3-6 tools from real user jobs, reuse your API and sign-in, keep writes safe, and host it remotely for AI assistants. ```yaml url: "https://makerhunt.io/studio/how-to-ship-an-mcp-server-for-your-product" markdown: "https://makerhunt.io/studio/how-to-ship-an-mcp-server-for-your-product.md" title: How to Ship an MCP Server So AI Assistants Can Use Your Product type: studio_article category: Growth tags: "MCP server, Model Context Protocol, build an MCP server, MCP server for SaaS, remote MCP server, MCP tools, MCP vs API, AI assistants, makers, Growth" featured_image: "https://txmhk1zrnc.ufs.sh/f/xSkWTCqmKWx9ohKQNz3waZD4fI5qz2hmxQ0kUL1XNBntoS7M" published_at: "2026-11-05T09:52:58.266Z" updated_at: "2026-11-05T09:52:58.869Z" ``` ## About this studio article How to ship an MCP server: pick 3-6 tools from real user jobs, reuse your API and sign-in, keep writes safe, and host it remotely for AI assistants. ## Article An MCP server is a small adapter that lets AI assistants such as Claude, ChatGPT, Cursor and VS Code call a few of your product's actions and read some of its data as tools. To ship one, pick three to six tools around jobs your users already do, build them on top of your existing API and permissions, keep write actions safe, describe every tool in plain words, and host it as a remote server so people can connect it by pasting a URL. This guide is for solo makers and teams of two or three whose users have started asking "can I use your product from my assistant?" The worked example near the end is made up. Protocol details come from the official Model Context Protocol specification and docs, checked on 5 November 2026, when the current specification revision was 2026-07-28. ## What is an MCP server, and who runs MCP? The Model Context Protocol (MCP) is an [open standard for connecting AI applications to outside systems](https://modelcontextprotocol.io/docs/getting-started/intro). Anthropic [open-sourced MCP in November 2024](https://www.anthropic.com/news/model-context-protocol), and in December 2025 it [became a founding project of the Agentic AI Foundation](https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/), a fund under the Linux Foundation. The protocol's maintainers still set its technical direction. The host is the AI app your user sits in, the client is the connector inside it, and the server is the part you build. Your MCP server does not replace your product or your API. It is a thin layer that translates between the assistant and things your product already does. ## Do you need an MCP server, or just an API? Short answer on MCP vs API: an MCP server usually sits on top of your API, so you need the API, or at least clean internal functions, first. The real question is which surface your users need next. Option Best when Skip it when Public API Customers' developers want to script and sync data Nobody has asked for programmatic access Zapier or Make integration Non-technical users want "when X happens here, do Y there" The jobs are one-off questions, not triggers MCP server Users already work inside an assistant and want to ask about or act on their data from there Your product has no clear actions a model could take for a user Nothing yet You have few users and no repeated asks Several customers asked for the same thing this month ## What are MCP tools, resources and prompts? The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28) lets a server offer three things: - **Tools** are functions the model can call, such as "find invoices for this client". The model decides when to use them. - **Resources** are data the user or model can attach as context, such as a project summary. - **Prompts** are message templates a user picks on purpose, a bit like saved commands. Start with tools; add resources or prompts later if users keep pasting the same context. ## Should your MCP server be local or remote? The [spec defines two standard transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports). A local server uses stdio: the user's app launches it as a process on their machine. A remote server uses Streamable HTTP: each message is an HTTP POST to one endpoint on your domain. For a SaaS product, ship a remote MCP server. Your data already lives on your servers, users install nothing, and you fix bugs once for everyone. Claude shows why: its [custom connectors reach your server from Anthropic's cloud](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), even from the desktop app, so the server must be reachable on the public internet. Local servers suit products that work on the user's own files or a CLI. The older HTTP plus SSE transport is deprecated, so do not start there. The 2026-07-28 revision also helps small teams. Its [changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog) removed protocol-level sessions and the opening handshake, and the [release post](https://blog.modelcontextprotocol.io/posts/2026-07-28/) says any request can now land on any instance behind a plain load balancer. If you need state across calls, return an explicit handle, such as a draft ID, and take it back as an ordinary argument. ## How should users sign in to a remote MCP server? The [MCP authorization spec](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) is built on OAuth. Your MCP server accepts access tokens, an authorization server (yours, or an identity provider you already use) runs the sign-in screen, and your server publishes a small metadata document telling clients where that authorization server lives. The current revision prefers Client ID Metadata Documents for client registration and marks Dynamic Client Registration as deprecated but still available. Three rules matter most: - Every user signs in as themselves, so every tool call runs with that user's permissions. - Your server accepts only tokens issued for it. The spec forbids accepting or passing along any other token. - Ask for the smallest scopes that work, starting with read, and request more only when a write tool needs it. Can you start with an API key? Sometimes. Cursor lets users put headers, including a key, in their `mcp.json` config. Claude's [connector authentication docs](https://claude.com/docs/connectors/building/authentication) list a fixed request-header credential as a beta for a limited set of organizations, shared by the whole organization rather than per person. Fine for early testers; plan on OAuth for ordinary Claude users. ## Which MCP tools should you ship first? Pick from evidence, not your feature list: 1. **Support questions.** "How many X do I have?" and "where is Y?" make perfect read tools. 2. **Most-used actions.** Check your logs for what people repeat every week. 3. **Copy and paste.** If users copy data from your app into a chat window, a tool can fetch it. Then cut hard. Three to six tools is plenty for version one. Every extra tool is one more description the model must read and one more choice it can get wrong. ## How do you write tool names and descriptions a model uses correctly? The model picks tools by reading their names, descriptions and input schemas, so treat them as product copy. Claude's [connector testing guide](https://claude.com/docs/connectors/building/testing) says the name and description you give each tool are what Claude reads when deciding to call it. From the [tools section of the spec](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) and practice: - Names are unique, with letters, digits, underscores or hyphens and no spaces. Use verb plus object, like `search_invoices`. - Descriptions say what the tool does, when to use it and what it returns, in one to three sentences. - Input schemas use JSON Schema: mark required fields, use enums for fixed choices, describe date formats. - If two tools could answer the same question, say in each when to use which. Part Weak Better Name query search_invoices Description "Gets data." "Find invoices in the user's workspace by client, status or date range. Returns up to 20, newest first." Date field date (string) issued_after: "Date as YYYY-MM-DD. Leave empty for all dates." Status field status (string) status: one of draft, sent, paid, overdue Write tool "Updates an invoice." "Mark one invoice as paid. Use only after the user confirms the invoice number." Overlap Two tools that both "get clients" "Use list_clients to browse. Use get_client when you have an ID." ## How do you keep write tools safe? Ship read tools first. Add write tools one at a time, and keep destructive ones (delete, cancel, refund, email customers) out of version one or behind an extra step. The spec says a human should always be able to deny a tool call, and Cursor asks for approval before running MCP tools by default, but do not rely only on the client. A pattern that works: one tool creates a draft and returns a preview, and a second commits it after the user has seen it. The spec also defines tool annotations: `readOnlyHint`, `destructiveHint`, `idempotentHint` and `openWorldHint`. Set them honestly so clients can warn better. They are hints, though: the spec tells clients to treat annotations as untrusted unless the server is trusted. Real safety comes from your permissions and confirmations. ## How much data should a tool return, and what should errors say? Less than you think. Tool results can land in the model's context, and big dumps make answers slower and worse. Return a short, capped list with IDs and the few fields people ask about, support paging, and offer a separate tool for full details of one item. Strip HTML and fields nobody needs. Errors should be something the model can act on. The spec separates protocol errors, like an unknown tool, from tool execution errors, which come back as a normal result with `isError` set to true and a message the model reads. "Error 400" is useless. "No client named Acme found. Try list_clients to see exact names." lets the model fix its own call. ## How do you handle rate limits and per-user scoping? The spec says servers must validate inputs, apply access controls and rate limit tool calls. Reuse what your API already does: the same permission checks, limits and audit log. The tool list can also vary by what the caller's token allows, so read-only users never see write tools. Our guide to [shipping a public API your first customers will use](https://makerhunt.io/studio/how-to-ship-a-public-api-your-first-customers-will-use) covers keys and rate limits in depth. ## What are the security risks of an MCP server? The model reads whatever your tools return. If a record contains text written by an outsider, such as a support message, that text can try to instruct the model; see EarlyHunt's guide to [protecting an AI product from prompt injection](https://earlyhunt.com/studio/how-to-protect-your-ai-product-from-prompt-injection). The official [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices) add rules worth copying: - No token passthrough. Never forward a token the client gave you to another service. - No wildcard scopes like "all" or "full access". - A state handle is not a password. Check on every call that a draft ID belongs to the caller. ![A person typing on a silver laptop at a wooden table, with a takeaway coffee cup in the soft-focus background](https://images.pexels.com/photos/6829472/pexels-photo-6829472.jpeg?auto=compress&cs=tinysrgb&w=1200&h=800&fit=crop) ## Which SDK should you use to build an MCP server, and how do you test it? Use an official SDK. The [MCP SDK list](https://modelcontextprotocol.io/docs/sdk) rates TypeScript, Python, C#, Go, Rust and Ruby as Tier 1, Java as Tier 2, and Swift, PHP and Kotlin as Tier 3. SDKs adopt spec revisions on their own schedules, so check which ones yours supports. The [MCP Inspector](https://modelcontextprotocol.io/docs/tools/inspector) is the reference test tool. It runs through npx with no install, as a browser UI, a command-line client for CI, or a terminal UI. List your tools, call each with good and bad arguments, and read the raw messages. Then test in a real assistant, because that is where you learn whether the model picks the right tool. Add your server to your own Claude account as a custom connector (Claude's testing guide suggests a tunnel for a server on your laptop), ask ten real user questions, and check which tool each one calls. ## How do users install your MCP server? - **Claude:** Customize, Connectors, Add, Custom, Web, then paste your server URL. The help article notes Free plan users get one custom connector, and on Team and Enterprise an owner adds it first. - **Cursor:** add your URL under `mcpServers` in a project or global `mcp.json`, per [Cursor's MCP docs](https://cursor.com/docs/context/mcp). Cursor handles OAuth sign-in for remote servers. - **VS Code:** run MCP: Add Server, choose HTTP and enter your URL, per the [VS Code guide to adding MCP servers](https://code.visualstudio.com/docs/copilot/customization/mcp-servers). ## How do people find your MCP server? 1. **A docs page** called "Use [your product] with your AI assistant": the URL, what each tool does, install steps and example questions. 2. **A changelog note and an email** to the users who asked. 3. **The official MCP Registry.** The [MCP Registry](https://modelcontextprotocol.io/registry/about) is in preview and stores metadata about public servers, remote ones included, which marketplaces and other aggregators pull. You describe the server in a `server.json` file, prove the namespace through GitHub or your domain, and publish with `mcp-publisher`, as the [registry quickstart](https://modelcontextprotocol.io/registry/quickstart) shows. 4. **Coverage by other people.** A launch post on maker communities helps, and so does getting your product into a [real roundup article on Listed Press](https://listedpress.com/), where readers compare tools before picking one. Getting assistants to recommend your product is a different job; the Aura++ playbook on [getting cited in AI search answers](https://auraplusplus.com/studio/how-to-get-your-startup-cited-in-ai-search-answers) covers it. ## How do you measure whether anyone uses it? Log every tool call with user, tool name, error or not, and duration. Under the 2026-07-28 revision clients should identify themselves on each request, so you can usually see which assistant called too. Each week, check how many users made a call, which tools get used and which never do, the error rate per tool, and how many users come back. A tool with lots of errors usually needs better words, not more code. ## A tool inventory sheet Fill this in before writing server code, one row per candidate tool. The example column uses the made-up Corbelnote app below. Column What to write Example Job The user's task in their words "What's still open on the Hale Street job?" Evidence Where the ask came from Repeated support emails Tool name Verb plus object list_open_items Read or write Read, write or destructive Read Existing endpoint The API route it wraps Items list with a status filter Scope needed The smallest permission that works Read projects Ship in v1? Yes, later or never Yes ![Three colleagues studying circles, arrows and notes drawn in marker on a glass wall in a bright office](https://images.pexels.com/photos/4623494/pexels-photo-4623494.jpeg?auto=compress&cs=tinysrgb&w=1200&h=800&fit=crop) ## A made-up example: Corbelnote ships four tools Corbelnote is an invented app for small renovation crews: site notes, photos and punch lists per job. Its founder, Radek, kept getting the same email from customers who plan their week in Claude: "Can Claude see my open punch lists?" He filled in the inventory sheet from support email and cut eleven ideas to four tools: `list_jobs`, `list_open_items`, `get_item` and `add_note`. Three only read. `add_note` adds a note to an existing item and cannot delete or close anything. He built on his existing API with the TypeScript SDK, used his app's existing sign-in, and gave notes their own scope. The first Claude test went badly. Asked "what's left at Hale Street?", the model called `list_jobs` and stopped. Radek rewrote the `list_open_items` description to "Use this for questions about what is left, open or unfinished on a job" and added a job name field. His next ten test questions all reached the right tool. Deleting items stayed out of version one on purpose. ## What traps catch small teams? - **Wrapping every endpoint.** Fifty tools confuse the model and multiply testing. - **One shared key for everyone.** You cannot tell users apart or limit what each sees. - **Returning everything.** Huge results crowd the conversation and leak data nobody asked for. - **Treating annotations as security.** A read-only hint does not make a tool read-only. - **Testing only in the Inspector.** It proves the server works, not that a model picks the right tool. ## A 7-day plan to ship your first MCP server A planning guess for a solo maker with an existing API, not a benchmark. Day Do Done when 1 Fill in the inventory sheet from support email and logs Three to six tools picked 2 Scaffold a remote server with an official SDK; wire one read tool It works in the MCP Inspector 3 Add the other read tools with capped, paged results Results are small and useful 4 Add sign-in, per-user permissions and minimal scopes A test user sees only their data 5 Test in Claude, Cursor and VS Code with ten real questions Most questions reach the right tool 6 Add one safe write tool, logging and rate limits Writes need confirmation and appear in logs 7 Publish the docs page, changelog note and email Someone outside your team connects it ## MCP server FAQ ### What is an MCP server? An MCP server is a small service that exposes some of your product's actions and data as tools an AI assistant can call through the Model Context Protocol, an open standard supported by Claude, ChatGPT, Cursor, VS Code and others. ### Do I need an API before an MCP server? Usually yes, or at least clean internal functions with permission checks. The MCP server is a thin layer that calls them and should not hold new business logic. ### Should my MCP server be local or remote? Remote, if your product is a web app: users connect with a URL and you update one place. Local suits products that work on the user's own files or machine. ### Is an MCP server safe to give users? It can be, if each user signs in as themselves, tools follow your existing permissions, writes need confirmation, destructive actions are left out or gated, and you never pass tokens through. ## Ship three tools this week You do not need a big AI strategy to show up where your users already work. Pick three read tools, describe them well and put a URL in your docs. When it is live, tell other makers on [MakerHunt](https://makerhunt.io/). ## Links - Article (HTML): https://makerhunt.io/studio/how-to-ship-an-mcp-server-for-your-product - AI-friendly Markdown: https://makerhunt.io/studio/how-to-ship-an-mcp-server-for-your-product.md ## Explore - [Studio index](https://makerhunt.io/studio) - [Blog](https://makerhunt.io/blog) - [Browse projects](https://makerhunt.io/projects) _HTML version: https://makerhunt.io/studio/how-to-ship-an-mcp-server-for-your-product_