I Installed an MCP Server and Tested It: Here's What Happened

Amina Alam — Sun, 25 Oct 2026 11:11:05 +0000

Tested on: Windows 11 (HP ZBook Firefly), Node.js v24.22.1 (LTS), npm 11.19.1, MCP Inspector v2.12.0, official filesystem MCP server, 23 October 2026.

MCP (Model Context Protocol) is an open standard that lets AI apps connect to tools and data in a common format. I installed the official filesystem MCP server, connected to it using the MCP Inspector, and ran two of its tools against a test folder. It worked on my second attempt. The first attempt failed on Windows, and the fix was one small change to the command.

What You Need

Windows with PowerShell
Node.js (LTS version)
A test folder with a few harmless files

Step 1: Install Node.js and Check It

I installed Node.js with Winget:

winget install OpenJS.NodeJS.LTS

After closing and reopening PowerShell, I checked the versions:
node --version
npm --version
My output was v24.22.1 for Node and 11.19.1 for npm.

First Problem: npm Was Blocked

node --version worked, but npm --version showed a red error saying running scripts is disabled on this system. Windows PowerShell blocks script files by default, and npm uses one. I fixed it by running:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

This changes the setting only for my user account. After that, npm --version printed 11.19.1. Using npm.cmd instead of npm should also work, though I didn’t try it.

Step 2: Create a Safe Test Folder

I made a folder called mcp-test on my Desktop with 3 small text files (a.txt, b.txt, notes.txt). I used a test folder on purpose: an MCP server can only reach the folders you give it, so I did not want it pointed at anything private.

Step 3: Start the Inspector with the Filesystem Server

The MCP Inspector is a browser tool for testing MCP servers. This command starts it and launches the filesystem server for my test folder:
npx.cmd -y @modelcontextprotocol/inspector npx.cmd -y @modelcontextprotocol/server-filesystem "C:\Users\hp\Desktop\mcp-test"

The first run downloaded packages, which took a minute or two. The terminal then printed a local address starting with 127.0.0.1, and the Inspector opened in Chrome. The page showed version v2.12.0.

Second Problem: The First Connection Failed

My first attempt used plain npx for the inner command, and clicking Connect in the Inspector showed "Failed". On Windows, npx can fail when another program launches it. I closed PowerShell, ran the command again with npx.cmd in both places, and it connected.

Step 4: List the Tools

Once connected, the Inspector showed a green status dot and the server name secure-filesystem-server. Under the Tools tab, it listed 14 tools, including read_file, read_text_file, list_directory, and read_media_file.

The right-hand panel showed the first MCP message: a tools/list request from the client to the server, status OK, completed in 115 ms. This is how a client discovers what a server can do.

Step 5: Run a Tool

I ran list_directory on my test folder. The server returned the three files I had created: a.txt, b.txt, and notes.txt. The Inspector showed the result as plain text and as structured output, and the message panel logged the request as a tools/call for list_directory, completed in 45 ms with status OK.

I also chose read_text_file and entered the path to one of my test files, C:\Users\hp\Desktop\mcp-test\a.txt. The tool has two optional fields, head and tail, which limit the result to the first or last N lines.

Third Problem: Empty Result

My first run returned nothing. Either the head/tail fields or the empty file caused this. After adding text to one of the files, the tool returned the file's text: "This is a text file".

What I Learned

MCP is a request and response conversation. The client asks what tools exist, then calls one, and each step shows up as a message you can inspect.
Windows adds friction. Script policies and npx versus npx.cmd caused two of my three problems, so it's worth knowing both fixes.
Access is limited by design. The server only reaches the folder you give it, which is why a test folder is the right way to start.
Optional fields matter. An empty or zero value in an optional field can look like a broken tool.

Why This Matters for Developers

With a server like this, an AI assistant can read project files through a standard interface rather than a custom integration. Testing it in the Inspector first means you can see exactly what a server exposes before connecting it to an AI app.

Next Steps

Next, I want to connect this server to Claude Desktop and compare what the client shows with what I saw in the Inspector.

DEV Community: Amina Alam