Ship an MCP Server With Your Product, and Get It Found

Pick the transport

MCP gives you two transports. stdio runs the server as a subprocess of the client on the user's machine. Streamable HTTP runs it on your domain and the client connects over HTTPS. For a product, pick HTTP. Three reasons:

• ChatGPT only connects to remote HTTPS servers, and it requires two tools named search and fetch to treat you as a connector at all.
• Your users' data already lives on your side. A remote server reads it with their session, so you never ship credentials into a config file on a laptop.
• You can update the server without asking anyone to reinstall. A stdio server is a package version on someone else's disk.

The current specification is dated July 28, 2026. Start from the TypeScript SDK and the Streamable HTTP transport. A minimal server is under forty lines:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";

export const server = new McpServer({ name: "yourproduct", version: "1.0.0" });

server.registerTool(
  "search_launches",
  {
    title: "Search launches",
    description: "Find products launched on Nick Launches by keyword. Returns name, tagline, URL and upvotes.",
    inputSchema: { query: z.string().min(2), limit: z.number().int().max(25).default(10) },
  },
  async ({ query, limit }) => {
    const rows = await db.searchProducts(query, limit);
    return { content: [{ type: "text", text: JSON.stringify(rows) }] };
  },
);

// One transport per request; stateless is fine for most SaaS tools.
export async function handleMcp(req: Request): Promise<Response> {
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  await server.connect(transport);
  return transport.handleRequest(req);
}

Mount that at https://mcp.yourproduct.com/mcp or /api/mcp on your main domain. Keep it on a domain you own: a server on your own hostname is one of the things the registry can verify, and it is what a reader trusts when the install line shows up in a README.

Keep stdout clean

The specification is blunt about it: the server MUST NOT write anything to its stdout that is not a valid MCP message. stderr may be used for logging. In a stdio server, stdout is the wire. One console.log("connected") and the client reads a line that is not JSON-RPC, throws a -32700 parse error, and your server "works in the terminal" and breaks in every client.

Route every log to stderr on day one, including the ones from libraries you import.

// stdout belongs to the protocol. Everything human goes to stderr.
export const log = (...args: unknown[]) => console.error(new Date().toISOString(), ...args);

// Belt and braces for a stdio build: make console.log unusable.
if (process.env.MCP_TRANSPORT === "stdio") {
  console.log = (...args) => console.error("[redirected from stdout]", ...args);
}

Remote servers do not have this failure, which is another point for HTTP. They have a cousin: anything you print into a tool result is what the model reads, so a stack trace in a result is a stack trace in the agent's context. Return a short error string and log the rest.

Write tools an agent will actually pick

The agent never reads your docs. It reads the tool list, picks one, and sends arguments. So the description is the product page now, and the client constrains it. In Claude Code, server instructions and tool descriptions are truncated at 2,048 characters. Tool results over about 10,000 tokens get a warning, and results over 50,000 characters are written to disk and the model gets a pointer unless the server raises _meta["anthropic/maxResultSizeChars"]. Lead with the point. Say what comes back.

• Name tools as verbs on your nouns. search_launches, get_product, submit_product. Not api_v2_products_list.
• Return what the agent needs, not the row. Spec0, a launch here in September, serves Cursor and Claude Code one API operation at a time over MCP: about 300 tokens instead of a whole OpenAPI spec pasted into the chat. That is the shape to copy.
• Five tools beat fifty. Claude Code's Tool Search only loads a tool into context when it matches; a tool marked anthropic/alwaysLoad is exempt. Mark the one or two that define your product and let the rest be found.
• Ship prompts and resources if they are real. They are worth 16 of the 100 points in step 7, but a prompt nobody would use costs you trust with the one person who tries it.

OAuth 2.1 the way clients expect it

A remote server for a product means someone's account is behind it, so the client needs to log the user in. The flow every client implements now is OAuth 2.1 with an external authorization server, discovered from a 401:

1. The client calls your MCP endpoint with no token. You answer 401 with a WWW-Authenticate header pointing at your protected resource metadata (RFC 9728).
2. The client fetches /.well-known/oauth-protected-resource, finds your authorization server, and starts the authorization code flow with PKCE.
3. The user signs in on your domain, consents, and the client comes back with a token scoped to your server as the resource.

// 1. The 401 that starts discovery
return new Response("Unauthorized", {
  status: 401,
  headers: {
    "WWW-Authenticate":
      'Bearer resource_metadata="https://mcp.yourproduct.com/.well-known/oauth-protected-resource"',
  },
});

// 2. The metadata the client fetches next
// GET /.well-known/oauth-protected-resource
{
  "resource": "https://mcp.yourproduct.com/mcp",
  "authorization_servers": ["https://auth.yourproduct.com"],
  "scopes_supported": ["launches:read", "launches:write"],
  "bearer_methods_supported": ["header"]
}

Three things trip up servers that otherwise work:

• Use Client ID Metadata Documents, not Dynamic Client Registration. Claude, ChatGPT and the WorkOS write-up all point the same way: the client identifies itself with a hosted JSON document, and you do not keep a registration table that fills with abandoned clients.
• client_id is the app, sub is the user. Every Claude Code user arrives with the same client_id. Read sub for who they are, and reject any session token that has no client_id at all.
• Redirect URIs match exactly. localhost and 127.0.0.1 are different strings. Register both.

