The scariest sentence I heard about MCP servers was "any tool you expose, an AI can call." That is true and it is fine, as long as you treat your tools like the small, powerful buttons they are. Nothing about MCP makes security fundamentally harder; you just have new places to be careless. Here are the habits that actually keep an MCP server safe, in plain terms.
Secrets Go in Env, Not in Code
The number one leak is an API key written directly into a config file that ends up on GitHub. MCP servers read configuration for command, args, and env. Put secrets in env or a git-ignored local file, never inside the source. The config guide shows that env block, and that is exactly where variables belong, referenced by name rather than written out.
Validate Every Argument
Because an AI builds the arguments it sends you, treat every input as untrusted. Check that an IP is actually an IP before you pass it to a database, that a number is in range, and that a string is not a path trick. Your inputSchema declares the shape, but you must enforce it in code. This is the same discipline as checking any external input, and it is covered well in material on building your own server.
Scope Tools to Least Privilege
Do not expose a delete-everything tool unless you really mean it. Give each tool the smallest capability it needs and think about what a single stray call could do. If a tool can reach a paid API, consider a rate limit or a budget, because a looping assistant can burn through quota faster than a human ever would. Keep that in mind when reading what a tools list exposes.
Be Careful What You Attach
When you connect a server to an assistant like Claude or Cursor, you are connecting a very capable program to your local machine or account. Prefer sandboxed environments and grant access only to the directories or services the tool truly needs. If a tool should only read, do not give it write access. This boundary thinking is the same principle behind a broader security self-audit, applied to your MCP setup.
Watch the Remote Trend
Remote MCP over HTTP and SSE is convenient, but it moves your tools onto a network endpoint. That means authentication matters, not just for your account but between the client and the server. A public tools catalog like the one at /mcp-tools.json is fine to expose read-only, but calls that change data or reach paid APIs should sit behind a key. The transport guide explains which pipe you are using and therefore what you need to protect.
The Rule That Ties It Together
If you remember one thing: assume anyone-including an AI-could call your tools, and build accordingly. Keep secrets out of code, validate inputs, scope permissions, and protect remote endpoints. That handful of habits prevents the vast majority of real incidents. When something still fails, the troubleshooting checklist will get you back up, and the IPIPAI blog keeps rounding out the rest.