Claude Code doesn't use the word "plugin" anywhere in its interface, yet the concept exists and it's more powerful than most developers realize. What the documentation calls an MCP server is, functionally, your claude code plugin system, connecting Claude directly to databases, APIs, issue trackers, and development tools with minimal configuration overhead.
This tutorial cuts through the terminology and shows you exactly how the Model Context Protocol integration works inside Claude Code. You'll learn the difference between the two connection types (local stdio and remote HTTP), understand how project-level and user-level configuration scopes interact, and walk through adding a remote MCP server in under 60 seconds. Along the way, you'll see what silent failure looks like and how to avoid the configuration mistakes that cause it.
By the end, you'll know where to find production-ready MCP servers, how to keep credentials out of version control using environment variable expansion, and how to structure your configuration so the whole team benefits without sacrificing personal customization. If you've been ignoring the MCP documentation, this is the practical starting point you've been waiting for.
"Plugin" means MCP server in Claude Code
If you search "Claude Code plugin," you won't find that term in the official docs. Claude Code has no plugin system. What it has is MCP (Model Context Protocol), an open standard that connects Claude to external tools, APIs, databases, and services. Developers looking for "plugins" are almost always looking for MCP server configuration.
Understanding the distinction matters. MCP is a protocol, not a proprietary extension format. Any server that implements the MCP specification works with any compliant client. Wire a server into Claude Code today; the identical endpoint URL works in Cursor and Codex CLI without modification. That interoperability is a direct consequence of the protocol design, not a feature any single client adds.
For a deeper look at what these servers are under the hood, see What an MCP Server Actually Is and the broader architectural context in The Backbone: Model Context Protocol (MCP) Servers.
Key behaviors to internalize before configuring anything:
Tools exposed by an MCP server become available to Claude at connection time. No manual activation step, no toggle to flip.
The server provides the capability; the protocol handles discovery. Claude sees new tools automatically when the server loads.
Because MCP is a standard, evaluating a server means checking its implementation and trust posture, not which client it was "built for."
Treating MCP as a protocol rather than a plugin system changes how you search for servers, how you evaluate them, and how you build your own.
Two connection types: local stdio vs. remote HTTP
MCP servers connect to Claude Code over one of two transports: stdio or HTTP. The choice is determined by where the server runs.
Local stdio
Claude Code spawns a local server as a subprocess and communicates with it over stdin/stdout. Your .mcp.json entry specifies a command and args:
{
"mcpServers": {
"my-tool": {
"command": "node",
"args": ["./server.js"]
}
}
}
No type field is needed; stdio is the default. The process runs in your shell environment and inherits your environment variables. Use stdio for servers that need direct filesystem access or depend on locally installed binaries that aren't exposed over the network.
Remote HTTP
Remote servers accept Streamable HTTP requests. The server runs somewhere else; Claude Code reaches it by URL. Add "type": "http" to the entry:
{
"mcpServers": {
"my-tool": {
"type": "http",
"url": "https://mcp.example.com/my-tool"
}
}
}
The protocol semantics are identical across both transports. The transport only defines how messages are framed and delivered, not what they mean.
When to use each
Scenario | Transport |
|---|---|
Tool needs local filesystem | stdio |
Tool runs only on your machine | stdio |
Shared server, multiple teammates | HTTP |
Same tools across multiple machines | HTTP |
Remote HTTP removes the reinstall requirement entirely. Paste the same URL into .mcp.json on any machine and the tools are immediately available. For a concrete working example before writing your own server, see the guide on wiring an image MCP server into Claude Desktop or Cursor, which walks through the same type: http pattern against a live endpoint.
Two configuration scopes: project vs. user
Where you put a config entry determines who can use it and whether it belongs in version control.
Project scope lives in .mcp.json at your repo root. Commit that file and every developer who clones the repo gets the same server entries automatically. This is the right place for shared infrastructure: linters, issue trackers, APIs the whole team calls.
User scope lives in ~/.claude.json. It is never committed and applies across every project on your machine. Put personal tools, private endpoints, and anything requiring credentials only you hold in this file.
Claude Code loads both files simultaneously at connection time. Tools from each scope are available together; there is no priority conflict as long as server names are distinct across the two files.
Keeping credentials out of version control
.mcp.json supports ${VARIABLE_NAME} expansion anywhere in its values. Claude Code resolves each variable from your shell environment at runtime, so the config file stays committable while secrets stay out of the repo.
A practical header auth entry looks like this:
{
"mcpServers": {
"my-api": {
"type": "http",
"url": "https://api.example.com",
"headers": {
"Authorization": "Bearer ${MY_API_TOKEN}"
}
}
}
}
MY_API_TOKEN resolves from the environment when Claude Code connects. Teammates clone the same file, set the variable in their own shell, and connect without ever seeing your token.
One important scoping rule: if only you have credentials for a server, put it in ~/.claude.json, not .mcp.json. Teammates who clone the repo and lack the matching environment variable will see the server entry, fail to connect, and have no obvious reason why.
Adding a remote MCP server in under 60 seconds
With your config scope decided, the next step is putting an actual server into .mcp.json and confirming it loads.
Step 1: Pick an endpoint. You need a Streamable HTTP URL. For a zero-configuration test, Moltline Studio's 22 hosted servers, 110 free tools work with no account and no API key. Each server lives at mcp.moltlinestudio.com/<server>. The files server, for example, is at:
https://mcp.moltlinestudio.com/files
Step 2: Add the entry to .mcp.json.
{
"mcpServers": {
"moltline-files": {
"type": "http",
"url": "https://mcp.moltlinestudio.com/files"
}
}
}
That is the complete entry. No headers, no credentials, no extra fields required for the free tier.
Step 3: Reload Claude Code. Claude Code reads .mcp.json at startup and connects to each server. Tools are discovered at connection time. No manual activation, no restart of a local process, no install step.
Step 4: Confirm it loaded. Ask Claude to list available tools, or check the MCP status indicator in the Claude Code UI. You should see the server name and its tool list within a few seconds. If the server name appears but shows zero tools, check the next section on silent skipping.
Moltline exposes 160 tools total across databases, file utilities, and developer APIs. The 110 free tools cover a wide range; the remaining 50 unlock with a single $19/month All-Access license.
The identical type: http entry with the same URL works in Cursor and Codex CLI. All three clients implement the same MCP protocol, so one endpoint serves all of them without modification.
What can go wrong: silent skipping and common mistakes
If a server loads cleanly, tools appear automatically. If it doesn't, Claude Code won't tell you loudly. It silently skips the failed server and continues, so the symptom is usually missing tools with no obvious crash. Check the MCP log output for the specific server name and error message; that entry is the only signal you get.
Four mistakes cause most of these silent failures:
Missing type: http for remote servers. If you omit it, Claude Code treats the entry as a stdio server and tries to execute the URL as a shell command. That fails silently. Every remote entry needs "type": "http" explicitly set.
Unset environment variables. If ${MY_API_TOKEN} is referenced in .mcp.json but not exported in the shell where Claude Code launches, the value expands to an empty string. Authentication fails without a clear error pointing to the cause. Confirm each variable is set in the same shell session, not just in your .bashrc or a separate terminal.
Credentials committed directly to .mcp.json. Hardcoding a token or key in the file and committing it exposes the credential to everyone with repo access. Use ${VARIABLE_NAME} syntax instead. The config file stays committable; the secret stays out of version control.
Using project scope for a server only you can authenticate. When a server entry lives in .mcp.json, teammates clone it too. If the required credentials exist only on your machine, their Claude Code will find the entry, attempt to connect, and fail. Move personal-only servers to user scope in ~/.claude.json. Use project scope only for servers the whole team can reach.
If you're unsure whether a server is loading or what it exposes, the Moltline server list shows each endpoint and its available tools, which makes it easier to cross-check what Claude Code should be seeing after a successful connection.
Where to find MCP servers to add
Once you have the configuration patterns down, the next question is what servers are actually available to wire up.
Official MCP registry
The official MCP registry on GitHub is the first place to check. It lists servers published by named maintainers. GitHub Copilot ships an official remote MCP server there, as does Atlassian for Jira. Both follow the type: http pattern and work directly in Claude Code.
Moltline Studio hosted servers
Moltline Studio hosts 22 MCP servers exposing 160 tools, all with direct Streamable HTTP endpoints at mcp.moltlinestudio.com/<server>. One hundred ten of those tools are free forever, no account, no API key, no signup required. Paste an endpoint into .mcp.json and the tools are available at connection time.
The remaining 50 tools unlock with a single $19/month All-Access licence, payable in cryptocurrency. The /api endpoint serves a live HTTP 402 x402 challenge, so an agent can discover the price and settle on-chain without a human in the loop. Where this came from gives more background on the protocol decisions behind that design.
Moltline also publishes 138 SKILL.md agent skills as open source at GarphenGate/moltline-oss on GitHub. The repo includes a SKILL.md linter and a free agent-readiness checker for auditing your setup before wiring servers into production.
Building your own
If no existing server fits your use case, the MCP specification at modelcontextprotocol.io documents everything needed to build and host a compliant server, including the tools, resources, and prompts interfaces, plus authorization requirements.
Next steps
Once you have a server wired in, a few practices will save time as your setup grows.
For team environments: commit .mcp.json to the repo and inject secrets as CI environment variables. Every developer and every CI run gets the same server configuration, and no credentials touch version control. A new teammate clones the repo, sets the required environment variables, and the full tool set is available immediately.
For autonomous agent development: if your agents need to discover and pay for tools without human intervention, mcp.moltlinestudio.com/api serves a live HTTP 402 x402 challenge. An agent can read the price header and settle on-chain, completing the access flow with no manual step. The Implementation Roadmap: Deploying Your Managed MCP Server covers the production side of that pattern in detail.
Before wiring new servers into production: run Moltline's free agent-readiness checker against your project. It surfaces configuration issues before they become silent failures in a live environment.
To deepen your understanding of integration patterns: the MCP certification curriculum covers server integration as Domain 2, Task 2.4 in both the Professional and Developer tracks. It is the most structured way to move from ad-hoc configuration to deliberate architecture.
Concrete starting checklist:
Pick one server from the MCP registry or from
mcp.moltlinestudio.comAdd it to
.mcp.jsonwithtype: httpand the endpoint URLUse
${VARIABLE_NAME}expansion for any credentialsReload Claude Code and confirm the server appears in the tool list
Move any personal-only servers to user scope so the project config stays clean and shareable
Conclusion
MCP servers transform Claude Code from a capable assistant into a genuinely extensible platform. The core concepts are straightforward: choose your connection type (stdio or HTTP), set the right configuration scope (project or user), and keep credentials out of version control using environment variable expansion. Silent failures are avoidable once you know what causes them.
The checklist above gives you everything needed to add your first server in under a minute. From there, the jump to autonomous agent workflows, where tools are discovered and paid for programmatically, is closer than it looks.
Start small. Pick one server from the MCP registry, wire it into .mcp.json, and verify it appears in your tool list. That single successful integration builds the intuition needed to architect something much more powerful. The infrastructure is ready; the next move is yours.