How to build an MCP server

Almost everyone searching about MCP servers wants to install one. This category is for the much smaller group who are writing one, and the split matters enough that it decided the name of the page you are on.

We checked before building this. The high-volume queries around MCP and Claude Code are overwhelmingly install and configure intent: how to add a server, which server is best, why the config file is not working, and a long tail of specific vendor integrations. Those questions are answered by the official quickstart, they are answered well, and a directory of skills is the wrong shape of thing to answer them with. So nothing here tells you how to add a server to your client. The verb in the title is doing real work: it is what separates this page from the much larger question next door.

What is actually hard about building one, and it is not the part people expect. Standing up a server that returns a tool list is an afternoon. The expensive parts are the ones with a specification behind them that you either match exactly or fail silently: the transport and what it requires of your responses, the authorisation flow and its metadata documents, the schema your tools advertise, and the policy your submission is judged against. Those are four different bodies of detail, none of them guessable, and all four have changed at least once. That is why this is six skills and not one. The anchor takes you end to end and hands off; the other five each own one of the hard parts and go deep enough to be useful when you are stuck inside it.

A warning about dates, which applies more here than anywhere else on this site. MCP's authorisation approach has been revised more than once, transports have been added and deprecated, and directory policy is a living document. Every skill in this category names the revision it describes and the date it was verified. Read that line first. Where a file could not verify something against live documentation, it says so rather than guessing, because a confidently wrong OAuth flow is worse than an absent one.

None of these has been measured, and that is stated on every card and at the top of every page. The honest position is that several of them have an unusually clean objective spine: whether a server responds correctly to an initialise request, whether the advertised schema validates, whether the metadata document contains the required fields, and whether a submission package has every required element are all things a checker can decide without an opinion. Those are near the front of the queue. The design-judgement parts, such as whether a tool set is well factored for an assistant to use, are not, and they are labelled accordingly.

What is not here. Installing or configuring a server in any client, picking which existing server to use, and anything about the wider agent frameworks that consume MCP. The first two are covered better by the official documentation, and the third is a different subject.

Measured means the skill was given a realistic task on real material, then the identical task was run again with the skill removed, five runs each way. Each output was graded alone, against a rubric written by someone who had never seen the skill, by a session that was not told the other arm existed. Whether it passed was decided by a rule written down before any run executed. Those pages carry the worst case, the median, the p value, and what the skill costs you as well as what it buys.

Not yet measured means exactly that. It is written, it has been read, it is free to take, and we have run no experiment on it, so we make no claim about what it does to an output. It is not a skill that failed. Skills that failed are not published at all, in either state, and their numbers are in the results table.

Measuring one skill properly costs roughly twenty model sessions. We are working down the queue and moving skills from the second group into the first. Read the full method, or go back to all skills.