The real cost of a free MCP server, and how to vet one

Most MCP servers cost nothing to download. Many are open source, some are published by the company whose service they wrap, and plenty are weekend projects. "Free" describes the price tag, not the cost. You still pay: with the machine that runs the server, with the access you hand it, with the data that flows through it and, for servers that sit in front of a hosted service, with whatever that service's free tier allows and keeps. This guide explains what free really means for MCP servers, how to evaluate any server before you connect it to a coding or desktop agent, and how to roll one out without widening what your agent can do. If MCP itself is new to you, start with what MCP is; the protocol is specified at modelcontextprotocol.io.

Three kinds of free

When an MCP server is described as free, it usually falls into one of three groups, and each carries a different hidden cost.

Self-hosted servers keep data on your machine but hand you the operational work: installing dependencies, updating when vulnerabilities are fixed, and making sure the process cannot reach more than it needs. Servers that wrap a hosted service are only as free as that service's free tier; check its usage limits, what happens when you exceed them, and whether your agent will then fail clearly or quietly. Remote endpoints are the easiest to connect and the hardest to inspect. Remote vs local MCP servers covers that trade-off in depth.

Data use is the cost people miss

An agent passes a server whatever the task needs: file contents, code, customer names in a search query, a database row. For each server, find out:

• Where tool inputs and outputs go. A local server that calls an external API still sends your data to that API.
• Whether the operator logs requests, how long they keep them and whether they use them for anything else, training included.
• Whether the server needs a token, what scopes that token carries, and whether a narrower one would do.
• What the licence allows, if you plan to use the server inside a commercial product.

A free server that ships your source code to an unknown third party is not free.

How to evaluate any MCP server before connecting it

The same review works for a filesystem server, a browser automation server such as Playwright MCP, a vendor's official server or a search server. (For search specifically, see choosing a web search MCP server.)

1. Read the tool list. Go through every tool the server exposes, with its parameters and descriptions. Separate tools that read from tools that write, send, delete or execute. A server with a harmless-sounding name can still expose a shell tool.
2. Read tool descriptions as if they were instructions. The model reads them, so a description can steer it. Text telling the model to read other files, ignore earlier instructions or call other tools is a red flag.
3. Check provenance. Who publishes it, is the source available, is it maintained, and does the package you install match the repository? Prefer servers from the vendor whose API they wrap, or from a maintainer with a visible history.
4. Check how it runs. Is it a local process your client launches, or a remote URL? What does it install? Does it pull code at startup?
5. Check authentication and scope. What credential does it need, and can you issue one with read-only or narrowly scoped access?
6. Try it on a sample. Point it at a test directory, a sandbox account or a throwaway repository, watch what it touches, and read the transcript of what the agent did with it.

Roll it out safely

Connecting a server should not, on its own, mean every task can use it. A rollout that keeps authority narrow:

• Start read-only. Enable the reading tools first and add writing tools once you have seen the server behave on real work. Start agents read-only argues for this order.
• Scope per project. Configure servers in the project that needs them rather than globally, and limit filesystem servers to specific directories.
• Keep confirmations on. Most coding and desktop agents can ask before running a tool. Leave that switched on for anything that changes state.
• Pin versions. Use a fixed version rather than the latest tag, and review changes before upgrading.
• Use dedicated credentials. Give each server its own low-privilege token, so you can revoke it without breaking anything else.
• Prune. Every connected server adds tool descriptions to the model's context and adds surface area. Remove what you no longer use.

A sample rule for a team's agent policy: "A new MCP server is enabled in one project, with read tools only, for one week. Write tools are added after someone has reviewed the transcripts of real use." The thinking behind it is set out in connect tools without widening authority.

MCP servers for Pi and other minimal agents

Not every coding agent treats MCP as a built-in feature. Pi, the minimal terminal coding agent, is built around a small core plus command-line tools and skills, and leaves MCP to extensions rather than building it in. Check Pi's current documentation for how MCP can be added. The evaluation above applies unchanged, with one addition: the adapter that connects MCP to the agent is code you run too, so review it the same way.

For many needs in a minimal agent, a CLI with a short skill file does the same job with less machinery. A git or GitHub command-line tool, a database client or a documentation fetcher can often replace a server outright. MCP, skills or CLI tools compares the approaches, and the Pi integration design guide covers keeping that setup reviewable.

Where GoCux fits

GoCux follows the same rules in its own MCP integration. It offers no hosted MCP endpoint of its own; the tools execute inside a compatible client on your machine, so the server process and its permissions stay on your side. The recommended start is read-only, and setting up a server does not by itself let every task use it: a work order still states the scope it may touch, and consequential actions such as sending data out or exporting files wait for a person to decide. The MCP quickstart walks through the setup.

Checklist before you connect a server

• You know which kind of free it is: self-hosted, a wrapper around a service's free tier, or a hosted endpoint.
• You know where tool inputs go, who logs them and for how long.
• You read every tool and its description, and separated read tools from write, send, delete and execute tools.
• The publisher is identifiable, and the installed package matches the source.
• Credentials are dedicated and as narrow as the work allows.
• It ran against sample data first, and you read what the agent did with it.
• It is enabled read-only, in one project, with confirmations on and a pinned version.
• Someone owns the decision to add write tools, and unused servers get removed.