Using MCP Servers with Claude Code: Configuration, Workflows, and Security Best Practices

Claude Code extends its reasoning capabilities by integrating with MCP (Model Context Protocol) servers, enabling live access to external tools like GitHub, databases, and Slack through HTTP, stdio, or WebSocket transports.

The luongnv89/claude-howto repository provides a complete reference implementation for using MCP servers with Claude Code, documenting the protocol architecture, configuration patterns, and security practices in 05-mcp/README.md. This integration allows the AI assistant to fetch real-time data and execute actions beyond static memory, transforming Claude Code into a dynamic interface for complex automation workflows.

MCP Architecture and Core Components

Understanding the MCP architecture is essential for configuring reliable integrations. The protocol defines a clear separation between the client, server, and transport mechanisms.

Component Overview

The MCP ecosystem consists of four primary components working in concert:

• Claude Code (client) – The interactive CLI that parses slash commands, builds JSON request payloads, and streams responses back to the user. This serves as the entry point for any /mcp command, as implemented in the main CLI logic referenced in 05-mcp/README.md.

• MCP Server – A lightweight process running over HTTP, stdio, SSE, or WebSocket that implements the MCP specification. The server receives JSON requests, calls external APIs (such as GitHub or databases), and returns structured JSON results.

• Transport Layer – Determines the communication channel between Claude Code and the server. Claude selects the transport based on the type field defined in the server configuration (lines 75-88 in the README).

• Tool Discovery – Upon startup, each server advertises its available tools to Claude Code. For extensive tool catalogs, Claude supports auto-tool-search functionality to efficiently locate specific capabilities (lines 203-212).

Request Flow Sequence

A typical MCP interaction follows this precise flow:

User → Claude CLI: /mcp__github__list_prs
Claude CLI → MCP Server (HTTP/stdio): {"tool":"list_prs","args":{}}
MCP Server → External API (GitHub): GET /repos/.../pulls
External API → MCP Server → Claude CLI: {"result":[...]}
Claude CLI → User: formatted list of PRs

This sequence is visualized in the architecture diagram within 05-mcp/README.md (lines 84-100), demonstrating how credentials and data flow securely between layers.

Configuring MCP Servers in Claude Code

Configuration management supports multiple scopes, allowing both personal preferences and team-wide standards to coexist without conflict.

Configuration Scopes

Claude Code supports three distinct configuration scopes for MCP servers:

• User scope (~/.claude.json) – Global settings applied across all projects for your user account.
• Project scope (.mcp.json) – Repository-specific configurations that team members share via version control.
• Local scope (~/.claude.json overrides) – Personal overrides that take precedence without modifying shared project files.

This scoping mechanism enables teams to define standard servers in .mcp.json while allowing developers to override endpoints or credentials locally (lines 58-66).

Transport Layer Options

The type field in your configuration determines how Claude Code communicates with the server:

• HTTP – Recommended for remote APIs and cloud services; supports standard headers and authentication.
• stdio – Used for local executables and command-line tools; spawns the server as a subprocess.
• SSE (Server-Sent Events) – Enables real-time streaming updates from server to client.
• WebSocket – Provides bidirectional communication for interactive tools requiring persistent connections.

Security and Credential Management

Security is implemented through environment variable injection and OS-level secret storage. According to the "Environment Variables" and "Do's/Don'ts" sections (lines 94-101 and 44-58), you must:

• Store tokens in environment variables (e.g., ${GITHUB_TOKEN}) rather than hardcoding them in JSON files.
• Ensure the runtime never logs secrets to console or disk.
• Rely on the OS keychain for persistent token storage when available.

Practical Implementation Examples

The repository provides concrete configuration files and commands for common integrations.

Adding a GitHub MCP Server via CLI

For quick testing or one-off configurations, use the CLI command:

claude mcp add --transport http github https://api.github.com/mcp

This corresponds to the HTTP Transport example in 05-mcp/README.md (lines 77-84) and creates a minimal configuration pointing to GitHub's MCP endpoint.

Project-Level Configuration Files

Create a .mcp.json file in your repository root to share server definitions with your team. The 05-mcp/github-mcp.json example demonstrates HTTP transport with header authentication:

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.github.com/mcp",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    }
  }
}

