mcp-server
MCP server
How to put a remote MCP server in front of outside agents and get it listed, written so the next product does not relearn it. The lessons come from products built on the same stack (Next.js + Supabase + Clerk + Netlify): a live Q&A product with an authenticated server, a stdio package and an anonymous ChatGPT plugin, and a monitoring product that decided against any unauthenticated surface. They appear here only as examples.
What is true of one product alone lives in that product's repository, in records this skill names by what they hold:
- the API contract: every REST route and MCP tool, what it accepts, returns and refuses;
- the distribution record: one row per listing (directory, registry, package), with its state, its date and how it is updated, and each client verified, with the date and what was called;
- the decision log: dated decisions that had real options, each with its reopen trigger;
- the backlog: deferred work, each item with the trigger that reopens it.
Clerk's settings for OAuth are not here. They are in clerk-production § MCP OAuth, with the four behaviours the route must allow for: a discovery list that is not the token's shape, a 503 for a verifier outage, an unknown kid refused before Clerk sees it, and revocation unseen until expiry. Read that section before writing the route; this skill does not repeat it.
What binds, in order
saas-authorization. A tool is a route: its caller is resolved by the three functions, deterministic code decides what it may do, and everything it returns that a person wrote is untrusted text.clerk-production§ MCP OAuth for every Clerk setting, applied and re-read per instance.- This skill for the server, its tools, the directories, the clients and the package.
- The directories' own current pages. They change without notice: read them again before every submission, and record the date you read them. Where this skill and a directory's page disagree, the page wins and this skill gets a dated correction.