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 requires Node 22.19 or newer, so Node 24 clears 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 it runs with comes from whatever launches it on your machine: your terminal, Inspector, or a desktop client.

JunoWhat you need first Install Node 24, and that is the whole list: no API key, no .env file.

Expect one surprise: this server never opens a web page. It waits quietly for a client to talk to it.

JunoWhat you need first Node 24 covers both the TypeScript server and Inspector's minimum Node version, so one install is enough.

The project talks over stdio rather than an HTTP port, so don't wait for a server URL. The only URL you will open is Inspector's.

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 Node install on the launching side matters even though the server needs no key and opens no port.

Install and repair the server

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

$ 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:

$ 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. Stop it with Ctrl+C before you open Inspector.

JunoInstall and repair the server The start script already calls tsx, so recording it as a dev dependency is the smallest repair that sticks.

A waiting stdio process is a successful start, not a hang, so there is no need to restart it.

JunoInstall and repair the servernpm ci installs only what the shipped lockfile records, and tsx is not in it. Installing with --save-dev writes tsx into package.json and the lockfile.

That recorded dependency is what lets a desktop client launch the server later with npm exec from any directory, without touching server.ts.

Test it with MCP Inspector

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

$ npx @modelcontextprotocol/inspector npx tsx server.ts

The first npx downloads and starts Inspector. Inspector then launches your server with npx tsx server.ts as its stdio child process. Inspector's 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.

Approve the one-time package download deliberately

npx may ask permission to install MCP Inspector. Confirm that the package is @modelcontextprotocol/inspector before accepting. For repeatable team use, pin a reviewed version instead of relying indefinitely on the newest release.

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 the local URL it prints, and connect. Then list the tools and resources and call the weather tool.

If npx asks to install a package, check that the name is @modelcontextprotocol/inspector before you accept.

JunoTest it with MCP Inspector Inspector is the client here, and it launches server.ts as its stdio child.

Check discovery before invocation: if the tool list is empty, calling anything will not work, so look at the terminal first. Keep the terminal open and stop both processes with Ctrl+C.

JunoTest it with MCP Inspector The outer npx runs Inspector and the inner command defines the child server transport. Inspector's web UI port is separate from that stdio pipe.

Once the inner command works here, the desktop client configuration in the next section is the same launch written as a command and arguments. Pin a reviewed Inspector version for repeatable team use.

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:

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, without 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.

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. The agents chapter covers the loop a client runs when its model uses tools like this one.

JunoConnect another MCP client Set the command to npm, add the arguments above with both absolute paths filled in, then restart the client.

You are reusing the server Inspector already tested, so if it worked there, the server side is fine and any problem is in the client's settings.

JunoConnect another MCP client Configuration syntax varies between clients, 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 your client uses.

JunoConnect another MCP client Desktop clients rarely inherit your terminal's PATH, so a bare tsx command works only where a global install happens to be visible.

Passing npm with the prefix, the exec separator, the runner and the absolute server path as separate arguments ties the launch to the project's own recorded dependency instead.

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 waiting, not broken.

Most problems on this page are one of those three.

JunoTroubleshooting Keep three failure layers apart: the tsx install, Inspector's minimum Node version, and the stdio connection itself.

Read the terminal before assuming tool registration failed; the real error is usually printed there already.

JunoTroubleshooting Trace the chain in order: the outer Inspector process, the child launch command, TypeScript execution, then MCP initialization.

Any link can leave the tool list empty, and the terminal output names the one that broke, so read it before restarting anything.