Discord on Yarang's Tech Lair

MCP Integration Guide: Integrating Discord MCP with ZeroClaw Runtime

Sun, 28 Jun 2026 09:00:35 +0900

With the recent release of ZeroClaw, a high-performance Rust agent runtime, we’ve been deeply contemplating ways to maximize the efficiency of multi-agent systems. In particular, the complexity of communication protocols encountered during the design of the [Discord Decision MCP] architecture was a decisive factor in adopting MCP (Model Context Protocol) as a standard interface.

In this post, we will explain how to actually integrate Discord MCP within the ZeroClaw environment, detailing the process of agents receiving and processing Discord messages with concrete code examples.

1. Architecture Design: Dual Communication on a Single Channel

In the previous [Discord MCP] Gateway architecture, the gateway played the role of filtering events and delivering them to agents. However, by directly implementing the MCP client within ZeroClaw, we’ve altered the design to eliminate the intermediate layer and reduce latency.

The core idea is a flow where the MCP Client transmits Discord events to the ZeroClaw process via stdio, and then sends the agent’s responses back to Discord.

2. Essential Dependencies and Setup (Rust)

As ZeroClaw is written in Rust, it utilizes the asynchronous runtime tokio for high concurrency processing and serde for JSON handling. Communication with the MCP server is assumed to involve exchanging JSON-RPC messages via standard input/output (stdio).

