Hook it up — connecting the server.
You wrote the server. Now tell a client how to launch it, and the tool appears.
A server on its own does nothing — it has to be plugged into a client: the app or model that will use it (Claude for Desktop, an IDE, your own app). Hooking it up is smaller than you'd expect — a few lines of config that tell the client how to start your server.
That config lives in a small JSON file the client reads when it starts up — in Claude for Desktop it is called claude_desktop_config.json. Here is what each part of our entry actually means:
"mcpServers"The list of servers you want the client to run. Everything nests inside here — one block per server."scorecard"A name you choose — the label the client files this server under. It happens to equal the MCPServer("scorecard") in your code, but they are separate names: this one is the client's label; that one is what the server calls itself. Matching them is just tidiness."command"The program the client runs to start your server — here uv, a Python runner. It could be python, node, npx."args"The arguments handed to that command, exactly as on a command line. These say: in the ~/scorecard folder, run scorecard.py.Put together, those lines tell the client to run uv --directory ~/scorecard run scorecard.py — which launches your server — and then speak MCP to it. You never start the server yourself; the client does, using exactly this recipe. (Edit the file, then restart the client so it re-reads it.)
On startup, the client launches the server and asks it a single question — “what tools do you have?” The server answers with its tool definitions. This is discovery: the client now knows the tools exist, with no per-tool wiring. That is the whole promise of the standard socket, in action.
From then on, whenever a question calls for it, the model can reach for your tool — grounded in your real data. You wired it once; any MCP client could use the same server.
Add the config, connect, and watch the client discover your scorecard tool — then see the model reach for it.
Config in, tools out.
Connecting a server is a few lines of config — a name, the command to launch it, its arguments. The client starts it, asks what it offers, and lists the tools. From that point the model can call them whenever they fit the question.
This is the pay-off of the standard socket: no bespoke integration per tool. Write the server once, drop a few lines of config into any MCP client, and the tools are simply there.