Similar examples exist for filesystem access (filesystem-mcp.json using stdio) and database connections (database-mcp.json), while multi-mcp.json demonstrates orchestrating multiple servers in a single project.

Executing MCP Commands

Once configured, invoke tools using the slash-command syntax /mcp__server__tool:

User: Show me all open PRs created in the last 7 days.

Claude: /mcp__github__list_prs created:>2024-03-23 state:open

This format is documented in the "MCP Prompts as Slash Commands" section (lines 28-36), providing a consistent interface regardless of the underlying transport protocol.

Multi-MCP Workflow Orchestration

Complex automation tasks can chain multiple MCP servers in a single interaction sequence. The following daily report workflow combines GitHub, database, filesystem, and Slack servers (lines 68-84):

# Step 1 – GitHub statistics

/mcp__github__list_prs completed:true last:7days

# Step 2 – Database sales query

SELECT COUNT(*) AS sales, SUM(amount) AS revenue
FROM orders
WHERE created_at > NOW() - INTERVAL '1 day';

# Step 3 – Save report to filesystem

/mcp__filesystem__write_file /reports/daily.html "<html>…</html>"

# Step 4 – Post to Slack

/mcp__slack__send_message "#daily-reports" "Daily report generated ✅"

This pattern, demonstrated in 05-mcp/README.md and utilized in scripts/build_epub.py, shows how MCP servers enable end-to-end automation without leaving the Claude Code interface.

MCP vs. Memory: Selecting the Right Approach

Claude Code provides two distinct mechanisms for data access, each suited to different scenarios:

• Memory stores static, user-specific data that persists across sessions but never changes automatically (preferences, conversation history, coding standards).
• MCP fetches live, external data on demand (open pull requests, real-time sales figures, current system status).

The decision matrix in 05-mcp/README.md (lines 555-564) recommends MCP for any data requiring real-time accuracy or external system interaction, while Memory remains optimal for stable personal context and preferences.

Summary

• MCP servers extend Claude Code with live tool access via HTTP, stdio, SSE, or WebSocket transports, defined in 05-mcp/README.md.
• Configuration scopes (User, Project, Local) allow flexible credential management through .mcp.json and ~/.claude.json files.
• Security depends on environment variable substitution (e.g., ${GITHUB_TOKEN}) and OS keychain storage, never logging secrets to output.
• Slash commands follow the /mcp__server__tool syntax for consistent invocation across different server types.
• Multi-server workflows enable complex automation by chaining GitHub, database, filesystem, and Slack operations in single sessions.
• Tool discovery supports auto-search for large tool catalogs, while the transport layer adapts to local executables or remote APIs.

Frequently Asked Questions

How do I securely store API tokens when using MCP servers with Claude Code?

Store sensitive tokens as environment variables on your system (e.g., export GITHUB_TOKEN="ghp_..."), then reference them in your .mcp.json configuration using the ${VARIABLE_NAME} syntax. According to the source code analysis, Claude Code's runtime never logs these secrets and integrates with the OS keychain for persistent storage, ensuring credentials remain protected outside of configuration files.

What is the difference between stdio and HTTP transport for MCP servers?

stdio transport spawns the MCP server as a local subprocess, making it ideal for command-line tools and local filesystem access as shown in filesystem-mcp.json. HTTP transport connects to remote endpoints over the network, supporting standard headers and authentication for cloud services like GitHub. The transport selection depends on whether your tool runs locally or remotely, configured via the type field in your server definition.

Can I use multiple MCP servers simultaneously in Claude Code?

Yes, Claude Code supports multi-MCP orchestration, allowing you to invoke tools from different servers in a single workflow sequence. The 05-mcp/multi-mcp.json example demonstrates defining several servers in one project, while the daily report workflow shows practical chaining of GitHub, database, filesystem, and Slack servers to generate and distribute reports without switching contexts.

Where does MCP configuration live in the luongnv89/claude-howto repository?

The primary documentation resides in 05-mcp/README.md, with working examples located in 05-mcp/github-mcp.json, 05-mcp/filesystem-mcp.json, 05-mcp/database-mcp.json, and 05-mcp/multi-mcp.json. For advanced integration patterns combining MCP with hooks, refer to 06-hooks/README.md, and see scripts/build_epub.py for a real-world implementation that gathers documentation using MCP-enabled commands.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}