# Cargo.toml
[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
async-trait = "0.1"

3. MCP Client Implementation

We define a simple client structure to control the Discord MCP server within ZeroClaw. This client uses the tools/call method, which adheres to the MCP standard, to execute Discord bot functionalities.

use serde::{Deserialize, Serialize};
use std::process::{Command, Stdio};
use std::io::{BufReader, BufWriter, Write};

#[derive(Debug, Serialize, Deserialize)]
struct MCPRequest {
 jsonrpc: String,
 id: u64,
 method: String,
 params: serde_json::Value,
}

#[derive(Debug, Serialize, Deserialize)]
struct MCPResponse {
 jsonrpc: String,
 id: u64,
 result: Option<serde_json::Value>,
}

pub struct DiscordMCPClient {
 id: u64,
}

impl DiscordMCPClient {
 pub fn new() -> Self {
 Self { id: 0 }
 }

 /// Executes an MCP tool to send a message to a Discord channel
 pub async fn send_message(&mut self, channel_id: &str, content: &str) -> Result<(), Box<dyn std::error::Error>> {
 self.id += 1;
 
 // Execute MCP server process (e.g., Python-based Discord MCP server)
 let mut child = Command::new("python3")
 .arg("discord_mcp_server.py")
 .stdin(Stdio::piped())
 .stdout(Stdio::piped())
 .spawn()?;

 let stdin = child.stdin.as_mut().ok("Failed to open stdin")?;
 let mut stdout = BufReader::new(child.stdout.as_mut().ok("Failed to open stdout")?);

 let request = MCPRequest {
 jsonrpc: "2.0".to_string(),
 id: self.id,
 method: "tools/call".to_string(),
 params: serde_json::json!({
 "name": "send_message",
 "arguments": {
 "channel_id": channel_id,
 "content": content
 }
 }),
 };

 // Send request
 let request_json = serde_json::to_string(&request)?;
 writeln!(stdin, "{}", request_json)?;

 // (In a real implementation, logic to parse the response from an asynchronous reader is needed)
 // Omitted here for simplicity.
 
 Ok(())
 }
}

4. Integration with ZeroClaw Agents

Now, let’s use the DiscordMCPClient created above within ZeroClaw’s agent loop. This scenario demonstrates an agent notifying Discord upon completing a specific task.

struct ZeroClawAgent {
 discord_client: DiscordMCPClient,
}

impl ZeroClawAgent {
 async fn run_task(&mut self, task: &str) {
 println!("[Agent] Starting task: {}", task);
 
 // Complex reasoning or file processing logic (omitted)
 // ...

 let result = format!("Task '{}' completed.", task);

 // Send result to Discord
 match self.discord_client.send_message("123456789", &result).await {
 Ok(_) => println!("[Agent] Successfully sent Discord notification"),
 Err(e) => eprintln!("[Agent] Sending failed: {}", e),
 }
 }
}

#[tokio::main]
async fn main() {
 let mut agent = ZeroClawAgent {
 discord_client: DiscordMCPClient::new(),
 };

 agent.run_task("Analyze server logs").await;
}

5. Efficiency and Security Considerations (Architecture Insights)

Resource Management: Similar to the trending ‘Adrafinil’ on [Hacker News], applying speculative decoding by disconnecting the Discord MCP connection when the agent is idle and only establishing it when a task is active can save resources.
Security: As highlighted in issues related to [Anonymous GitHub accounts], parameters passed to the MCP server (e.g., API tokens) should be managed via environment variables or fetched from a separate secure storage (Vault). Hardcoding secrets in code is critical.
Error Handling: As discussed in communication platform design considerations, it’s important to include retry logic in the MCP client, taking into account Discord API’s Rate Limits.

Conclusion

Integrating ZeroClaw and Discord MCP goes beyond simply creating a bot; it’s a process of building a standardized interface for agents to interact with the external world. Leveraging our experience in building [MCP] blog automation systems, we plan to further develop more sophisticated multi-agent collaboration systems.

Claude Code Discord MCP Plugin - Fixing asdf bun Path Issue

Thu, 26 Mar 2026 00:00:00 +0900

Problem

When installing the discord plugin for Discord channel integration in Claude Code CLI, I encountered the following error:

> discord Plugin · claude-plugins-official · √ enabled
 └ discord MCP · × failed

The plugin was enabled, but the MCP server was in a failed state.

Root Cause

This issue occurs when using bun installed via asdf. Claude Code CLI looks for the bun command to run the MCP server, but asdf uses shell wrappers, so the actual binary cannot be found in the system-wide path.

Solution

I resolved this by entering the absolute path to the bun installed via asdf.

Finding the Absolute Path of asdf-installed bun

which bun

Or:

asdf where bun

Example output:

/Users/yarang/.asdf/installs/bun/1.x.x/bin/bun

Applying the Configuration

Specify this absolute path as the execution path in the Discord MCP configuration, and the problem will be resolved.

Summary

Situation	Solution
System-wide installed bun	Use `bun` command
asdf-installed bun	Enter absolute path directly

When using asdf, you must specify the actual binary path, not the shell wrapper, for the MCP server to run properly.

References

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

Tue, 03 Mar 2026 15:02:49 +0900

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

This document analyzes the structure, advantages, and disadvantages of the MCP (Model Context Protocol) tools implemented in the server-monitor project. A total of 13 MCP tools are provided, categorized into 8 existing Discord MCP tools and 5 new Cloud Monitor MCP tools.

Architecture Overview
Detailed Tool Analysis
Architecture Structure
Advantages
Disadvantages and Improvements
Conclusion

Architecture Overview

FastMCP-based Architecture

graph TB
 subgraph MCP Server
 A[FastMCP Server] --> B[Discord Tools]
 A --> C[Cloud Monitor Tools]
 B --> D[Gateway Service]
 C --> D
 D --> E[Discord API]
 end

 subgraph Cloud Monitor
 F[SSH Monitor] --> G[OCI Servers]
 F --> H[Mac mini]
 G --> I[Ubuntu]
 H --> J[macOS]
 end

 subgraph Discord
 K[Bot] --> L[Channels]
 K --> M[Threads]
 end

MCP Tool Categories

Category	Tool Count	Main Functions
Discord MCP	8	Message, thread management
Cloud Monitor MCP	5	Server monitoring, metrics collection
Total	13	Integrated monitoring platform

Detailed Tool Analysis

1. Existing Discord MCP Tools (8)

1.1 Message Management Tools

Tool Name	Parameters	Returns	Features
`discord_send_message`	`channel_id`, `content`, `thread_id?`	Result message	Basic message sending
`discord_get_messages`	`channel_id`, `limit?`, `after?`	Message list	Message retrieval
`discord_wait_for_message`	`channel_id`, `timeout_seconds?`	Wait status	Async message waiting (SSE not implemented)

1.2 Thread Management Tools

Tool Name	Parameters	Returns	Features
`discord_create_thread`	`channel_id`, `message_id`, `name?`	Thread info	Thread creation
`discord_list_threads`	`channel_id`	Thread list	Active thread lookup
`discord_archive_thread`	`thread_id`	Result message	Thread archiving (not implemented)

1.3 Concurrency Management Tools

Tool Name	Parameters	Returns	Features
`discord_acquire_thread`	`thread_id`, `agent_name`, `timeout?`	Lock acquisition result	Multi-agent lock
`discord_release_thread`	`thread_id`, `agent_name`	Lock release result	Agent lock release

2. New Cloud Monitor MCP Tools (5)

2.1 Server Management Tools

Tool Name	Parameters	Returns	Features
`cloud_get_server_status`	`server_name`	Server status info	Connection status, OS, metrics
`cloud_list_servers`	`group?`	Server list	Group filtering support
`cloud_list_ssh_config_hosts`	`group?`	SSH host list	SSH config auto-parsing

2.2 Monitoring Tools

Tool Name	Parameters	Returns	Features
`cloud_get_metrics`	`server_name`, `metric_types?`	Metrics data	Optional metric lookup
`cloud_set_alert`	`metric_type`, `level`, `threshold`	Setting result	Dynamic threshold configuration

Architecture Structure

1. FastMCP Structure

graph LR
 subgraph "FastMCP Layer"
 A[@mcp.tool decorator] --> B[Tool Function]
 B --> C[Parameter Validation]
 C --> D[Business Logic]
 D --> E[Result Formatting]
 E --> F[Return Response]
 end

 subgraph "Common Components"
 G[Gateway Request] --> H[HTTP Client]
 I[Config Manager] --> J[Cloud Monitor Config]
 K[Error Handler] --> L[Uniform Error Response]
 end

2. Communication Flow

sequenceDiagram
 participant MCP as MCP Server
 participant GW as Gateway Service
 participant Discord as Discord API
 participant Server as Target Server

 MCP->>GW: HTTP Request
 GW->>Discord: API Call
 Discord-->>GW: Response
 GW-->>MCP: JSON Response

 MCP->>Server: SSH Connection
 Server-->>MCP: Metrics Data
 MCP->>GW: Alert Message
 GW->>Discord: Embed Message

3. Data Flow

Configuration (config.yaml)
 ↓
Server Info parsing
 ↓
SSH Connection
 ↓
Metrics Collection
 ↓
Threshold Check
 ↓
Alert Generation
 ↓
Discord Notification

Advantages

1. Scalability

Modular Structure: Each tool operates independently and is easy to extend
Plugin Architecture: Adding new tools only requires adding decorators
Cloud Provider Abstraction: SSH-based support for various environments

2. Integration

Unified Platform: Discord and Cloud Monitor managed together on a single MCP server
Automatic Linkage: Automatic Discord alerts on server anomalies
Consistent Interface: All tools follow the same parameter pattern

3. Usability

Intuitive Tool Names: Clear function expression like cloud_get_server_status
Optional Parameters: Most parameters are optional for convenience
Detailed Error Messages: Clearly indicates the cause of failures
JSON Response: Structured data return for easy parsing

4. Reliability

Timeout Handling: Timeout set for all requests
Connection Pooling: SSH connection reuse for performance
Exception Handling: Comprehensive try-catch blocks
Status Tracking: Continuous server status monitoring

5. Maintainability

Centralized Configuration: Central management via config.yaml
Environment Variable Support: Sensitive info separated into environment variables
Logging System: Detailed logging for easy debugging
Version Management: Clear module version distinction

Disadvantages and Improvements

Issues

Synchronous Processing: Some tools operate sequentially
Connection Latency: New connection created each SSH connection
Memory Usage: All processing on single event loop

Improvements

# Async processing improvement example
async def concurrent_monitoring(servers):
 tasks = [monitor_server(server) for server in servers]
 return await asyncio.gather(*tasks)

# Connection pooling introduction
class ConnectionPool:
 def __init__(self, max_connections=10):
 self.pool = asyncio.Queue(maxsize=max_connections)

Issues

Undifferentiated Errors: All errors handled the same way
Lack of Recovery Mechanism: No auto-recovery logic on failures
Insufficient Detailed Logging: Insufficient logs for debugging

Improvements

# Differentiated error handling
class CloudMonitorError(Exception):
 pass

class ConnectionError(CloudMonitorError):
 pass

class MetricCollectionError(CloudMonitorError):
 pass

# Auto-recovery mechanism
async def resilient_monitoring(server_info, max_retries=3):
 for attempt in range(max_retries):
 try:
 return await monitor_server(server_info)
 except ConnectionError:
 await asyncio.sleep(2 ** attempt)
 raise CloudMonitorError("Max retries exceeded")

Issues

Lack of Metadata: Tool descriptions too brief
Insufficient Validation: Lack of input value check logic
No Batch Processing: Cannot process multiple servers simultaneously

Improvements

# Detailed metadata
@mcp.tool(
 name="cloud_batch_monitoring",
 description="Retrieve multiple server statuses at once",
 parameters={
 "server_names": {
 "type": "array",
 "items": {"type": "string"},
 "description": "List of server names to monitor"
 }
 }
)
async def cloud_batch_monitoring(server_names: List[str]) -> str:
 # Batch processing logic
 pass

Issues

Credential Exposure: Sensitive info potentially exposed in logs
No Access Control: Anyone can call tools
Insufficient Input Validation: Insufficient defense against malicious input

Improvements

# Access control
def require_role(required_role):
 def decorator(func):
 async def wrapper(*args, **kwargs):
 if not has_role(required_role):
 raise PermissionError("Access denied")
 return await func(*args, **kwargs)
 return wrapper
 return decorator

# Input validation
@mcp.tool()
async def secure_monitoring(server_name: str):
 if not is_valid_server_name(server_name):
 raise ValueError("Invalid server name")
 # ...

Issues

Lack of Documentation: No detailed documentation for tool usage
No Examples: No actual usage examples
Inconsistent Return Values: Some tools return JSON, others return strings

Improvements

# Consistent return value format
@mcp.tool()
async def cloud_get_server_status_v2(server_name: str) -> dict:
 """
 Retrieve server status.

 Args:
 server_name (str): Server name

 Returns:
 dict: {
 "success": bool,
 "data": Optional[dict],
 "error": Optional[str],
 "timestamp": str
 }
 """
 # ...
 return {
 "success": True,
 "data": status,
 "error": None,
 "timestamp": datetime.now().isoformat()
 }

Conclusion

1. Overall Assessment

The MCP tools in the server-monitor project have the following strengths:

✅ Excellent Integration: Perfect combination of Discord integration and server monitoring
✅ Scalable Structure: Modular architecture using FastMCP
✅ Practicality: Provides all functions needed for actual server monitoring
✅ Ease of Use: Intuitive tool names and simple interface

2. Improvement Priority

Improvement plans by priority:

High: Performance improvement (async processing, connection pooling)
Medium: Error handling enhancement and auto-recovery mechanisms
Low: Security enhancement and detailed documentation

3. Future Direction

Microservices Architecture: Separate each tool into independent services
Real-time Monitoring: Real-time data collection via WebSocket/SSE
Auto-scaling: Automatic scaling based on server changes
Machine Learning: ML model integration for anomaly detection

4. Final Assessment

Overall, a well-designed MCP tool system that provides stability and functionality suitable for actual production environments. While there are areas for improvement, the core functionality is highly complete, and it has the potential to develop into an even more powerful monitoring platform through continuous improvements.

Written: 2026-03-03 Author: server-monitor-team

Korean Version: 한국어 버전

[Discord Decision MCP] Architecture Design Document

Mon, 02 Mar 2026 21:36:30 +0900

Discord Decision MCP — Architecture Design Document

1. Project Overview

1.1 Purpose

An MCP (Model Context Protocol) server that allows Claude Code, while operating in tmux Teammate mode for autonomous work, to ask questions via Discord when user decisions are needed and resume work after receiving responses.

1.2 Key Features

Feature	Description
One Bot per Project	Each project uses an independent Discord Bot
Infinite Wait Default	Wait for user response without timeout (Claude must not proceed unilaterally)
State Persistence	Restore waiting state after process restart
Korean-Friendly	Korean options, Yes/No response support
MCP-Based Communication	All Discord communication through MCP Tools

1.3 Version Information

Version: 1.0.0
Python Requirement: >= 3.11
MCP Framework: FastMCP >= 0.1.0

2. Directory Structure

discord-decision/
├── discord_mcp/ # Main package
│ ├── __init__.py
│ ├── server.py # MCP server entry point
│ ├── config.py # Environment variable configuration
│ │
│ ├── bot/ # Discord API client
│ │ ├── __init__.py
│ │ ├── client.py # REST API client (httpx)
│ │ └── gateway.py # WebSocket gateway (receive only)
│ │
│ ├── decision/ # Decision request management
│ │ ├── __init__.py
│ │ ├── manager.py # Decision request lifecycle management
│ │ ├── poller.py # Discord polling and response waiting
│ │ ├── parser.py # User response parsing
│ │ └── state.py # State persistence (JSON files)
│ │
│ ├── tools/ # MCP Tools implementation
│ │ ├── __init__.py
│ │ ├── ask.py # discord_ask_decision
│ │ ├── notify.py # discord_notify
│ │ ├── report.py # discord_report_progress
│ │ ├── status.py # discord_check_pending
│ │ ├── inbox.py # discord_read_inbox, discord_clear_inbox
│ │ └── _templates.py # Discord message templates
│ │
│ └── daemon/ # Watcher daemon
│ ├── __init__.py
│ ├── watcher.py # Discord channel monitoring (discord-watch CLI)
│ └── inbox.py # Inbox file management
│
├── scripts/ # Utility scripts
│ └── start-discord-watch.sh
│
├── tests/ # Test suite
│ ├── __init__.py
│ ├── test_parser.py
│ └── test_state.py
│
├── CLAUDE.md # Claude Code project instructions
├── README.md # Project description
├── pyproject.toml # Project configuration and dependencies
└── mcp.json.example # MCP configuration example

3. Key Module Descriptions

3.1 Server Entry Point (`server.py`)

Role: FastMCP server creation and MCP Tool registration

mcp = FastMCP(name="discord-decision-mcp")
# Tool registration
mcp.tool()(discord_ask_decision)
mcp.tool()(discord_notify)
mcp.tool()(discord_report_progress)
mcp.tool()(discord_check_pending)
mcp.tool()(discord_read_inbox)
mcp.tool()(discord_clear_inbox)

Execution:

discord-mcp # or python -m discord_mcp.server

3.2 Configuration Management (`config.py`)

Role: Load configuration values from environment variables

Environment Variable	Description	Default
`DISCORD_BOT_TOKEN`	Discord Bot Token (includes “Bot " prefix)	Required
`DISCORD_CHANNEL_ID`	Default question channel ID	Required
`PROJECT_NAME`	Used for question_id generation	“project”
`PENDING_DIR`	State file storage path	`~/.claude/pending_decisions`
`POLL_INTERVAL_SECONDS`	Discord polling interval (seconds)	5

3.3 Discord API Client (`bot/`)

3.3.1 REST API Client (`client.py`)

Role: Discord REST API calls (httpx-based)

Key Methods:

class DiscordClient:
 async def send_message(channel_id, content, embeds=None)
 async def get_messages(channel_id, after=None, limit=50)
 async def create_thread(channel_id, name, first_message)
 async def archive_thread(thread_id)

Features:

Automatic rate limit handling (retry on 429 response)
Singleton pattern (get_client())

3.3.2 WebSocket Gateway (`gateway.py`)

Role: Discord Gateway WebSocket connection (receive only)

Features:

Real-time MESSAGE_CREATE event reception
Reduces polling delay from 5 seconds to instant
System works without Gateway (polling fallback)
Automatic reconnection (Exponential backoff)

class GatewayClient:
 async def run() # Start event reception
 async def stop() # Close connection

3.4 Decision Request Management (`decision/`)

3.4.1 DecisionManager (`manager.py`)

Role: Coordinate the entire lifecycle of decision requests

class DecisionManager:
 async def ask(question, context, options, timeout_seconds, thread_id) -> PollResult
 async def restore_pending() -> list[DecisionState]

Flow:

Check for duplicate questions
Create thread (or reuse existing thread)
Create state file (~/.claude/pending_decisions/{question_id}.json)
Run poller to wait for response
Mark disconnected state on SIGHUP signal

3.4.2 DecisionPoller (`poller.py`)

Role: Poll Discord channel and wait for response

class DecisionPoller:
 async def wait(state: DecisionState) -> PollResult

Features:

Default: infinite wait (timeout_seconds=None)
Real-time waiting status display in tmux pane (ANSI escape)
Re-question up to 2 times for ambiguous responses

3.4.3 Response Parser (`parser.py`)

Role: Parse user Discord responses

Supported Patterns:

Option matching: “A”, “a”, “A번”, “A로 해줘”, “1”, “1번”
Affirmative/Negative: “yes”, “네”, “예”, “no”, “아니요”
Natural language: 15+ characters or 3+ Korean characters

def parse_response(text: str, options: list[str]) -> ParseResult
def build_clarify_message(...) -> str # Generate re-question message

3.4.4 State Store (`state.py`)

Role: Persist decision request state to JSON files

State File Location: ~/.claude/pending_decisions/{question_id}.json

class DecisionState(BaseModel):
 question_id: str
 project: str
 question: str
 context: str
 options: list[str]
 timeout_seconds: float | None
 thread_id: str
 message_id: str
 asked_at: str
 status: Literal["pending", "disconnected", "resolved", "aborted", "timeout"]
 clarify_attempts: int
 resolved_at: str | None
 resolution: str | None
 selected_option: str | None

class StateStore:
 def save(state: DecisionState)
 def load(question_id: str) -> DecisionState | None
 def load_all_pending() -> list[DecisionState]
 def resolve(question_id, resolution, selected_option)
 def is_duplicate(question: str) -> bool

3.5 MCP Tools (`tools/`)

Tool	Blocking	Description
`discord_ask_decision`	✅	User decision request
`discord_notify`	❌	Progress notification
`discord_report_progress`	❌	Task completion report
`discord_check_pending`	❌	Check pending questions
`discord_read_inbox`	❌	Inbox message query
`discord_clear_inbox`	❌	Inbox message deletion

3.6 Watcher Daemon (`daemon/`)

3.6.1 DiscordWatcher (`watcher.py`)

Role: Monitor Discord channel and record new messages to inbox file

Execution:

discord-watch --interval 10
# or
tmux new-session -d -s discord-watch 'uv run discord-watch'

Features:

Periodically poll specified channel(s)
Record new user messages to inbox
Display status in tmux pane

3.6.2 InboxStore (`inbox.py`)

Role: JSON file-based storage for Discord messages

Inbox File Location: ~/.claude/discord_inbox.json

class InboxMessage:
 message_id: str
 channel_id: str
 thread_id: str | None
 author: str
 author_id: str
 content: str
 timestamp: str
 read: bool

class InboxStore:
 def add_message(msg: InboxMessage)
 def get_unread() -> list[InboxMessage]
 def mark_read(message_id: str)
 def clear_read() # Delete read messages

4. Data Flow Diagrams

4.1 Decision Request Flow

┌─────────────────┐
│ Claude Code │
└────────┬────────┘
 │ discord_ask_decision()
 ▼
┌─────────────────────────────────────┐
│ MCP Server (server.py) │
│ ┌───────────────────────────────┐ │
│ │ DecisionManager.ask() │ │
│ │ 1. Duplicate check │ │
│ │ 2. Thread creation │ │
│ │ 3. State file save │ │
│ └───────────────┬───────────────┘ │
└──────────────────┼──────────────────┘
 ▼
┌─────────────────────────────────────┐
│ DecisionPoller.wait() │
│ ┌───────────────────────────────┐ │
│ │ Polling loop │ │
│ │ 1. tmux status update │ │
│ │ 2. Discord API call │ │
│ │ 3. Response parsing │ │
│ │ 4. Re-question if ambiguous │ │
│ └───────────────┬───────────────┘ │
└──────────────────┼──────────────────┘
 │
 ┌─────────┴─────────┐
 ▼ ▼
┌───────────────────┐ ┌──────────────────┐
│ Discord REST API │ │ Discord Thread │
│ (client.py) │ │ │
└───────────────────┘ └────────┬─────────┘
 │
 ┌────────▼────────┐
 │ User Response │
 └────────┬────────┘
 ▼
 ┌─────────────────┐
 │ parser.py │
 │ - Option match │
 │ - Ambiguity │
 └────────┬────────┘
 ▼
 ┌─────────────────┐
 │ store.resolve()│
 └────────┬────────┘
 ▼
 ┌─────────────────┐
 │ PollResult │
 │ Return │
 └─────────────────┘

4.2 Watcher Daemon Flow

┌─────────────────────────────────────────────┐
│ DiscordWatcher (daemon/watcher.py) │
│ ┌───────────────────────────────────────┐ │
│ │ 1. Set initial message ID │ │
│ │ 2. Periodic polling (default 10s) │ │
│ │ 3. Detect new messages │ │
│ │ 4. InboxStore.add_message() │ │
│ └───────────────────┬───────────────────┘ │
└──────────────────────┼──────────────────────┘
 ▼
┌─────────────────────────────────────────────┐
│ ~/.claude/discord_inbox.json │
│ { │
│ "last_message_id": "...", │
│ "messages": [ │
│ { "message_id": "...", ... } │
│ ] │
│ } │
└──────────────────────┬──────────────────────┘
 ▲
 │ discord_read_inbox()
┌──────────────────────┴──────────────────────┐
│ Claude Code │
└─────────────────────────────────────────────┘

4.3 Session Restoration Flow

┌─────────────────────────────────────────────┐
│ Claude Code session start │
└──────────────────────┬──────────────────────┘
 ▼
┌─────────────────────────────────────────────┐
│ discord_check_pending() │
└──────────────────────┬──────────────────────┘
 ▼
┌─────────────────────────────────────────────┐
│ DecisionManager.restore_pending() │
│ ┌───────────────────────────────────────┐ │
│ │ 1. ~/.claude/pending_decisions/*.json │ │
│ │ 2. Check Thread via Discord API │ │
│ │ 3. If answered → Auto-resolve │ │
│ │ 4. If no answer → Restart notification│ │
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

5. MCP Tools List

5.1 discord_ask_decision

Description: Send question to Discord Thread and wait for response when user decision is needed (blocking)

Parameters:

Name	Type	Required	Description
`question`	string	✅	Question content
`context`	string	✅	Current work context
`options`	string[]	❌	List of options (empty array for free response)
`timeout_seconds`	float	❌	Wait timeout (null for infinite wait)
`thread_id`	string	❌	Existing Thread ID (null to create new Thread)

Return Value:

{
 "success": true,
 "answer": "A) Execute now",
 "selected_option": "A) Execute now",
 "question_id": "project_20260301_abc123",
 "timed_out": false,
 "aborted": false
}

5.2 discord_notify

Description: Send progress notification to Discord (non-blocking)

Parameters:

Name	Type	Required	Description
`message`	string	✅	Notification message
`level`	string	❌	info/warning/success/error (default: info)
`thread_id`	string	❌	Thread ID to send to (null for default channel)

5.3 discord_report_progress

Description: Report task completion or milestone completion (non-blocking)

Parameters:

Name	Type	Required	Description
`title`	string	✅	Report title
`summary`	string	✅	Task result summary
`details`	string[]	❌	List of detail items
`thread_id`	string	❌	Thread ID to send to

5.4 discord_check_pending

Description: Check pending questions at session start (non-blocking)

Parameters: None

Return Value:

{
 "has_pending": true,
 "pending_questions": [
 {
 "question_id": "project_20260301_abc123",
 "question": "Deploy?",
 "thread_id": "1234567890",
 "asked_at": "2026-03-01T10:30:00Z",
 "status": "pending"
 }
 ]
}

5.5 discord_read_inbox

Description: Query messages stored in Inbox (non-blocking)

Parameters:

Name	Type	Default	Description
`unread_only`	boolean	true	Return only unread messages
`mark_read`	boolean	false	Mark queried messages as read

5.6 discord_clear_inbox

Description: Delete Inbox messages (non-blocking)

Parameters:

Name	Type	Default	Description
`read_only`	boolean	true	Delete only read messages

6. Dependency Information

6.1 Core Dependencies

Package	Version	Purpose
`fastmcp`	>= 0.1.0	MCP server framework
`httpx`	>= 0.27.0	Async HTTP client
`websockets`	>= 12.0	WebSocket client
`python-dotenv`	>= 1.0.0	Environment variable loading
`pydantic`	>= 2.0.0	Data model validation
`anyio`	>= 4.0.0	Async execution

6.2 Development Dependencies

Package	Purpose
`pytest`	Test framework
`pytest-asyncio`	Async test support
`pytest-mock`	Mock support
`respx`	httpx mocking

6.3 CLI Commands

discord-mcp # Run MCP server
discord-watch # Run watcher daemon

7. State File Format

7.1 Decision State File

Location: ~/.claude/pending_decisions/{question_id}.json

{
 "question_id": "project_20260301_abc123",
 "project": "my-project",
 "question": "Run DB migration?",
 "context": "v1→v2 schema change",
 "options": ["A) Execute now", "B) Staging first", "C) Hold"],
 "timeout_seconds": null,
 "thread_id": "1234567890",
 "message_id": "0987654321",
 "asked_at": "2026-03-01T10:30:00Z",
 "status": "pending",
 "clarify_attempts": 0,
 "resolved_at": null,
 "resolution": null,
 "selected_option": null
}

7.2 Inbox File

Location: ~/.claude/discord_inbox.json

{
 "last_message_id": "1234567890",
 "messages": [
 {
 "message_id": "1234567890",
 "channel_id": "1234567890",
 "thread_id": null,
 "author": "username",
 "author_id": "1234567890",
 "content": "Message content",
 "timestamp": "2026-03-01T00:00:00Z",
 "read": false
 }
 ]
}

8. Architecture Principles

8.1 Design Principles

Singleton Pattern: DiscordClient, StateStore, InboxStore are module-level singletons
State Persistence: All decision request states are persisted to files
Infinite Wait Default: Timeout default is None so Claude does not proceed unilaterally
Re-question Limit: Ambiguous responses are re-asked up to 2 times
Rate Limit Handling: Automatic wait and retry on Discord API 429 responses

8.2 Error Handling

Situation	Handling
Discord API 429	Automatic wait and retry (max 5 times)
WebSocket disconnection	Reconnect with exponential backoff
Response parsing failure	Re-question up to 2 times then abort
Timeout occurrence	Send abort notification and set aborted state
Session disconnect (SIGHUP)	Save as disconnected state

Document Version: 1.0.0 Last Modified: 2026-03-02

Korean Version: 한국어 버전

[Discord MCP] Gateway Architecture Design

Sun, 01 Mar 2026 01:13:00 +0900

The Claude Code team designed a Discord Gateway Service for user communication via Discord. This article summarizes the key architecture decisions and user_comm Agent design.

1. Overall Architecture

Components

Layer	Component	Role
Discord	Bot, Channel, Thread	User interface
Gateway	WebSocket, REST API, SSE	Message routing
MCP	gcp-mcp, oci-mcp, db-mcp	Tool execution
user_comm	Discord Agent	User communication

Message Flow

flowchart LR
 subgraph D[Discord]
 U[User]
 end
 subgraph G[Gateway :8081]
 WS[WebSocket]
 API[REST API]
 SSE[SSE]
 end
 subgraph A[Claude Code Team]
 UC[user_comm]
 GCP[gcp-mcp]
 OCI[oci-mcp]
 DB[db-mcp]
 end

 U --> WS
 WS --> UC
 UC --> API
 API --> GCP
 API --> OCI
 API --> DB
 GCP --> UC
 OCI --> UC
 DB --> UC
 UC --> SSE
 SSE --> U

2. user_comm Agent (User Communication Handler)

Role and Responsibilities

The user_comm Agent is a member of the Claude Code team, communicating with users through Discord channels and collaborating with other agents.

Function	Description
Input Reception	Receive Discord messages and route to appropriate agent
Opinion Request	Query user opinions at other agents’ requests
Notification/Report	Send system status, warnings, reports
Team Communication	Exchange messages with other agents

Internal Structure

flowchart TB
 subgraph UC[user_comm Agent]
 DBot[Discord Bot]
 Agent[UserCommAgent]
 TComm[TeamCommunicator]
 DBot <--> Agent
 Agent <--> TComm
 end
 subgraph DAPI[Discord API]
 M[Messages]
 B[Buttons]
 T[Threads]
 end
 subgraph O[Other Agents]
 GCP[gcp-mcp]
 OCI[oci-mcp]
 AL[alert-mcp]
 end

 DBot <--> M
 DBot <--> B
 DBot <--> T
 TComm --> GCP
 TComm --> OCI
 TComm --> AL

Message Types

class MessageType(Enum):
 TASK_REQUEST = "task_request" # Task request
 NOTIFICATION = "notification" # Notification
 OPINION_REQUEST = "opinion_request" # Opinion request
 OPINION_RESPONSE = "opinion_response" # Opinion response
 STATUS_REPORT = "status_report" # Status report
 ERROR = "error" # Error

Key Function Flows

Input Reception (Discord -> Agent)

User: "@gcp-monitor check server status"
 -> DiscordBot.on_message
 -> UserCommAgent._parse_command (target: gcp-monitor)
 -> TeamCommunicator.send_to_agent
 -> Discord: "Request forwarded to gcp-monitor."

Opinion Request (Agent -> Discord)

gcp-monitor: "Clean up disk?" -> user_comm
 -> DiscordBot.ask_opinion (wait for button or reply)
 -> User response
 -> TeamCommunicator.send_to_agent (forward response)

Notification/Report (Agent -> Discord)

oci-monitor: "Disk 92% warning" -> user_comm
 -> DiscordBot.send_message (Embed format)

3. Lightweight Architecture Without Redis

Why Remove Redis?

Item	With Redis	With In-Memory
Thread Lock	Redis SET NX	Python dict
Event Distribution	Redis Streams	Direct SSE
State Storage	Redis Cache	Memory cache

Conclusion: In-memory is sufficient for single-instance environments

Gateway Structure

flowchart TB
 subgraph GW[Gateway Service]
 Bot[Discord Bot]
 subgraph C[Core Components]
 Lock[Thread Lock]
 Cache[Message Cache]
 SSEMgr[SSE Manager]
 end
 end
 DAPI[Discord API] <--> Bot
 Bot --> Lock
 Bot --> Cache
 Bot --> SSEMgr
 SSEMgr --> Clients[WebSocket Clients]

Component Details

Module	Role	Features
Discord Bot	WebSocket connection	Auto-reconnect
Thread Lock	Concurrency control	5min timeout
Message Cache	Message storage	Max 1000 items
SSE Manager	Real-time delivery	Broadcast to all MCPs

4. MCP Selection: 4-Stage Hybrid

Selection Priority

Rank	Method	Example	Description
1	Slash Command	`/gcp status`	Most explicit
2	@Mention	`@gcp-monitor status`	Natural conversation
3	Keyword Detection	`gcp server status`	Auto keyword recognition
4	Channel Assignment	#gcp-monitoring	Channel default MCP

Fallback Order

flowchart TD
 A[Message Received] --> B{Slash Command?}
 B -->|Yes| C[Route to MCP]
 B -->|No| D{Mention?}
 D -->|Yes| C
 D -->|No| E{Keyword?}
 E -->|Yes| C
 E -->|No| F{Channel Default?}
 F -->|Yes| C
 F -->|No| G[Broadcast]

Slash Command List

Command	MCP	Description
`/gcp status [server]`	gcp-mcp	GCP server status
`/gcp list`	gcp-mcp	GCP instance list
`/oci status [server]`	oci-mcp	OCI server status
`/oci list`	oci-mcp	OCI instance list
`/db query <sql>`	db-mcp	Execute DB query
`/db list`	db-mcp	DB list
`/alert check`	alert-mcp	Check alerts

5. Thread Lock Rules

Lock Behavior

sequenceDiagram
 participant M1 as gcp-mcp
 participant GW as Gateway
 participant M2 as oci-mcp
 participant DT as Discord Thread

 Note over M1,DT: Lock Acquisition
 M1->>+GW: Lock request
 GW-->>-M1: Lock acquired
 M1->>DT: Send response

 Note over M2,GW: Lock Conflict
 M2->>GW: Lock request
 GW-->>M2: Lock failed

 Note over M1,GW: 5min timeout
 GW->>GW: Auto-release lock

 Note over M2,GW: Lock Retry
 M2->>+GW: Lock request
 GW-->>-M2: Lock acquired

Lock API

Method	Endpoint	Description
`POST`	`/api/threads/{id}/acquire`	Acquire lock
`POST`	`/api/threads/{id}/release`	Release lock
`GET`	`/api/threads/{id}/lock`	Check lock status

Request/Response Example

Lock Acquire Request

POST /api/threads/123456/acquire
{
 "agent_name": "gcp-mcp",
 "timeout": 300
}

Lock Acquire Response

{
 "acquired": true,
 "thread_id": "123456",
 "agent": "gcp-mcp"
}

6. MCP Tools (8)

Tool List

Tool	Description	Key Parameters
`discord_send_message`	Send message	channel_id, content
`discord_get_messages`	Get messages	channel_id, limit
`discord_wait_for_message`	Wait for message	channel_id, timeout
`discord_create_thread`	Create thread	channel_id, message_id
`discord_list_threads`	List threads	channel_id
`discord_archive_thread`	Archive thread	thread_id
`discord_acquire_thread`	Acquire lock	thread_id, agent_name
`discord_release_thread`	Release lock	thread_id, agent_name

Tool Relationships

flowchart LR
 subgraph Lock[Lock Tools]
 Acquire[acquire_thread]
 Release[release_thread]
 end
 subgraph Thread[Thread Tools]
 Create[create_thread]
 List[list_threads]
 Archive[archive_thread]
 end
 subgraph Msg[Message Tools]
 Send[send_message]
 Get[get_messages]
 Wait[wait_for_message]
 end

 Acquire --> Create
 Create --> Send
 Send --> Release

Usage Examples

# Send message
discord_send_message(
 channel_id="123456789",
 content="Server status: OK"
)

# Create thread
discord_create_thread(
 channel_id="123456789",
 message_id="987654321",
 name="Status Check"
)

# Acquire lock
discord_acquire_thread(
 thread_id="111222333",
 agent_name="gcp-mcp",
 timeout=300
)

7. File Structure

flowchart TB
 subgraph P[server_monitor/]
 subgraph Gw[gateway/]
 M1[main.py]
 M2[discord_ws.py]
 M3[thread_lock.py]
 M4[sse.py]
 end
 subgraph Uc[user_comm/]
 A1[agent.py]
 A2[discord_bot.py]
 A3[team_comm.py]
 end
 subgraph Mcp[discord_mcp/]
 S1[server.py]
 end
 subgraph Sh[mcp_shared/]
 MO[monitor/]
 end
 subgraph Doc[docs/]
 D1[MCP_SELECTION_STRATEGY.md]
 D2[MCP_ROUTING_POLICY.md]
 end
 end

Directory Description

Path	Description
`gateway/`	Gateway Service (FastAPI)
`user_comm/`	User Communication Agent
`discord_mcp/`	MCP Server (8 tools)
`mcp_shared/`	Shared MCP tools
`docs/`	Documentation

8. How to Run

Local Execution

# Start Gateway Service
uvicorn gateway.main:app --host 0.0.0.0 --port 8081

# Start user_comm Agent (standalone mode)
python main.py --standalone

# Start user_comm Agent (team mode)
python main.py --team server-monitor

# Health check
curl http://localhost:8081/health

# Response
{"status": "healthy", "discord_connected": true}

Claude Code MCP Configuration

// ~/.claude/settings.json
{
 "mcpServers": {
 "discord-gateway": {
 "command": "python3",
 "args": ["/path/to/discord_mcp/server.py"],
 "env": {
 "GATEWAY_URL": "http://localhost:8081"
 }
 }
 }
}

9. Roadmap

Phase 1: Complete

FastAPI Gateway Service
Discord WebSocket connection
Thread Lock (In-Memory)
SSE broadcast
MCP Server (8 tools)

Phase 2: In Progress

user_comm Agent implementation
Slash command implementation
Channel default MCP settings
Keyword auto-detection
Routing configuration file

Phase 3: Optional

API authentication (API Key)
Rate Limiting
Message persistence (SQLite)

Conclusion

We chose a strategy of starting with a lightweight architecture and expanding when needed.

Item	Current	Future
State Storage	In-Memory	SQLite (if needed)
Distributed Lock	Not used	Redis (multi-instance)
Authentication	None	API Key (if needed)
User Communication	Gateway direct	user_comm Agent

The current structure is sufficient for single instances, and we plan to expand incrementally as traffic grows. The user_comm Agent systematizes user communication and improves collaboration with other agents on the team.

Korean Version: 한국어 버전

[Claude Code] Team Agent Communication Architecture

Sat, 28 Feb 2026 14:07:38 +0900

Claude Code Team Agent Communication Architecture Design

Overview

When multiple AI agents collaborate in Claude Code, an efficient communication method is needed. This article shares the communication architecture designed while building a Discord-integrated server monitoring team.

Problem Definition

Claude Code has two types of agents:

Python Processes (Daemon)
- Discord Gateway, user_comm_daemon, etc.
- Always running, filesystem access available
LLM Agents (Created as Tasks)
- gcp-monitor, oci-monitor, alert-manager, etc.
- Use SendMessage tool, Claude Code native communication

Communication between these two types was needed.

Considered Approaches

1. File-based Message Queue (Existing)

Pros: Simple implementation, no dependencies
Cons: Latency (~1s), file management required

2. WebSocket

Pros: Real-time bidirectional communication
Cons: Server/client implementation required

3. gRPC

Pros: Strong type checking, streaming
Cons: proto file management, high complexity

4. SQLite Message Hub (Adopted)

Pros: Fast (~10ms), transactions, no additional dependencies
Cons: Works only on a single machine

Final Architecture

┌─────────────────────────────────────────────────────────────────┐
│ SQLite Message Hub (messages.db) │
│ ~/.claude/teams/{team}/messages.db │
└───────────────────────────┬─────────────────────────────────────┘
 │
 ┌───────────────────┼───────────────────┐
 ↓ ↓ ↓
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Discord │ │ Python │ │ LLM │
│ Gateway │ │ Daemon │ │ Agent │
│ (Direct Access)│ │ (Direct Access)│ │ (MCP Tool) │
└──────────────┘ └──────────────┘ └──────────────┘

SQLite Message Hub Structure

Messages Table

CREATE TABLE messages (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 message_id TEXT UNIQUE NOT NULL,
 sender TEXT NOT NULL,
 recipient TEXT, -- NULL = broadcast
 message_type TEXT DEFAULT 'message',
 content TEXT NOT NULL,
 priority TEXT DEFAULT 'normal',
 metadata TEXT DEFAULT '{}',
 status TEXT DEFAULT 'pending',
 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
 processed_at TIMESTAMP,
 expires_at TIMESTAMP
);

Agent Status Table

CREATE TABLE agent_status (
 agent_name TEXT PRIMARY KEY,
 status TEXT DEFAULT 'offline',
 last_heartbeat TIMESTAMP,
 metadata TEXT DEFAULT '{}'
);

Communication Methods

LLM Agent ↔ LLM Agent

Use SendMessage (Claude Code native)
Auto-managed, idle notification provided

Python ↔ LLM Agent

SQLite Hub + MCP Tool
Python accesses SQLite directly
LLM Agent accesses via MCP Tool

MCP Server Implementation

MCP tools for LLM Agents:

@server.list_tools()
async def list_tools():
 return [
 Tool(name="team_send_message", ...),
 Tool(name="team_read_messages", ...),
 Tool(name="team_broadcast", ...),
 Tool(name="team_get_status", ...),
 Tool(name="team_update_status", ...),
 ]

Message Flow Example

1. Discord user: "Hello"
 ↓
2. Discord Gateway → SQLite: INSERT message
 ↓
3. user_comm Daemon → SQLite: SELECT pending
 ↓
4. user_comm → SQLite: INSERT response
 ↓
5. Discord Gateway → SQLite: SELECT response
 ↓
6. Discord channel: "Hi there! 👋"

Performance Comparison

Method	Latency	Stability	Complexity
File-based	~1000ms	Medium	Low
WebSocket	~5ms	High	Medium
SQLite	~10ms	High	Low

Conclusion

The SQLite Message Hub + MCP Server combination was most suitable for Claude Code team agent communication:

Low Latency: 100x faster than file-based
Stability: Data integrity guaranteed through transactions
Simplicity: Uses Python’s built-in sqlite3 without additional dependencies
Flexibility: Both Python and LLM Agents use the same data source

Code

Core components:

message_hub.py: SQLite Message Hub
team_comm_mcp_server.py: MCP Server
discord_gateway.py: Discord integration gateway
user_comm_daemon.py: Message processing daemon

Korean Version: 한국어 버전

Discord on Yarang's Tech Lair

MCP Integration Guide: Integrating Discord MCP with ZeroClaw Runtime

1. Architecture Design: Dual Communication on a Single Channel

2. Essential Dependencies and Setup (Rust)

3. MCP Client Implementation

4. Integration with ZeroClaw Agents

5. Efficiency and Security Considerations (Architecture Insights)

Conclusion

Claude Code Discord MCP Plugin - Fixing asdf bun Path Issue

Problem

Root Cause

Solution

Finding the Absolute Path of asdf-installed bun

Applying the Configuration

Summary

References

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

Table of Contents

Architecture Overview

FastMCP-based Architecture

MCP Tool Categories

Detailed Tool Analysis

1. Existing Discord MCP Tools (8)

1.1 Message Management Tools

1.2 Thread Management Tools

1.3 Concurrency Management Tools

2. New Cloud Monitor MCP Tools (5)

2.1 Server Management Tools

2.2 Monitoring Tools

Architecture Structure

1. FastMCP Structure

2. Communication Flow

3. Data Flow

Advantages

1. Scalability

2. Integration

3. Usability

4. Reliability

5. Maintainability

Disadvantages and Improvements

1. Performance Related

Issues

Improvements

2. Error Handling Related

Issues

Improvements

3. Functionality Related

Issues

Improvements

4. Security Related

Issues

Improvements

5. Usability Related

Issues

Improvements

Conclusion

1. Overall Assessment

2. Improvement Priority

3. Future Direction

4. Final Assessment

[Discord Decision MCP] Architecture Design Document

Discord Decision MCP — Architecture Design Document

1. Project Overview

1.1 Purpose

1.2 Key Features

1.3 Version Information

2. Directory Structure

3. Key Module Descriptions

3.1 Server Entry Point (server.py)

3.2 Configuration Management (config.py)

3.3 Discord API Client (bot/)

3.3.1 REST API Client (client.py)

3.3.2 WebSocket Gateway (gateway.py)

3.4 Decision Request Management (decision/)

3.4.1 DecisionManager (manager.py)

3.4.2 DecisionPoller (poller.py)

3.4.3 Response Parser (parser.py)

3.4.4 State Store (state.py)

3.1 Server Entry Point (`server.py`)

3.2 Configuration Management (`config.py`)

3.3 Discord API Client (`bot/`)

3.3.1 REST API Client (`client.py`)

3.3.2 WebSocket Gateway (`gateway.py`)

3.4 Decision Request Management (`decision/`)

3.4.1 DecisionManager (`manager.py`)

3.4.2 DecisionPoller (`poller.py`)

3.4.3 Response Parser (`parser.py`)

3.4.4 State Store (`state.py`)

3.5 MCP Tools (`tools/`)

3.6 Watcher Daemon (`daemon/`)

3.6.1 DiscordWatcher (`watcher.py`)

3.6.2 InboxStore (`inbox.py`)