Using MCP Servers: Plug Tools Into Your Assistant

MCP servers transform any AI assistant from a chatbot into an orchestrator of real-world tools: files, calendars, music systems. You find, install, and securely configure these servers with a few lines of JSON (JavaScript Object Notation), connecting them to your assistant via stdio or HTTP. Once connected they immediately expose discoverable capabilities the LLM (large language model) can use.

The surprising part? The assistant never talks to the server directly. Every interaction passes through a host-enforced permission layer that prevents the model from grabbing your entire filesystem or posting to your API (application programming interface) without your consent.

How do you find MCP servers for your assistant?

You find MCP servers in the official model context protocol repository, on npm, and from community registries. For the personal assistant we are building in this series, files, calendar, music, smart home, several battle-tested servers already exist.

Start at the MCP examples directory which lists official reference servers. There you will see the server-filesystem for local file access, server-brave-search for web queries, and others. The npm registry surfaces hundreds more. A search for mcp-server returns servers wrapping Google Calendar, Spotify, Home Assistant, Jira, and databases. Community directories like glama.ai/mcp/servers help you browse by category and verify maintenance status.

For our assistant we need four domains. The official @modelcontextprotocol/server-filesystem handles documents. For calendar we pick mcp-server-google-calendar because it uses OAuth and runs locally. Music comes from mcp-server-spotify, built on the Spotify Web API. Smart home we hand to mcp-server-home-assistant, which talks to Home Assistant’s RESTful interface. Every server lives in a separate process with a narrow, auditable surface area.

Once you have identified the servers you want, the next step is to tell your assistant about them.

How do you install and configure an MCP server?

MCP servers are external processes. You do not install them inside your assistant. You configure the assistant, Claude Desktop, VS Code, or a custom host, with a JSON snippet that tells it how to launch or reach each server. The host then spawns the process or connects over HTTP and handles the entire MCP protocol under the hood.

Configuration lives in a text file and follows a simple schema. For Claude Desktop on macOS the file is ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows it is %APPDATA%\Claude\claude_desktop_config.json. The schema expects a mcpServers object where each key names the server and specifies either a command and args for stdio or a url for HTTP.

Here is how you plug in the four servers for our assistant. First, the filesystem server. It runs locally via npx and allows read-write access to specific directories. The entry looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/alice/Documents",
        "/Users/alice/Desktop"
      ]
    }
  }
}

The calendar server needs OAuth tokens. You store them as environment variables so they never appear in config files.

"google-calendar": {
  "command": "npx",
  "args": ["-y", "mcp-server-google-calendar"],
  "env": {
    "GOOGLE_CLIENT_ID": "your-client-id",
    "GOOGLE_CLIENT_SECRET": "your-client-secret",
    "GOOGLE_REFRESH_TOKEN": "your-refresh-token"
  }
}

The music server follows the same pattern with a Spotify access token.

"spotify": {
  "command": "npx",
  "args": ["-y", "mcp-server-spotify"],
  "env": {
    "SPOTIFY_CLIENT_ID": "...",
    "SPOTIFY_CLIENT_SECRET": "...",
    "SPOTIFY_REFRESH_TOKEN": "..."
  }
}

For smart home, Home Assistant runs inside your network. The server connects over WebSocket. You expose the URL and a long-lived access token.

"home-assistant": {
  "command": "npx",
  "args": ["-y", "mcp-server-home-assistant"],
  "env": {
    "HA_URL": "http://homeassistant.local:8123",
    "HA_TOKEN": "your-long-lived-token"
  }
}

VS Code uses a similar JSON structure inside .vscode/mcp.json. It also supports remote servers with HTTP transport by setting "type": "streamable-http" and providing a url.

After adding these blocks you restart the application. The assistant will load the configuration, spawn each server, negotiate capabilities, and surface tools, resources, and prompts automatically. You never write wiring code.

But configuration is only as safe as the boundaries you set. Next we need to talk about those boundaries.

How does MCP keep your tools safe?

MCP does not trust the LLM with direct access to anything. Every tool call, resource read, and prompt execution goes through the host, which enforces permissions and can demand explicit user consent. The protocol’s control hierarchy locks the model into a tightly constrained role.

When you use stdio transport the server runs as a child process of the assistant. It inherits the same operating system permissions as your user account, but the host can further restrict it. The filesystem server only sees directories you list in the arguments. The assistant itself can ask for confirmation before the first file write or before sending a Google Calendar invitation. This consent gate is a host feature, Claude Desktop shows a permission dialog, for example, and it stops the model from acting autonomously on sensitive operations.

Environment variables let you supply API tokens without ever exposing them to the LLM. The model sees the tool description and schema. It never sees the environment values. The host injects tokens only when making the JSON-RPC call to the server. Similarly, the sampling capability lets a server request an LLM completion through the host, but the host still controls the model key, applies policy filters, and reviews the result before returning it to the server.

