Tutorial
Claude Code MCP Server Setup Guide
Developers who want Claude Code to call external tools, repositories, browser helpers, or internal services without giving every project the same broad permissions.
Tutorials
Claude Code MCP Server Setup Guide
A practical setup guide for connecting local stdio and remote HTTP MCP servers to Claude Code with clear scopes, authentication, and verification steps.
Best For
Developers who want Claude Code to call external tools, repositories, browser helpers, or internal services without giving every project the same broad permissions.
Page Type
Tutorials
Attributes
Claude Code / MCP Setup / Coding Agent
How to Use
Use this workflow as a starting point, then adapt the tools, prompts, and review steps to your own process.
Overview
Claude Code can use Model Context Protocol servers to reach tools that are outside the chat session: local scripts, developer utilities, internal services, browser helpers, documentation search, repository systems, and remote APIs. The useful setup is not to install every available MCP server. The useful setup is to match each server to a clear development job and make the permission boundary visible.
A reliable Claude Code MCP configuration starts with three choices. First, decide whether the server should run locally over stdio or remotely over HTTP. Second, decide who should see it: only the current project, every project on the machine, or a shared team configuration checked into the repository. Third, decide how the server authenticates, because tokens for GitHub, databases, SaaS tools, and production systems should never be hidden inside a copied prompt.
This guide treats MCP setup as an engineering change rather than a plugin install. The goal is to create a small, testable tool surface for Claude Code, confirm that the tool appears in the MCP list, run one harmless call, and document the exact server purpose so another developer can review it later.
Use cases
- Connect a repository-aware helper so Claude Code can inspect issues, pull requests, release notes, or internal code search without pasting large blocks into the conversation.
- Expose a local script or service as a narrow stdio MCP server for repeatable tasks such as schema lookup, log parsing, dependency inventory, or project-specific command wrappers.
- Use remote HTTP MCP servers for hosted tools that already manage OAuth or token-based authentication, while keeping the Claude Code project config clean.
- Share a project-level MCP configuration with teammates when the server is safe for that repository and everyone should use the same tool names and command arguments.
Implementation steps
- Define the tool job. Write one sentence for the server purpose, such as reading project docs, querying staging logs, or opening browser diagnostics. If the purpose cannot be stated narrowly, split the idea into separate servers or wait until the workflow is better understood.
- Choose local or remote transport. Use stdio when Claude Code should launch a command on the developer machine, usually with npx, uvx, node, python, or a compiled binary. Use remote HTTP when the server is hosted, shared across devices, or needs provider-managed authentication.
- Select the scope. Use a local scope for private machine-specific tools, a project scope when the repository should carry the MCP definition, and a user scope for trusted personal utilities that should appear across multiple Claude Code sessions.
- Add the server entry. Create the MCP server entry with an explicit command, arguments, environment variables, or remote URL. Keep secrets in environment variables or the provider auth flow instead of committing tokens inside the project configuration.
- Authenticate deliberately. For remote servers, run the Claude Code MCP authentication flow and confirm the account shown in the browser is the intended account. For local servers, verify the command can start without exposing unrelated directories or credentials.
- Run a harmless verification. Ask Claude Code to list available MCP tools or perform a read-only query, then check the returned data against the source system. Save a short note that explains what the server can do and what actions still require manual approval.
Configuration steps
- Prefer remote HTTP for hosted MCP servers when the provider supports it; SSE should be treated as legacy unless a specific server still requires it.
- Keep project-level `.mcp.json` entries reviewable in code review and avoid committing personal access tokens, private paths, or machine-only assumptions.
- Name servers by job rather than vendor when multiple servers come from the same provider, for example `staging-logs` and `docs-search` instead of two vague tool names.
- Start with read-only tools when connecting production systems, then add write-capable tools only after the team has reviewed prompts, logs, and rollback behavior.
- Use Claude Code's MCP inspection command after changes so the tool list, authentication state, and transport errors are visible before real work starts.
Quick fit
| Best transport | stdio for local developer commands; HTTP for hosted or team-accessible servers. |
|---|---|
| Configuration scope | Local for one machine, project for repository-shared tools, user for trusted personal utilities. |
| Main risk | Over-broad credentials, hidden write tools, or a shared config that silently exposes machine-specific paths. |
| Success signal | Claude Code can see the server, run a read-only tool, and produce output that matches the original source. |
FAQ
Should a Claude Code MCP server be local or remote?
Use a local stdio server for machine-specific developer commands and a remote HTTP server for hosted services, shared tools, or provider-managed authentication.
Is it safe to commit `.mcp.json`?
It is safe only when the file contains reviewable server definitions and no secrets. Tokens, local private paths, and personal account details should stay outside the repository.
How do I know the setup worked?
Open Claude Code's MCP status view, confirm the server is connected, run one read-only tool call, and compare the response with the original service.
Related resources
123 results
0 saved
7 categories
123 resources
Updated index
Workflow Directory
Browse curated agents, MCP servers, templates, and workflow examples for real AI automation projects.
AI agent stack research
Find the right AI agents, MCP servers, and workflow templates
Agent Stack Library is a practical directory for people who are building real AI automation systems, not just collecting tool names. The site brings together AI agent frameworks, MCP servers, workflow templates, coding agents, browser automation tools, research workflows, and SaaS operations playbooks so you can compare an entire agent stack before committing to a toolchain.
A useful AI agent stack usually needs more than one model or one chat interface. Teams need a clear workflow, safe tool permissions, repeatable prompts, review checkpoints, and a way to measure whether the output is good enough for production. That is why the directory focuses on use cases such as AI coding agents, MCP server selection, SEO content workflows, browser QA, research assistants, internal tools, and multi-agent orchestration.
If you are evaluating MCP servers for AI agents, start with the task. A coding agent often needs GitHub access, a narrow filesystem scope, a test runner, and browser or DevTools verification. A research agent may need web search, document parsing, citation capture, memory, and a review step. A business operations agent may need CRM, email, calendar, spreadsheet, and audit logs. The best stack is the smallest one that completes the job safely.
AI agent workflow templates
Workflow templates help turn one-off prompts into repeatable systems. Each template should define the trigger, input context, agent role, connected tools, output format, human review step, and success metric. Browse the AI Agent Workflow Templates guide for SEO, coding, research, browser automation, and SaaS operations examples.
Office AI agent workflows
Office automation pages focus on concrete business tasks like Gmail email triage, daily email and calendar briefings, meeting notes to action items, meeting follow-up emails, and spreadsheet cleanup workflows.
MCP servers for AI agents
MCP servers connect agents to browsers, repositories, files, databases, memory, and business apps. Good MCP choices reduce custom integration work, but they also require clear permission boundaries. The Best MCP Servers for AI Agents guide explains how to pick a safe and useful tool stack.
AI coding agent workflow
Coding agents work best when they follow a normal engineering path: issue intake, repo context, plan, patch, tests, UI verification, pull request, and human review. The AI Coding Agent Workflow page gives a practical checklist for scoped code changes.
How to choose an agent stack
Start by deciding what the agent is allowed to do. Read-only workflows are easier to launch because the agent can gather context, summarize findings, and draft recommendations without touching production systems. Write-capable workflows need stricter guardrails: scoped credentials, test environments, logging, rollback procedures, and a human approval point before external actions.
Next, compare tools by workflow fit rather than popularity. An open-source agent framework may be perfect for a developer team that wants full control, while a managed automation platform may be better for operations teams that need quick integrations. A browser automation stack is useful for UI checks and web research, but it should not replace structured APIs when reliable APIs exist.
Finally, measure quality. Track task completion rate, review time, correction rate, cost per run, latency, and whether the output can be reused without heavy manual cleanup. A strong AI agent workflow is not the one with the most tools; it is the one that produces reliable output, exposes failures clearly, and lets humans stay in control where the risk is high.
What each directory category is for
The Agents category covers frameworks, SDKs, and agent products that help teams plan, call tools, manage memory, hand off work, or coordinate multiple specialist agents. Use this category when you are comparing LangGraph-style orchestration, coding agents, research agents, customer support agents, or open-source agent frameworks for a production project.
The MCP Tools category is focused on servers and integrations that let an AI agent interact with the outside world. These pages are useful when you need repository context, browser inspection, file access, databases, calendars, CRMs, or other business systems. Each MCP server should be judged by permission scope, reliability, setup effort, documentation quality, and how clearly failed tool calls are reported.
The Workflows and Templates categories are for readers who already know the job they want to automate. Instead of starting with a tool, start with a repeatable process: SEO content briefing, GitHub issue triage, browser QA, competitive research, sales lead enrichment, or support ticket summarization. From there, pick the smallest agent stack that can collect the right context, run the task, produce a reviewable output, and leave a log for future improvement.