If you run Next.js with Supabase or Clerk, Makerkit's August write-up walks the whole flow on Next.js 16 and is the closest thing to a copy-paste reference. If you would rather not run an authorization server, WorkOS and Clerk both sell one that speaks this exact dance.

Get installed in every client

Your README needs one paste-able mcpServers block per client, not a sentence that says "add it to your MCP config". A bare npx line leaves the reader to work out where it goes. The JSON block is what the client consumes, and it is one of the nine checks in step 7.

Claude Code. The default scope is local, which means the server exists in the current project folder only. That is why a server you added on Monday has vanished by Wednesday in another repo. Tell users to pick a scope:

# For the user, every project (stored in ~/.claude.json)
claude mcp add --transport http --scope user yourproduct https://mcp.yourproduct.com/mcp

# For a team, checked in with the repo (stored in .mcp.json)
claude mcp add --transport http --scope project yourproduct https://mcp.yourproduct.com/mcp

{
  "mcpServers": {
    "yourproduct": {
      "type": "http",
      "url": "https://mcp.yourproduct.com/mcp"
    }
  }
}

Cursor. Global config lives in ~/.cursor/mcp.json, project config in .cursor/mcp.json, same mcpServers shape. Cursor also takes an install link you can put behind a button, with the config base64-encoded:

cursor://anysphere.cursor-deeplink/mcp/install?name=yourproduct&config=eyJ1cmwiOiJodHRwczovL21jcC55b3VycHJvZHVjdC5jb20vbWNwIn0=

Codex. Servers live in ~/.codex/config.toml under [mcp_servers.yourproduct], or run codex mcp add.

[mcp_servers.yourproduct]
url = "https://mcp.yourproduct.com/mcp"

ChatGPT. Connectors must be remote, over HTTPS, with search and fetch tools present, and OAuth is strongly recommended. If your server has those two tools it can be a connector; if it does not, ChatGPT will not list it, however good the rest is.

Registry, server card, skill

The official registry is where clients and directories pull from. Publish with a namespace you can verify (your GitHub org or your domain), a real description, and the source repo. The registry solves listing, not vouching: with thousands of near-duplicate entries from a handful of accounts, a verified domain namespace and a repo are what separate you from the noise. Check the registry's spam policy before you automate anything; rate limits were still "under consideration" in October.

A server card is a small JSON document that tells an agent "there is an MCP server for this site, here is how to connect". It is useful, and it is still a draft. SEP-2127 was approved by the community maintainers on August 13 and has not been merged into the specification; the proposed well-known path has moved from /.well-known/mcp/server-card.json to /.well-known/mcp/server-cards.json, and the experimental extension recommends GET <mcp-url>/server-card instead. Serve one, keep tool lists out of it (cards describe connectivity, not tools), and label it experimental in your docs so nobody files a bug when the path changes again.

{
  "name": "yourproduct",
  "version": "1.0.0",
  "description": "Search, read and submit launches on Nick Launches from your agent.",
  "endpoint": "https://mcp.yourproduct.com/mcp",
  "transport": "streamable-http",
  "authentication": { "type": "oauth2", "resource_metadata": "https://mcp.yourproduct.com/.well-known/oauth-protected-resource" },
  "documentation": "https://yourproduct.com/mcp"
}

Skills over MCP went final on September 13 as the io.modelcontextprotocol/skills extension: your server answers skills/list and skills/get, and the skill's files come through resources/read. In September about 270 providers were shipping a server and a skill as two separate installs. Serve both from the one server: the MCP tools give the agent access, the skill tells it the workflow. Client support is still rolling out, so keep the standalone skill folder too.

Then put a line in llms.txt pointing at your /mcp page. It is the one discovery file agents already read today.

Pre-grade yourself on the nine checks

Every MCP server on the AI agents board gets the same public score, whether the owner claimed the listing or not. The score never moves a listing up the rankings and nobody can pay to change it, so it is a straight reading of the server. The nine checks and what each is worth:

• Validated, 20. The server answered a real handshake: tools/list over HTTP, or a sandboxed stdio run of the npm package.
• Deployment, 15, required. A reachable endpoint or a runnable package on a domain or namespace that is yours.
• Tools, 15, required. A verified tool table, not a list in the README.
• Easy install, 12. A paste-able mcpServers config block. A bare npx line does not count.
• README, 10, required. Present, and it describes this server.
• License, 8. A license file. Anthropic's own skills repo shipped without one for a while; do not copy that.
• Prompts, 8. prompts/list returns something real.
• Resources, 8. resources/list returns something real.
• Claimed, 4. The owner claimed the listing.

The four introspection checks, 51 points between them, only count when the board can actually run the server: an npm package or a public HTTP endpoint. A Docker-only or build-it-yourself server leaves them out of the denominator and the grade caps at B. Before that rule existed, 274 of 291 listings were an F, and 127 of them could never have been anything else. The cap is what keeps it honest: no server reaches A without a verified tool table.