How to Set Up MCP Servers for a Coding Agent

Quick answer
An MCP server is a small process or service that exposes tools, resources, and prompts to an AI client over a defined protocol. Setup is mostly configuration.
The two common transports are stdio, where the client launches the server as a child process, and HTTP-based transports, where the server runs independently and the client connects to a URL.
Configuration lives in a JSON or TOML file that names each server, its command or URL, and its environment variables.
Pass credentials through environment variables or a secrets manager, never inline in the config file, because that file is frequently committed by accident.
Verify by asking the agent to list its tools. If a server does not appear, the process failed to start — check its stderr output first.

What are you actually setting up?

Model Context Protocol defines how an AI client discovers and calls capabilities provided by an external program. A server exposes three kinds of thing: tools, which the model can invoke with arguments; resources, which the model can read, such as a file or a record; and prompts, which are reusable templates. Your agent is the client. Adding a server means telling the client how to start or reach it, and then the agent can use its tools alongside its built-in ones.

The value is reach. A server turns a system the agent otherwise cannot touch — your issue tracker, your database, a design tool, your cloud account — into a set of callable operations. The risk is the same surface viewed from the other side: you are granting an automated process access to systems with real data, and it will use that access with the same confidence it uses everything else.

Step 1 — choose a transport and install or locate the server

Two transport styles cover almost everything. With stdio, the client starts the server as a child process and talks over standard input and output; there is nothing to run separately, credentials are inherited from the environment, and the server lives only as long as the session. With an HTTP transport, the server runs as its own service — often in a container — and the client connects to a URL; this suits shared servers and remote systems, and adds authentication as something you must get right.

Prefer stdio for local tooling and HTTP for anything shared or remote. For a published server, the simplest route is usually to run it with a package runner rather than installing it globally, so the version is pinned in configuration and the machine stays clean. For your own server, start it in a terminal and confirm it responds before wiring it into the agent, because debugging two things at once is the slow path.

Step 2 — write the configuration

The shape is a named entry per server with either a command and arguments (stdio) or a URL (HTTP), plus an environment block. The example below uses the widely copied mcpServers shape; some clients use TOML or their own file, so match the tool’s documentation. Note that the token is referenced, not embedded — that is the single most important habit in this step.

Scope matters too. A server configured globally is available in every project on the machine, which is convenient and broad. Where your client supports project-scoped configuration, put project-specific servers in the repository or a local untracked file, so cloning someone else’s project does not silently grant access to production systems.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres-readonly": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${READONLY_DATABASE_URL}" }
    },
    "internal-docs": {
      "url": "https://mcp.internal.example.com/sse",
      "headers": { "Authorization": "Bearer ${MCP_INTERNAL_TOKEN}" }
    }
  }
}

Step 3 — pass secrets safely and verify the tools appear

Keep credentials out of the configuration file. Use environment variable references or placeholders that the client resolves at launch, put the real values in your shell environment or a secret manager, and add the local config file to .gitignore. A committed MCP config with a database URL or an access token is a credential leak in the same category as a committed .env, and it is becoming a common one.

Then confirm the server is live. In a new agent session, ask it to list the tools it has available and check that the server’s tools are present. If they are not, the process failed to start: run the same command manually and read the error, which is usually an unresolvable package, a bad path, or an unset variable. Once the tools appear, test the least destructive one to prove the credentials work before trusting it with anything that writes.

Step 4 — narrow what the server can do

Having it working is not the same as having it safe. Give each server the minimum access its job needs: a read-only database user rather than the application’s owner account, a token scoped to specific repositories rather than full account access, and an API key limited to the endpoints you actually use. Where the server supports a read-only mode or an allow-list, enable it and leave it on.

It is also worth knowing that a server’s tool descriptions are instructions the model reads, so they are part of your prompt surface. That is why a server you did not write deserves the same scepticism as a package you installed: check who maintains it, what it can reach, and whether the credential you gave it is broader than the task. The dedicated security treatment is in the linked guide.

Where this bites vibecoders
Setting up an MCP server from a README is the kind of task an assistant does well, including writing the config block — which is precisely why the credential handling gets skipped. The published example often shows an inline token because it is shorter, and that block gets pasted into a file in the repository. Ask explicitly for the token to come from an environment variable and for the config file to be gitignored; those two sentences prevent a class of leak that is otherwise discovered by a scanner.

Where AI coding assistants get this wrong

Embedding tokens or connection strings directly in the MCP configuration file.
Using a full-privilege database account for a server that only needs to read.
Committing a local MCP config that contains credentials.
Configuring the same server globally and project-specifically, causing duplicate or conflicting tools.
Assuming a failed server will surface an obvious error rather than silently not appearing.
Granting a third-party server broad account access instead of a scoped token.

Checklist

Decide stdio or HTTP for each server before writing config.
Pin versions and avoid global installs where the client supports it.
Reference secrets from the environment; never inline them.
Add any local config file to .gitignore.
Ask the agent to list tools and confirm each server appears.
Test the least dangerous tool first to validate credentials.
Scope every credential to the minimum the server needs.

FAQ

What is the difference between stdio and HTTP MCP servers?

A stdio server is started by the client as a subprocess and communicates over standard input and output, which is simple and local. An HTTP server is a separate long-running service the client connects to, which suits shared and remote deployments but requires authentication and its own operations. Most local tooling uses stdio; team-wide or hosted integrations use HTTP.

Where do I put MCP credentials?

In environment variables or a secret manager, referenced from the configuration rather than written into it. The config file is frequently committed by accident, so treat it as public. Scope the credential itself narrowly as well: a read-only account for a read-only server, and a token limited to the resources in question.

My MCP server is not showing up. What should I check?

Run the server’s command manually and read the error — usually a missing package, a wrong path, or an unset environment variable. Then confirm your config file is in the location that client reads, and restart the session, since servers are typically discovered at startup. Silence from a server almost always means the process exited immediately.

Can an MCP server be dangerous?

Yes. It gives a model-callable interface to a real system, so a broad credential or a write-capable tool can cause real changes at the speed the agent works. Treat a server as a privileged integration: minimum scopes, prefer read-only where possible, and be more cautious with servers you did not write, whose tool descriptions are also text the model will trust.