Skip to content

Running Model Context Protocol locally

Use this page to run the extracted TypeScript MCP server and try its weather tool and resource in MCP Inspector. The server communicates with its client through standard input and output, so it waits for a client instead of opening a project page or application port.

What you need first

Install Node 24. MCP Inspector sets a minimum Node version (22.19 at the time of writing); Node 24 is above that minimum, while an older LTS release may not start the testing UI.

This project does not require an API key or .env file. MCP clients launch the server as a child process, so the Node version and environment it runs with come from whatever launches it on your machine.

JunoWhat you need first Install Node 24, and that is the whole list of requirements: no API key, no .env file. The one surprise is that this server never opens a web page; it waits quietly for a client, which fooled me completely the first time I ran one.
JunoWhat you need first Node 24 satisfies the minimum Node version for both the TypeScript server and Inspector, so one install covers both. The project talks over stdio rather than an HTTP port, so do not wait for a URL that is never coming.
JunoWhat you need first The client spawns this server as a child process, so the Node version and environment come from whatever launches it, not from the server's folder. That is why the client-side Node install matters even though the server itself needs no key and no port. "The server needs nothing" stays true only while the client that launches it runs a supported Node version.

Install and repair the server

Open a terminal in the extracted server folder containing package.json:

bash
$ cd path-to-your-downloaded-project
$ npm ci
$ npm install --save-dev tsx

The final command records tsx, the tool that runs TypeScript files, which the extracted "start": "tsx server.ts" script expects.

You can start the stdio server directly:

bash
$ npm start

It waits for an MCP client instead of printing a browser URL. Stop it with Ctrl+C before starting Inspector.

JunoInstall and repair the server Run npm ci, add the missing tsx tool that runs TypeScript files, then try npm start. When the terminal goes quiet, nothing is wrong: the server is waiting for a client to talk to it. I restarted mine three times before anyone told me that!
JunoInstall and repair the server The package's start script already expects tsx, so recording it as a dev dependency is the smallest repeatable repair. And a waiting stdio process is a successful start, not a hang; resist the urge to keep restarting it.
JunoInstall and repair the servernpm ci installed only what the shipped lockfile recorded, and tsx was not in it. Installing with --save-dev writes tsx into package.json and the lockfile. That recorded dependency is what lets a client later launch the server with npm exec from any directory. Repairs recorded in the manifest survive; the ones that exist only in your shell history do not.

Test it with MCP Inspector

From the same project folder, run the official MCP Inspector:

bash
$ npx @modelcontextprotocol/inspector npx tsx server.ts

The first npx downloads and starts Inspector, and it may ask permission for that one-time install; confirm that the package is @modelcontextprotocol/inspector before accepting, and for repeatable team use, pin a reviewed version instead of relying indefinitely on the newest release. Inspector then launches your server with npx tsx server.ts as its stdio child process. Its web UI runs on its own local port, separate from the stdio connection to the server. Open the local URL printed in the terminal if it does not open automatically.

In Inspector, connect to the server, list its tools and resources, and call the weather tool with one of the inputs used in the course. The tool use chapter explains what a tool definition like this gives a model. Leave the terminal open while testing, then stop Inspector and the child server with Ctrl+C.

JunoTest it with MCP Inspector Run the Inspector command, open its local URL, connect, then list and call the course tool and resource. Check the package name before accepting the download, the same way you check a web address before opening it.
JunoTest it with MCP Inspector Inspector is the client here and it launches server.ts as its stdio child. Verify discovery before invocation: if the tool list is empty, calling anything is pointless. Keep the terminal open and stop both processes with Ctrl+C.
JunoTest it with MCP Inspector The inner command is the same process contract the next section gives to desktop clients, so getting it working here means the client configuration later is copying values rather than debugging. And Inspector's web UI port is separate from the stdio transport: a busy port blocks the web UI while the server itself keeps running.

Connect another MCP client

A desktop client needs an executable command and arguments for launching the same stdio server. First, copy the absolute paths to the extracted project folder and its server.ts file. Configure the client with this process contract, replacing both example paths:

text
command: npm
arguments:
  - --prefix
  - /absolute/path/to/project
  - exec
  - --
  - tsx
  - /absolute/path/to/project/server.ts

The --prefix value makes npm use the tsx dependency installed in that project even when the desktop client starts from another working directory. A client configured to run tsx on its own, with no npm --prefix in front of it, depends instead on a global install and on the client's PATH, which often differs from your terminal's. Keep each argument as a separate item so paths containing spaces remain one value. Do not add a URL or port: this server communicates over stdio.

Connecting servers like this one is how desktop clients give their models tools; the agents chapter covers the loop that uses those tools.

Client configuration formats differ, so map that command and those arguments to the fields in the client's current MCP setup instructions. Restart the client after changing its configuration. You do not need another project download: connect it to the extracted server you already tested.

JunoConnect another MCP client Set the command to npm, add the documented arguments with both absolute paths filled in, then restart the client. You are reusing the same extracted server Inspector tested, so if it worked there, the server side is already proven.
JunoConnect another MCP client Client configuration syntax varies, but the process contract stays the same: npm --prefix selects the project, and exec -- tsx launches its TypeScript server over stdio. Map those pieces onto whatever field names the client uses.
JunoConnect another MCP client A client configured to run tsx on its own works only on machines that already have a global install, and desktop clients rarely inherit your terminal's PATH. The npm --prefix and exec command pins the launch to the project's own recorded dependency instead. Configurations that depend on the launching environment are the ones that fail on the second machine.

Troubleshooting

tsx: command not found: Run npm install --save-dev tsx in the project folder. For a desktop client, also confirm that its command is npm and its arguments begin with --prefix followed by the absolute project path.

Inspector rejects the Node version: Install Node 24, verify with node --version, and reopen the terminal.

npm start appears to hang: That is expected for a stdio server waiting for a client. Use Inspector to interact with it.

Inspector shows no tools: Check the terminal for TypeScript or connection errors and confirm the final command ends with npx tsx server.ts.

JunoTroubleshooting Install tsx if it is missing, move to Node 24 if Inspector refuses to start, and remember that a quiet server is a waiting server, not a broken one. Nearly every problem on this page is one of those three.
JunoTroubleshooting Separate the three failure layers: the tsx installation, Inspector's minimum Node version, and the stdio connection itself. Check the terminal output before assuming tool registration failed; the real error is usually printed there already.
JunoTroubleshooting Trace the chain in order: outer Inspector process, child launch command, TypeScript execution, MCP initialization. Any step in that chain can leave the tool list empty, and the terminal tells you which one broke if you read it before restarting things. Restarting first is the common instinct, and it rarely tells you anything.