For remote HTTP servers the host must verify the endpoint. You should always use TLS and pin certificates if possible. Some hosts support authentication headers so the server can validate the client, preventing unauthorized hosts from connecting. The server itself never receives the user’s model API key.

Resources add another layer: the host decides which resource URIs get fed into the model context. You can, for instance, let the assistant read log files but not the configuration files that contain secrets.

With these guarantees in place you can confidently pick servers for each pillar of our assistant.

Which servers should you pick for files, calendar, music, and smart home?

A handful of projects have become the de facto standard implementations because they are maintained, well-documented, and safe for daily use. Here are the four we use in this series.

The filesystem server is the official @modelcontextprotocol/server-filesystem. It is maintained in the MCP servers repository. Install it with npx -y @modelcontextprotocol/server-filesystem <allowed directories>. It exposes tools like read_file, write_file, list_directory, and search_files. The allowed directories are absolute paths. Any path outside those roots causes an error. This server is your assistant’s eyes and hands for local documents and workspace management.

For calendar access, mcp-server-google-calendar wraps the Google Calendar API. It adds tools to list events, create meetings, and check busy times. You must create a Google Cloud project, enable the Calendar API, and generate an OAuth refresh token. The server stores no data. It makes REST calls on your behalf and respects the permissions of the authenticated user.

Music control comes from mcp-server-spotify. It translates natural language into Spotify playback commands: play an artist, queue an album, adjust volume. The server uses the Spotify Web API and requires an app registration in the Spotify Developer Dashboard. Because it executes playback actions, you should consider adding an explicit consent gate in the host for music-related tool calls.

The smart home pillar relies on mcp-server-home-assistant. Home Assistant provides a REST API for devices, scenes, and automations. This server exposes tools to turn lights on or off, read sensor values, and trigger scripts. It connects over your local network, so all traffic stays private. Pair it with a dedicated Home Assistant user and a limited-scope long-lived token to avoid exposing full-home control.

Each of these servers follows a pattern: a small, focused process, powered by well-understood APIs, running mostly on your own machine. Together they give your assistant real-world reach while the host enforces safety boundaries at every step.

Quick Reference

Frequently Asked Questions

Q: Can I use MCP servers with a local LLM running on Ollama or llama.cpp? Yes, as long as your host implements MCP and supports function calling. Projects like Continue.dev and LM Studio already bridge MCP to local models. The assistant must be able to translate model-generated tool calls into the tools/call JSON-RPC request, but the protocol does not care which model is behind it.

Q: How do I know a community MCP server is safe to run? Read its source code. Check what commands it runs and what data it sends over the network. Run it in a sandbox with restricted directory access and network controls. Use an allowlist of directories in the config. Avoid servers that demand broad filesystem access or that transmit data to unknown endpoints. If the repository has a lot of stars and recent commits, that is a positive signal.

Q: What happens if a server crashes during a tool call? The JSON-RPC session returns an error response to the client. The host then surfaces a user-friendly message, and the assistant can normally recover by suggesting an alternative action. For long-running servers, consider running them under a process manager so they restart automatically.

Q: Can I share one MCP server between multiple assistants on the same machine? For stdio servers, each process handles one client at a time. You would need to launch separate instances for each assistant, possibly with different allowed directories. With an HTTP server you could accept multiple concurrent connections, but you should design the server to handle that safely.

Q: Do I need to restart my assistant after adding a new server to the config? Most desktop hosts read the configuration at startup. You must restart the application. Some tools like Claude Code or VS Code extensions may support hot-reload in the future, but as of mid-2026 a restart is the standard path.

Test yourself

Scenario: You added the filesystem server with "args": ["/Users/alice/Documents"] but the assistant reports it cannot access /Users/alice/Documents/Projects/summary.txt. You have verified the file exists. What is the most likely cause?

Answer: The filesystem server restricts file access to the exact directory trees listed in its arguments. The argument /Users/alice/Documents is a single path. The server should allow any file or directory under that root. However, the tool call might have used a relative path or a symlink that resolves outside the allowed tree. More commonly, the server’s argument is passed as a separate element in the array, like "-d", "/Users/alice/Documents", not as a bare path. If you omitted the -d flag or accidentally used two separate arguments, the server might interpret the path differently or reject it. Always check the server’s README for the exact argument syntax. In this case, the correct form would be "args": ["-d", "/Users/alice/Documents"]. Once corrected and after a restart, the assistant can see the Projects folder without issues.

If you want this kind of breakdown every week, how to safely wire real tools into AI assistants instead of just playing with demos, subscribe to Internals Decoded at internalsdecoded.com.

Sources

• MCP Introduction
• MCP Servers Repository
• Claude Desktop MCP Setup
• MCP examples directory
• glama.ai/mcp/servers
• internalsdecoded.com