updates to the README.md#4
Open
groupthinking wants to merge 26 commits intoadd-workflows-20260128-072952from
Open
updates to the README.md#4groupthinking wants to merge 26 commits intoadd-workflows-20260128-072952from
README.md#4groupthinking wants to merge 26 commits intoadd-workflows-20260128-072952from
Conversation
Removed redundant text from the introduction section.
Removed duplicate steps for creating and storing the xAI / Grok API key.
Contributor
Summary of ChangesHello @groupthinking, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request focuses on improving the clarity and accessibility of the project's documentation. It refines the core description of the X agent's functionality and simplifies the process for users to acquire necessary API keys, making the setup process smoother for new contributors. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the README.md to clarify the project description and simplify API key instructions. My review focuses on improving clarity and consistency. I've pointed out a minor typo in the description and a formatting inconsistency in one of the instructional lists. Applying these suggestions will enhance the readability of the documentation.
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request updates the README.md to clarify the project description and simplify the xAI/Grok API key setup instructions. The description now emphasizes that the agent acts based on thread context and reasoning rather than just detecting mentions, and the API key instructions have been streamlined by removing the Premium+ subscription requirement.
Changes:
- Updated project description to better explain the agent's behavior as acting on context and reasoning
- Simplified xAI/Grok API key instructions by removing Premium+ subscription requirement
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
README.md
Outdated
| # MyXstack | ||
|
|
||
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that detects mentions, pulls thread context, and routes reasoning through Grok via the xMCP server. Follow the phases below to get from zero to a working "tag and watch" prototype. | ||
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that acts based on thread context & reasoning, through Grok via the xMCP server. |
There was a problem hiding this comment.
The phrasing "acts based on thread context & reasoning, through Grok via the xMCP server" is awkward and unclear. Consider rewording to something clearer like "that acts on thread context and reasoning through Grok via the xMCP server" or "that uses thread context and Grok reasoning via the xMCP server to take actions".
Suggested change
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that acts based on thread context & reasoning, through Grok via the xMCP server. | |
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that uses thread context and Grok reasoning via the xMCP server to take actions. |
README.md
Outdated
Comment on lines
23
to
24
| . Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | ||
| . Store the key securely. |
There was a problem hiding this comment.
The list items are using periods instead of numbers. Lines 23-24 should start with "1." and "2." respectively to maintain consistency with all other numbered lists in the README (see lines 8-20, 32-72, etc.). The current format with bare periods creates broken list formatting.
Suggested change
| . Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | |
| . Store the key securely. | |
| 1. Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | |
| 2. Store the key securely. |
README.md
Outdated
| # MyXstack | ||
|
|
||
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that detects mentions, pulls thread context, and routes reasoning through Grok via the xMCP server. Follow the phases below to get from zero to a working "tag and watch" prototype. | ||
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that acts based on thread context & reasoning, through Grok via the xMCP server. |
There was a problem hiding this comment.
There is an extra space between "that" and "acts". The text should read "agent system that acts" instead of "agent system that acts" (note the double space).
Suggested change
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that acts based on thread context & reasoning, through Grok via the xMCP server. | |
| This repository hosts a lightweight, step-by-step guide for setting up an autonomous X (Twitter) agent system that acts based on thread context & reasoning, through Grok via the xMCP server. |
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
README.md
Outdated
Comment on lines
23
to
24
| . Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | ||
| . Store the key securely. |
There was a problem hiding this comment.
The list items are missing their numbering prefixes. The lines should start with "1." and "2." instead of just "." to maintain proper markdown list formatting.
Suggested change
| . Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | |
| . Store the key securely. | |
| 1. Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | |
| 2. Store the key securely. |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
.github/workflows/pr-checks.yml
Outdated
| - name: Basic Syntax Check | ||
| run: | | ||
| echo "Running syntax validation..." | ||
| find . -name "*.js" -o -name "*.py" -o -name "*.ts" | xargs -I {} node -c {} || true |
There was a problem hiding this comment.
The syntax check command uses node -c to check JavaScript/TypeScript files, but this will fail for Python files. The command finds .js, .py, and .ts files but only validates them with Node.js. Python files should be checked with a Python syntax checker (like python -m py_compile), and the || true at the end silently ignores all errors, making this check ineffective. Consider separating the validation by file type or removing unsupported file types from the check.
Suggested change
| find . -name "*.js" -o -name "*.py" -o -name "*.ts" | xargs -I {} node -c {} || true | |
| js_ts_files=$(find . \( -name "*.js" -o -name "*.ts" \)) | |
| if [ -n "$js_ts_files" ]; then | |
| echo "$js_ts_files" | xargs -r -I {} node -c {} | |
| fi | |
| py_files=$(find . -name "*.py") | |
| if [ -n "$py_files" ]; then | |
| echo "$py_files" | xargs -r -I {} python -m py_compile {} | |
| fi |
Co-authored-by: groupthinking <154503486+groupthinking@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Bumps the npm_and_yarn group with 1 update in the / directory: [@modelcontextprotocol/sdk](https://github.com/modelcontextprotocol/typescript-sdk). Updates `@modelcontextprotocol/sdk` from 1.25.3 to 1.26.0 - [Release notes](https://github.com/modelcontextprotocol/typescript-sdk/releases) - [Commits](modelcontextprotocol/typescript-sdk@v1.25.3...v1.26.0) --- updated-dependencies: - dependency-name: "@modelcontextprotocol/sdk" dependency-version: 1.26.0 dependency-type: direct:production dependency-group: npm_and_yarn ... Signed-off-by: dependabot[bot] <support@github.com>
…260127 Merge pull request #3 from groupthinking/main
…_and_yarn-5277a85702 Bump @modelcontextprotocol/sdk from 1.25.3 to 1.26.0 in the npm_and_yarn group across 1 directory
…molt Add strategic analysis and competitive mapping of Molt AI agent platform
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Owner
Author
|
@copilot open a new pull request to apply changes based on the comments in this thread |
Contributor
|
@groupthinking I've opened a new pull request, #17, to work on those changes. Once the pull request is ready, I'll request review from you. |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+23
to
+24
| 1. Visit <https://console.x.ai>, open the API keys section, and create a key that starts with `xai-`. | ||
| 2. Store the key securely. |
There was a problem hiding this comment.
The list formatting is broken. The numbering has been replaced with periods instead of sequential numbers (1., 2., 3.). The xAI/Grok API key instructions should start with "1." not "." and continue with "2." not another "."
| "license": "MIT", | ||
| "dependencies": { | ||
| "@modelcontextprotocol/sdk": "^1.0.4", | ||
| "@modelcontextprotocol/sdk": "^1.26.0", |
There was a problem hiding this comment.
This PR is described as "updates to the README.md" but includes several unrelated changes: TypeScript type annotations in xapi.ts, a major version bump of @modelcontextprotocol/sdk (from ^1.0.4 to ^1.26.0), and three new GitHub workflow files. These changes should either be mentioned in the PR description or split into separate PRs for clarity and proper review.
| "license": "MIT", | ||
| "dependencies": { | ||
| "@modelcontextprotocol/sdk": "^1.0.4", | ||
| "@modelcontextprotocol/sdk": "^1.26.0", |
There was a problem hiding this comment.
The @modelcontextprotocol/sdk upgrade from ^1.0.4 to ^1.26.0 is a major version jump (25 minor versions). This significant upgrade includes breaking changes in transitive dependencies, notably hono which changed from a peer dependency to a direct dependency. This change should be tested thoroughly and documented in the PR description, as it may affect application behavior and require code changes to remain compatible.
| types: [opened] | ||
| jobs: | ||
| triage: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
This GitHub Actions workflow needs explicit permissions to add labels to issues. Without the permissions key, the workflow may fail with insufficient permissions. Add a permissions block to grant the necessary access: permissions: issues: write
Suggested change
| runs-on: ubuntu-latest | |
| runs-on: ubuntu-latest | |
| permissions: | |
| issues: write |
| pull_request: | ||
| types: [opened, reopened, synchronized] | ||
| jobs: | ||
| label: |
There was a problem hiding this comment.
This GitHub Actions workflow needs explicit permissions to add labels to pull requests. Without the permissions key, the workflow may fail with insufficient permissions. Add a permissions block to grant the necessary access: permissions: pull-requests: write
Suggested change
| label: | |
| label: | |
| permissions: | |
| pull-requests: write |
| } | ||
|
|
||
| private parseThread(tweets: any[]): XThread | null { | ||
| private parseThread(tweets: { created_at: string; [key: string]: any }[]): XThread | null { |
There was a problem hiding this comment.
Unexpected any. Specify a different type.
Suggested change
| private parseThread(tweets: { created_at: string; [key: string]: any }[]): XThread | null { | |
| private parseThread(tweets: { created_at: string; [key: string]: unknown }[]): XThread | null { |
Co-authored-by: groupthinking <154503486+groupthinking@users.noreply.github.com>
Update print statement from 'Hello' to 'Goodbye'
…uctions Add Copilot instructions for repository-specific code generation
Comment on lines
+1
to
+1075
| # Strategic Analysis: Molt (Moltbot) AI Agent Platform | ||
| ## Comprehensive Teardown & Competitive Mapping | ||
|
|
||
| **Analysis Date:** January 29, 2026 | ||
| **Platform:** Molt.bot (formerly Clawdbot) | ||
| **Official Site:** https://www.molt.bot/ | ||
| **GitHub:** https://github.com/moltbot/moltbot | ||
|
|
||
| --- | ||
|
|
||
| ## Executive Summary | ||
|
|
||
| Molt (Moltbot) is an open-source, self-hosted AI agent platform that has rapidly emerged as a disruptive force in the personal and enterprise automation space. Rebranded from Clawdbot in early 2026 following a trademark dispute, Molt distinguishes itself through its **privacy-first, local-execution model** and **deep system integration capabilities**. With 60,000-100,000 GitHub stars and an estimated 300,000-400,000 worldwide users, Molt represents a significant market shift toward user-controlled, privacy-preserving AI agents. | ||
|
|
||
| **Key Differentiators:** | ||
| - Fully self-hosted with local-first architecture | ||
| - Multi-platform messaging integration (13+ platforms) | ||
| - Real action execution (shell commands, file operations, browser automation) | ||
| - Proactive, autonomous agent behavior | ||
| - Open-source with MIT license and active community (130-300+ contributors) | ||
| - Model-agnostic architecture supporting multiple LLM providers | ||
|
|
||
| **Market Position:** Molt occupies a unique niche between traditional cloud-based AI assistants (ChatGPT, Claude) and enterprise agent frameworks (LangChain, CrewAI), targeting privacy-conscious power users, developers, and organizations requiring data sovereignty. | ||
|
|
||
| --- | ||
|
|
||
| ## 1. Core Features Analysis | ||
|
|
||
| ### 1.1 Platform Architecture | ||
|
|
||
| Molt employs a sophisticated gateway-based architecture built entirely in TypeScript/Node.js: | ||
|
|
||
| **Gateway Control Plane:** | ||
| - Single supervised daemon (systemd/launchd) orchestrating all operations | ||
| - Default port: 18789 (WebSocket/HTTP) | ||
| - Centralized routing for all messaging channels | ||
| - Unified session and state management | ||
|
|
||
| **Source:** [DeepWiki - Moltbot Architecture](https://deepwiki.com/moltbot/moltbot) | ||
|
|
||
| **Agent Runtime Engine:** | ||
| - Sandboxed agent execution with isolated workspaces | ||
| - Per-agent configuration for models, skills, and permissions | ||
| - Multi-agent orchestration with parallel operation support | ||
| - Persistent cross-session memory | ||
|
|
||
| **Source:** [Molt.bot Documentation - Multi-Agent Routing](https://docs.molt.bot/concepts/multi-agent) | ||
|
|
||
| **Messaging Integration Layer:** | ||
| - 13+ platform plugins: WhatsApp (Baileys), Telegram (grammY), Discord (discord.js), Slack (Bolt SDK), iMessage, Signal, Matrix, WebChat, CLI | ||
| - Modular plugin architecture (`src/plugins/`) | ||
| - User/channel-based routing for multi-tenant scenarios | ||
|
|
||
| **Source:** [Moltbot GitHub Repository](https://github.com/moltbot/moltbot) | ||
|
|
||
| ### 1.2 Feature Set | ||
|
|
||
| | Feature Category | Capabilities | Implementation | | ||
| |-----------------|--------------|----------------| | ||
| | **Multi-Platform Integration** | WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Teams, Matrix, WebChat, CLI | Native adapters with platform-specific SDKs | | ||
| | **Action Execution** | Shell commands, file operations, email sending, calendar management, browser automation, form filling | Secure sandbox with permission-based execution | | ||
| | **Memory & Context** | Persistent long-term memory, cross-session continuity, preference tracking, relationship mapping | Local storage (~/.moltbot) with searchable history | | ||
| | **Proactive Behavior** | Autonomous reminders, scheduled tasks, background automation, initiated conversations | Cron-style scheduling with event triggers | | ||
| | **Multi-Agent Support** | Parallel agent operation, persona isolation, role-based routing | Workspace isolation (~/clawd-*) per agent | | ||
| | **Model Flexibility** | OpenAI, Anthropic, Google Gemini, Ollama (local), custom LLMs | Pluggable provider architecture | | ||
| | **Skills/Plugins** | 565+ community skills via ClawdHub marketplace | JavaScript/TypeScript extensibility | | ||
| | **OS Support** | macOS, Linux, Windows (WSL2), Raspberry Pi | Cross-platform Node.js runtime | | ||
|
|
||
| **Sources:** | ||
| - [Molt.bot Official Site](https://www.molt.bot/) | ||
| - [DEV Community - Moltbot Guide](https://dev.to/czmilo/moltbot-the-ultimate-personal-ai-assistant-guide-for-2026-d4e) | ||
| - [Metana - Moltbot Overview](https://metana.io/blog/what-is-moltbot-everything-you-need-to-know-in-2026/) | ||
|
|
||
| ### 1.3 Technical Stack | ||
|
|
||
| **Core Technologies:** | ||
| - **Language:** TypeScript/Node.js (100%) | ||
| - **Messaging Adapters:** | ||
| - WhatsApp: Baileys library | ||
| - Telegram: grammY framework | ||
| - Discord: discord.js | ||
| - Slack: Bolt SDK | ||
| - iMessage: BlueBubbles (Swift on macOS) | ||
| - **Configuration:** JSON5 format (~/.clawdbot/clawdbot.json) | ||
| - **Storage:** File-system based, local directory structure | ||
| - **Execution:** Native shell integration, sandboxed tool runner | ||
| - **Protocol:** WebSocket/HTTP API for agent communication | ||
|
|
||
| **Source:** [Moltbot GitHub - Technical Stack](https://github.com/moltbot/moltbot) | ||
|
|
||
| --- | ||
|
|
||
| ## 2. User-Facing Functionality | ||
|
|
||
| ### 2.1 Use Cases | ||
|
|
||
| **Personal Productivity:** | ||
| - Automated task management and reminders | ||
| - Cross-platform message consolidation | ||
| - Email and calendar management | ||
| - File organization and retrieval | ||
| - Research assistance with web browsing | ||
|
|
||
| **Source:** [Hostinger - What is Moltbot](https://www.hostinger.com/tutorials/what-is-moltbot) | ||
|
|
||
| **Developer Workflows:** | ||
| - Code review and documentation generation | ||
| - Repository management and CI/CD integration | ||
| - API testing and monitoring | ||
| - Development environment automation | ||
| - Log analysis and debugging assistance | ||
|
|
||
| **Source:** [Analytics Vidhya - Clawdbot Guide](https://www.analyticsvidhya.com/blog/2026/01/clawdbot-guide/) | ||
|
|
||
| **Enterprise Applications:** | ||
| - Knowledge base management | ||
| - Compliance and audit trail generation | ||
| - Process automation across departments | ||
| - Secure inter-team communication | ||
| - Document workflow orchestration | ||
|
|
||
| **Source:** [AI Multiple - Moltbot Use Cases](https://research.aimultiple.com/moltbot/) | ||
|
|
||
| ### 2.2 User Experience | ||
|
|
||
| **Setup Complexity:** High - Requires technical knowledge for initial configuration | ||
| **Learning Curve:** Medium to steep - Configuration-heavy but well-documented | ||
| **Customization:** Extensive - Full access to source code and plugin system | ||
| **Maintenance:** User-managed - Self-hosting requires ongoing updates and security management | ||
|
|
||
| **Strengths:** | ||
| - Complete control and transparency | ||
| - No vendor lock-in | ||
| - Unlimited customization potential | ||
| - Privacy preservation | ||
|
|
||
| **Weaknesses:** | ||
| - Technical expertise required | ||
| - Self-managed security burden | ||
| - Complex initial setup | ||
| - Ongoing maintenance overhead | ||
|
|
||
| **Source:** [CurateClick - Moltbot Complete Guide](https://curateclick.com/blog/2026-moltbot-complete-guide) | ||
|
|
||
| --- | ||
|
|
||
| ## 3. Go-To-Market (GTM) Strategy | ||
|
|
||
| ### 3.1 Target Audience Analysis | ||
|
|
||
| **Primary Segments:** | ||
|
|
||
| 1. **Privacy-Conscious Power Users** (40% of user base) | ||
| - Technical literacy: High | ||
| - Primary concerns: Data sovereignty, vendor lock-in | ||
| - Willingness to self-host: High | ||
| - Value proposition: Complete control over data and AI agent | ||
|
|
||
| 2. **Developers and Technical Teams** (35% of user base) | ||
| - Use case: Development workflow automation | ||
| - Integration needs: GitHub, Slack, development tools | ||
| - Customization requirements: High | ||
| - Value proposition: Extensible, programmable assistant | ||
|
|
||
| 3. **Small to Medium Enterprises** (20% of user base) | ||
| - Privacy requirements: Regulatory compliance (GDPR, HIPAA) | ||
| - Budget constraints: Cost-conscious | ||
| - IT capability: In-house technical teams | ||
| - Value proposition: Self-hosted alternative to cloud services | ||
|
|
||
| 4. **Early Adopters and Enthusiasts** (5% of user base) | ||
| - Motivation: Cutting-edge technology experimentation | ||
| - Community participation: High | ||
| - Contribution potential: Plugin development, bug reports | ||
| - Value proposition: Participation in open-source innovation | ||
|
|
||
| **Source:** [Macaron - Is Moltbot Free](https://macaron.im/blog/is-moltbot-free-cost) | ||
|
|
||
| ### 3.2 GTM Approach | ||
|
|
||
| **Current Strategy: Community-Led, Bottom-Up Growth** | ||
|
|
||
| **Distribution Channels:** | ||
| 1. **GitHub Repository** - Primary distribution (60,000-100,000 stars) | ||
| 2. **Developer Communities** - DEV.to, Reddit, Hacker News | ||
| 3. **Discord Server** - 8,900+ active members | ||
| 4. **ClawdHub Marketplace** - 565+ community plugins | ||
| 5. **Technical Documentation** - Comprehensive setup guides | ||
|
|
||
| **Growth Tactics:** | ||
| - Open-source collaboration and contribution | ||
| - Community-driven feature development | ||
| - Viral social media presence (X/Twitter, Reddit) | ||
| - Technical content marketing (blog posts, tutorials) | ||
| - Developer advocacy and education | ||
|
|
||
| **Source:** [Moltbot Official Documentation](https://docs.molt.bot/) | ||
|
|
||
| ### 3.3 Marketing Positioning | ||
|
|
||
| **Value Propositions:** | ||
|
|
||
| | Segment | Primary Message | Secondary Benefits | | ||
| |---------|----------------|-------------------| | ||
| | Privacy Users | "Your data, your control, your AI" | No cloud dependencies, full transparency | | ||
| | Developers | "Build your perfect AI assistant" | Extensible, programmable, open-source | | ||
| | Enterprises | "Enterprise AI without the cloud" | Compliance-friendly, cost-effective, secure | | ||
| | Enthusiasts | "Join the AI agent revolution" | Community-driven, cutting-edge technology | | ||
|
|
||
| **Competitive Positioning:** | ||
| - **vs. ChatGPT/Claude:** Privacy-first, self-hosted alternative | ||
| - **vs. LangChain/CrewAI:** End-user focused with multi-platform integration | ||
| - **vs. Commercial Assistants:** Open-source, no subscription fees, unlimited customization | ||
|
|
||
| **Sources:** | ||
| - [FelloAI - Moltbot Overview](https://felloai.com/moltbot-complete-overview/) | ||
| - [Growth Jockey - Moltbot Guide](https://www.growthjockey.com/blogs/clawdbot-moltbot) | ||
|
|
||
| --- | ||
|
|
||
| ## 4. Investment & Monetization Model | ||
|
|
||
| ### 4.1 Current Business Model | ||
|
|
||
| **Open-Source Foundation:** | ||
| - MIT License - Completely free to use, modify, and distribute | ||
| - No direct revenue from core software | ||
| - Community-driven development | ||
|
|
||
| **True Cost Structure:** | ||
|
|
||
| | Cost Component | Monthly Estimate | Notes | | ||
| |----------------|-----------------|-------| | ||
| | LLM API Costs | $15-40 | Claude/GPT-4 usage-based | | ||
| | Hosting | $5-10 | Local hardware or VPS | | ||
| | Setup Time | ~8-12 hours | One-time investment | | ||
| | Maintenance | ~2-4 hours/month | Updates, troubleshooting | | ||
|
|
||
| **Total Monthly Cost:** $20-50 + time investment | ||
|
|
||
| **Source:** [Macaron - Moltbot True Cost Breakdown](https://macaron.im/blog/is-moltbot-free-cost) | ||
|
|
||
| ### 4.2 Potential Monetization Strategies | ||
|
|
||
| Based on industry analysis of similar open-source AI platforms: | ||
|
|
||
| **1. Freemium Model with Premium Features** | ||
| - Free: Core self-hosted version | ||
| - Premium: Enhanced skills, priority support, managed updates | ||
| - Pricing: $10-30/user/month | ||
|
|
||
| **2. Managed Hosting Service** | ||
| - Fully managed Molt instances | ||
| - Enterprise-grade security and compliance | ||
| - SLA-backed uptime guarantees | ||
| - Pricing: $50-200/agent/month | ||
|
|
||
| **3. Enterprise Licensing** | ||
| - Advanced security features | ||
| - Dedicated support channels | ||
| - Custom integration development | ||
| - Training and onboarding services | ||
| - Pricing: $10,000-50,000 annual contracts | ||
|
|
||
| **4. Marketplace Revenue Share** | ||
| - ClawdHub plugin marketplace | ||
| - 20-30% commission on paid plugins | ||
| - Certified partner program | ||
|
|
||
| **5. Professional Services** | ||
| - Custom integration development | ||
| - Security auditing and hardening | ||
| - Training and workshops | ||
| - Consulting for enterprise deployments | ||
|
|
||
| **Sources:** | ||
| - [Orb - AI Monetization Strategies](https://www.withorb.com/blog/ai-monetization) | ||
| - [UserPilot - AI SaaS Monetization](https://userpilot.com/blog/ai-saas-monetization/) | ||
| - [Alguna - AI Monetization Platforms](https://blog.alguna.com/ai-monetization-platform/) | ||
|
|
||
| ### 4.3 Investment Landscape | ||
|
|
||
| **Funding Status:** No public information on venture funding (as of January 2026) | ||
|
|
||
| **Likely Funding Strategy:** | ||
| - Bootstrap phase via community contributions | ||
| - Potential future VC interest given rapid growth metrics: | ||
| - 60,000-100,000 GitHub stars (top 0.1% of projects) | ||
| - 300,000-400,000 estimated users | ||
| - High engagement (8,900+ Discord members) | ||
| - Strong developer advocacy | ||
|
|
||
| **VC Appeal Factors:** | ||
| - Large addressable market (privacy-conscious enterprise segment) | ||
| - Strong technical moat (comprehensive platform) | ||
| - Network effects (plugin marketplace, community) | ||
| - Clear enterprise upsell path | ||
| - Defensible positioning (local-first architecture) | ||
|
|
||
| **Sources:** | ||
| - [Morgan Stanley - AI Monetization Race to ROI](https://www.morganstanley.com/insights/articles/ai-monetization-race-to-roi-tmt) | ||
| - [StartupTalky - Monetizing AI Business Models](https://startuptalky.com/monetizing-ai-business-models/) | ||
|
|
||
| --- | ||
|
|
||
| ## 5. Competitive Landscape Analysis | ||
|
|
||
| ### 5.1 Direct Competitors | ||
|
|
||
| #### 5.1.1 LangChain / LangGraph | ||
|
|
||
| **Positioning:** Developer framework for building LLM-powered applications | ||
|
|
||
| **Feature Comparison:** | ||
|
|
||
| | Dimension | Molt | LangChain/LangGraph | | ||
| |-----------|------|---------------------| | ||
| | **Target User** | End-users, power users | Developers, engineers | | ||
| | **Setup Complexity** | High (self-host) | High (code-first) | | ||
| | **Out-of-box Functionality** | High (full agent system) | Low (framework only) | | ||
| | **Customization** | Plugin-based | Code-level | | ||
| | **Multi-platform Chat** | Native (13+ platforms) | Requires custom integration | | ||
| | **Deployment** | Self-hosted | Flexible (cloud or local) | | ||
| | **Memory Management** | Built-in persistent | Developer-implemented | | ||
| | **Agent Orchestration** | Gateway-based | Graph-based workflows | | ||
|
|
||
| **Molt Advantages:** | ||
| - Pre-built agent system ready to use | ||
| - Native multi-platform messaging | ||
| - End-user focused interface | ||
| - Persistent memory out-of-box | ||
|
|
||
| **LangChain Advantages:** | ||
| - Maximum flexibility for developers | ||
| - Extensive ecosystem integrations | ||
| - Production-grade tooling | ||
| - Enterprise adoption and support | ||
|
|
||
| **Sources:** | ||
| - [AgentFrame Guide - LangChain vs CrewAI](https://agentframe.guide/blog/langchain-vs-crewai-complete-comparison-features-pros-cons/) | ||
| - [SelectHub - LangChain vs CrewAI](https://www.selecthub.com/ai-agent-framework-tools/langchain-vs-crewai/) | ||
|
|
||
| #### 5.1.2 CrewAI | ||
|
|
||
| **Positioning:** Multi-agent orchestration framework built on LangChain | ||
|
|
||
| **Feature Comparison:** | ||
|
|
||
| | Dimension | Molt | CrewAI | | ||
| |-----------|------|--------| | ||
| | **Agent Model** | Multi-agent gateway | Role-based teams | | ||
| | **Workflow Design** | Message-driven | Task-driven | | ||
| | **User Interface** | Multi-platform chat | API/code-first | | ||
| | **Collaboration** | Platform-based | Agent-to-agent | | ||
| | **Learning Curve** | Moderate (config-heavy) | Low (declarative) | | ||
| | **Memory** | Persistent, cross-session | Per-task context | | ||
| | **Action Scope** | System-wide (shell, files) | Framework-defined tools | | ||
| | **Privacy Model** | Local-first | Deployment-dependent | | ||
|
|
||
| **Molt Advantages:** | ||
| - True end-user product (not just framework) | ||
| - Multi-platform messaging built-in | ||
| - Local-first privacy by design | ||
| - System-level automation capabilities | ||
|
|
||
| **CrewAI Advantages:** | ||
| - Simpler for team-based workflows | ||
| - Better documentation for developers | ||
| - Explicit task delegation model | ||
| - Lower barrier to entry for AI workflows | ||
|
|
||
| **Sources:** | ||
| - [Leanware - LangChain vs CrewAI](https://www.leanware.co/insights/langchain-vs-crewai) | ||
| - [DataCamp - CrewAI vs LangGraph vs AutoGen](https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen) | ||
|
|
||
| #### 5.1.3 LlamaIndex | ||
|
|
||
| **Positioning:** Data-centric framework for RAG and knowledge management | ||
|
|
||
| **Feature Comparison:** | ||
|
|
||
| | Dimension | Molt | LlamaIndex | | ||
| |-----------|------|------------| | ||
| | **Primary Focus** | General-purpose agent | Document/knowledge workflows | | ||
| | **RAG Capabilities** | Basic (plugin-based) | Advanced (core competency) | | ||
| | **Data Connectors** | Standard integrations | 100+ data sources | | ||
| | **Use Case** | Personal automation | Enterprise knowledge management | | ||
| | **Document Processing** | Basic | Advanced (parsing, chunking, indexing) | | ||
| | **Messaging Integration** | Native (13+ platforms) | Not included | | ||
| | **Query Types** | Conversational | QA, search, retrieval | | ||
| | **Deployment Model** | Self-hosted mandatory | Flexible | | ||
|
|
||
| **Molt Advantages:** | ||
| - Broader automation scope beyond documents | ||
| - Multi-platform communication | ||
| - Proactive agent behavior | ||
| - System integration (shell, files) | ||
|
|
||
| **LlamaIndex Advantages:** | ||
| - Superior document processing | ||
| - Extensive data source connectors | ||
| - Production RAG pipelines | ||
| - Enterprise knowledge management focus | ||
|
|
||
| **Sources:** | ||
| - [DataCamp - Best AI Agents](https://www.datacamp.com/blog/best-ai-agents) | ||
| - [Genta Dev - Best AI Agent Frameworks](https://genta.dev/resources/best-ai-agent-frameworks-2026) | ||
|
|
||
| ### 5.2 Adjacent Competitors | ||
|
|
||
| #### 5.2.1 Cognosys | ||
|
|
||
| **Positioning:** Enterprise workflow automation platform | ||
|
|
||
| **Comparison:** | ||
| - **Molt:** Local-first, user-controlled, privacy-focused | ||
| - **Cognosys:** Cloud-based, enterprise workflow automation, SaaS model | ||
| - **Target:** Cognosys targets large enterprises; Molt targets privacy-conscious users and SMBs | ||
|
|
||
| **Sources:** [AlphaMatch - Top Agentic AI Frameworks](https://www.alphamatch.ai/blog/top-agentic-ai-frameworks-2026) | ||
|
|
||
| #### 5.2.2 BerriAI | ||
|
|
||
| **Positioning:** API-first platform for custom conversational agents | ||
|
|
||
| **Comparison:** | ||
| - **Molt:** Comprehensive self-hosted system | ||
| - **BerriAI:** Rapid deployment of custom RAG agents via API | ||
| - **Differentiation:** BerriAI focuses on developer experience and quick deployment; Molt emphasizes privacy and system integration | ||
|
|
||
| **Sources:** [Turing - AI Agent Frameworks Comparison](https://www.turing.com/resources/ai-agent-frameworks) | ||
|
|
||
| #### 5.2.3 AutoGen (Microsoft) | ||
|
|
||
| **Positioning:** Conversation-centric multi-agent framework | ||
|
|
||
| **Comparison:** | ||
| - **Molt:** Message-platform focused, end-user oriented | ||
| - **AutoGen:** Dialog-based, developer-focused, human-in-loop | ||
| - **Strength:** AutoGen excels in iterative coding and planning tasks; Molt excels in real-world automation | ||
|
|
||
| **Sources:** | ||
| - [Smiansh - LangChain vs AutoGen vs CrewAI](https://www.smiansh.com/blogs/langchain-agents-vs-autogen-vs-crewai-comparison/) | ||
| - [Sider AI - Best CrewAI Alternatives](https://sider.ai/blog/ai-tools/best-crewai-alternatives-for-multi-agent-ai-in-2025) | ||
|
|
||
| ### 5.3 Cloud-Based AI Assistants | ||
|
|
||
| #### Commercial Comparison | ||
|
|
||
| | Platform | Deployment | Privacy | Cost Model | Customization | System Access | | ||
| |----------|-----------|---------|------------|---------------|---------------| | ||
| | **Molt** | Self-hosted | Maximum | LLM API only | Full (open-source) | Complete (shell, files) | | ||
| | **ChatGPT** | Cloud | Limited | $20/month | Minimal (GPTs) | None | | ||
| | **Claude** | Cloud | Limited | Usage-based | Minimal | None | | ||
| | **GitHub Copilot** | Cloud | Limited | $10/month | Minimal | IDE only | | ||
| | **Google Assistant** | Cloud | Minimal | Free | None | Limited (Google services) | | ||
|
|
||
| **Molt's Unique Position:** | ||
| - Only self-hosted, privacy-first option | ||
| - Complete system integration capabilities | ||
| - Open-source with full customization | ||
| - Multi-platform messaging consolidation | ||
| - No subscription fees (only LLM API costs) | ||
|
|
||
| **Sources:** | ||
| - [PCMag - Clawdbot Safety Analysis](https://www.pcmag.com/news/clawdbot-now-moltbot-is-hot-new-ai-agent-safe-to-use-or-risky) | ||
| - [AICYBR - Moltbot Guide](https://aicybr.com/blog/moltbot-guide) | ||
|
|
||
| --- | ||
|
|
||
| ## 6. Gap Analysis: Where Molt Differs, Matches, and Falls Short | ||
|
|
||
| ### 6.1 Unique Differentiators (Where Molt Wins) | ||
|
|
||
| **1. Privacy-First Architecture** | ||
| - **Status:** ✅ Market Leader | ||
| - **Evidence:** Only major platform with mandatory self-hosting | ||
| - **Impact:** Appeals to privacy-conscious users, regulated industries, and data sovereignty requirements | ||
| - **Source:** [Hostinger - What is Moltbot](https://www.hostinger.com/tutorials/what-is-moltbot) | ||
|
|
||
| **2. Multi-Platform Messaging Integration** | ||
| - **Status:** ✅ Unique Capability | ||
| - **Evidence:** Native support for 13+ messaging platforms (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, etc.) | ||
| - **Impact:** Unified communication interface across all channels | ||
| - **Source:** [Molt.bot Official Site](https://www.molt.bot/) | ||
|
|
||
| **3. System-Level Action Execution** | ||
| - **Status:** ✅ Advanced Capability | ||
| - **Evidence:** Shell command execution, file system operations, browser automation, email management | ||
| - **Impact:** True automation beyond conversational AI | ||
| - **Source:** [DEV Community - Moltbot Guide](https://dev.to/czmilo/moltbot-the-ultimate-personal-ai-assistant-guide-for-2026-d4e) | ||
|
|
||
| **4. Proactive Agent Behavior** | ||
| - **Status:** ✅ Distinguishing Feature | ||
| - **Evidence:** Autonomous reminders, scheduled tasks, initiated conversations | ||
| - **Impact:** Moves beyond reactive chatbot to proactive assistant | ||
| - **Source:** [Molt-bot.io - Personal AI Assistant](https://molt-bot.io/) | ||
|
|
||
| **5. Open-Source with Active Community** | ||
| - **Status:** ✅ Strong Ecosystem | ||
| - **Evidence:** 60,000-100,000 GitHub stars, 130-300+ contributors, 8,900+ Discord members, 565+ plugins | ||
| - **Impact:** Rapid innovation, community-driven features, no vendor lock-in | ||
| - **Source:** [GitHub - Moltbot Repository](https://github.com/moltbot/moltbot) | ||
|
|
||
| ### 6.2 Competitive Parity (Where Molt Matches) | ||
|
|
||
| **1. LLM Integration** | ||
| - **Status:** ⚖️ Industry Standard | ||
| - **Evidence:** Supports OpenAI, Anthropic, Google, Ollama (same as competitors) | ||
| - **Assessment:** No differentiation; follows industry patterns | ||
| - **Source:** [Sterlites - Moltbot Local-First Guide](https://sterlites.com/blog/moltbot-local-first-ai-agents-guide-2026) | ||
|
|
||
| **2. Memory and Context Management** | ||
| - **Status:** ⚖️ Comparable | ||
| - **Evidence:** Persistent memory, session continuity (similar to LangChain, CrewAI implementations) | ||
| - **Assessment:** Solid implementation but not innovative | ||
| - **Source:** [Metana - Moltbot Open-Source Guide](https://metana.io/blog/moltbot-the-open-source-personal-ai-assistant-thats-taking-over-in-2026/) | ||
|
|
||
| **3. Plugin/Extensibility System** | ||
| - **Status:** ⚖️ Standard Approach | ||
| - **Evidence:** JavaScript/TypeScript plugins (similar to other frameworks) | ||
| - **Assessment:** Good but not unique; marketplace size growing | ||
| - **Source:** [Moltbot.you - Official Project Site](https://moltbot.you/) | ||
|
|
||
| ### 6.3 Gaps and Weaknesses (Where Molt Falls Short) | ||
|
|
||
| **1. Enterprise-Grade Features** | ||
| - **Status:** ❌ Significant Gap | ||
| - **Missing:** RBAC, SSO integration, audit logging, enterprise SLA, professional support | ||
| - **Competitor Advantage:** LangChain, Cognosys, commercial platforms have mature enterprise offerings | ||
| - **Impact:** Limits adoption by large organizations | ||
| - **Mitigation Path:** Enterprise edition with security hardening and support | ||
| - **Sources:** | ||
| - [OX Security - Moltbot Data Breach Analysis](https://www.ox.security/blog/one-step-away-from-a-massive-data-breach-what-we-found-inside-moltbot/) | ||
| - [Collabnix - Moltbot Security Guide](https://collabnix.com/securing-moltbot-a-developers-guide-to-ai-agent-security/) | ||
|
|
||
| **2. Security Model** | ||
| - **Status:** ⚠️ High Risk | ||
| - **Issues:** | ||
| - Elevated system access (shell, files) creates large attack surface | ||
| - Prompt injection vulnerabilities | ||
| - Credential exposure risks (hundreds of misconfigurations found publicly) | ||
| - Network exposure concerns | ||
| - **Competitor Advantage:** Sandboxed cloud environments with professional security teams | ||
| - **Impact:** Deters security-conscious enterprises | ||
| - **Mitigation Path:** Security-focused fork, professional security audits, managed service option | ||
| - **Sources:** | ||
| - [Snyk - Clawdbot Security Analysis](https://snyk.io/articles/clawdbot-ai-assistant/) | ||
| - [The Register - Clawdbot Security Concerns](https://www.theregister.com/2026/01/27/clawdbot_moltbot_security_concerns/) | ||
| - [BleepingComputer - Moltbot Data Security Concerns](https://www.bleepingcomputer.com/news/security/viral-moltbot-ai-assistant-raises-concerns-over-data-security/) | ||
|
|
||
| **3. User Experience** | ||
| - **Status:** ❌ Barrier to Entry | ||
| - **Issues:** | ||
| - Complex setup process (8-12 hours) | ||
| - Requires technical expertise | ||
| - Limited GUI/dashboard | ||
| - Maintenance burden | ||
| - **Competitor Advantage:** Cloud services offer instant signup and zero configuration | ||
| - **Impact:** Limits addressable market to technical users | ||
| - **Mitigation Path:** Managed hosting service, simplified installation, web dashboard | ||
| - **Source:** [CurateClick - Moltbot Complete Guide](https://curateclick.com/blog/2026-moltbot-complete-guide) | ||
|
|
||
| **4. Documentation and Onboarding** | ||
| - **Status:** ⚖️ Adequate but Inconsistent | ||
| - **Issues:** | ||
| - Community-driven docs with quality variation | ||
| - Limited video tutorials | ||
| - Fragmented across multiple sources | ||
| - Rapid changes cause doc drift | ||
| - **Competitor Advantage:** Professional documentation teams (LangChain, Anthropic) | ||
| - **Impact:** Increases time-to-value for new users | ||
| - **Mitigation Path:** Centralized documentation, video series, interactive tutorials | ||
|
|
||
| **5. Production Readiness** | ||
| - **Status:** ⚠️ Developer Preview Quality | ||
| - **Issues:** | ||
| - No official SLA or uptime guarantees | ||
| - Community support only | ||
| - Breaking changes between versions | ||
| - Limited monitoring/observability tools | ||
| - **Competitor Advantage:** Enterprise platforms offer production SLAs and support | ||
| - **Impact:** Unsuitable for mission-critical applications | ||
| - **Mitigation Path:** Stability commitment, professional support tiers, monitoring tools | ||
|
|
||
| **6. RAG and Knowledge Management** | ||
| - **Status:** ❌ Basic Capabilities | ||
| - **Missing:** Advanced document processing, semantic search, vector store optimization, citation tracking | ||
| - **Competitor Advantage:** LlamaIndex has purpose-built RAG infrastructure | ||
| - **Impact:** Less suitable for knowledge-intensive use cases | ||
| - **Mitigation Path:** Integrate LlamaIndex as backend, develop advanced RAG plugins | ||
|
|
||
| **7. Analytics and Insights** | ||
| - **Status:** ❌ Minimal | ||
| - **Missing:** Usage analytics, performance metrics, conversation analytics, cost tracking | ||
| - **Competitor Advantage:** Commercial platforms offer comprehensive analytics | ||
| - **Impact:** Difficult to optimize and demonstrate value | ||
| - **Mitigation Path:** Analytics plugin, dashboard development | ||
|
|
||
| **8. Compliance and Governance** | ||
| - **Status:** ❌ User-Managed | ||
| - **Missing:** Built-in compliance frameworks (GDPR, HIPAA, SOC2), policy enforcement, data retention controls | ||
| - **Competitor Advantage:** Enterprise platforms have certification and compliance features | ||
| - **Impact:** Requires manual compliance implementation | ||
| - **Mitigation Path:** Compliance toolkit, certified deployment guides | ||
|
|
||
| --- | ||
|
|
||
| ## 7. SWOT Analysis | ||
|
|
||
| ### Strengths | ||
|
|
||
| 1. **Privacy-First Architecture** | ||
| - Self-hosted with complete data control | ||
| - No third-party data sharing | ||
| - Attractive to regulated industries | ||
|
|
||
| 2. **Multi-Platform Integration** | ||
| - 13+ messaging platforms natively supported | ||
| - Unified communication interface | ||
| - Unique competitive advantage | ||
|
|
||
| 3. **Open-Source Community** | ||
| - 60,000-100,000 GitHub stars | ||
| - Active contributor base (130-300+) | ||
| - Rapid innovation and feature development | ||
|
|
||
| 4. **System-Level Capabilities** | ||
| - Shell command execution | ||
| - File system operations | ||
| - Browser automation | ||
| - True action-oriented agent | ||
|
|
||
| 5. **Model Agnostic** | ||
| - Supports multiple LLM providers | ||
| - Flexibility for cost optimization | ||
| - No vendor lock-in | ||
|
|
||
| 6. **Cost Efficiency** | ||
| - No subscription fees | ||
| - Pay only for LLM API usage | ||
| - Open-source with no licensing costs | ||
|
|
||
| ### Weaknesses | ||
|
|
||
| 1. **High Technical Barrier** | ||
| - Complex setup (8-12 hours) | ||
| - Requires self-hosting infrastructure | ||
| - Ongoing maintenance burden | ||
|
|
||
| 2. **Security Risks** | ||
| - Large attack surface (shell access) | ||
| - Prompt injection vulnerabilities | ||
| - Misconfiguration risks (exposed instances) | ||
|
|
||
| 3. **No Professional Support** | ||
| - Community support only | ||
| - No SLA or uptime guarantees | ||
| - Limited accountability | ||
|
|
||
| 4. **Limited Enterprise Features** | ||
| - No RBAC, SSO, or audit logging | ||
| - Lacks compliance certifications | ||
| - No centralized management | ||
|
|
||
| 5. **Documentation Gaps** | ||
| - Inconsistent quality across sources | ||
| - Rapid changes cause drift | ||
| - Limited video/interactive tutorials | ||
|
|
||
| 6. **Production Readiness Concerns** | ||
| - Breaking changes between versions | ||
| - Limited monitoring tools | ||
| - Unsuitable for mission-critical use | ||
|
|
||
| ### Opportunities | ||
|
|
||
| 1. **Enterprise Edition** | ||
| - Add RBAC, SSO, audit logging | ||
| - Offer professional support | ||
| - Target regulated industries | ||
| - Potential: $10-50K annual contracts | ||
|
|
||
| 2. **Managed Hosting Service** | ||
| - Eliminate setup complexity | ||
| - Professional security management | ||
| - SLA-backed reliability | ||
| - Potential: $50-200/agent/month | ||
|
|
||
| 3. **Marketplace Revenue** | ||
| - ClawdHub plugin economy | ||
| - 20-30% commission model | ||
| - Certified partner program | ||
|
|
||
| 4. **Security Hardening** | ||
| - Professional security audits | ||
| - Certified deployment guides | ||
| - Security-focused fork | ||
| - Compliance toolkit | ||
|
|
||
| 5. **Vertical Solutions** | ||
| - Healthcare (HIPAA-compliant agent) | ||
| - Finance (SOC2/PCI certified) | ||
| - Legal (privilege management) | ||
| - Government (FedRAMP pathway) | ||
|
|
||
| 6. **Integration Partnerships** | ||
| - Pre-built connectors with major SaaS platforms | ||
| - OEM partnerships with DevOps tools | ||
| - API marketplace integrations | ||
|
|
||
| 7. **AI Agent Ecosystem Leadership** | ||
| - Define standards for local-first AI | ||
| - Build community around privacy-preserving AI | ||
| - Thought leadership in data sovereignty | ||
|
|
||
| ### Threats | ||
|
|
||
| 1. **Security Incidents** | ||
| - Publicized breaches could damage reputation | ||
| - Malicious plugins in marketplace | ||
| - Supply chain attacks on dependencies | ||
|
|
||
| 2. **Cloud Platform Feature Parity** | ||
| - ChatGPT/Claude adding action capabilities | ||
| - Cloud providers offering "private deployments" | ||
| - Managed LLM services reducing self-host advantages | ||
|
|
||
| 3. **Enterprise Framework Evolution** | ||
| - LangChain/CrewAI adding end-user interfaces | ||
| - Commercial wrappers around existing frameworks | ||
| - Better documentation and onboarding from competitors | ||
|
|
||
| 4. **Regulatory Challenges** | ||
| - Liability for autonomous agent actions | ||
| - Compliance requirements for AI agents | ||
| - Intellectual property concerns | ||
|
|
||
| 5. **Technical Debt** | ||
| - Rapid growth leading to code quality issues | ||
| - Breaking changes alienating users | ||
| - Difficulty maintaining backwards compatibility | ||
|
|
||
| 6. **Competitor Consolidation** | ||
| - Acquisitions creating stronger competitors | ||
| - Enterprise giants entering space (Microsoft, Google) | ||
| - Well-funded startups with professional teams | ||
|
|
||
| 7. **Market Education** | ||
| - Self-hosting seen as outdated by mainstream users | ||
| - Cloud-first mentality in younger demographics | ||
| - Perceived complexity deterring adoption | ||
|
|
||
| --- | ||
|
|
||
| ## 8. Strategic Recommendations | ||
|
|
||
| ### 8.1 Short-Term Priorities (0-6 months) | ||
|
|
||
| **1. Security Hardening Initiative** | ||
| - **Action:** Comprehensive security audit by professional firm | ||
| - **Deliverable:** Hardened deployment guide, security best practices documentation | ||
| - **Investment:** $50K-100K | ||
| - **Impact:** Addresses #1 enterprise adoption barrier | ||
| - **Source:** [OX Security - Moltbot Analysis](https://www.ox.security/blog/one-step-away-from-a-massive-data-breach-what-we-found-inside-moltbot/) | ||
|
|
||
| **2. Simplified Installation** | ||
| - **Action:** One-click installers for major platforms (Docker, systemd, launchd) | ||
| - **Deliverable:** Automated setup scripts, web-based configuration wizard | ||
| - **Investment:** 1-2 developer months | ||
| - **Impact:** Reduces setup time from 8-12 hours to 30 minutes | ||
|
|
||
| **3. Documentation Consolidation** | ||
| - **Action:** Centralize and standardize all documentation | ||
| - **Deliverable:** Official docs site with search, video tutorials, interactive guides | ||
| - **Investment:** 1 technical writer, 3 months | ||
| - **Impact:** Improves onboarding success rate | ||
|
|
||
| **4. Community Governance** | ||
| - **Action:** Establish formal governance model and security response team | ||
| - **Deliverable:** Security disclosure policy, release cadence, maintainer guidelines | ||
| - **Investment:** Organizational effort (no direct cost) | ||
| - **Impact:** Builds trust with enterprise evaluators | ||
|
|
||
| ### 8.2 Medium-Term Priorities (6-18 months) | ||
|
|
||
| **1. Enterprise Edition Launch** | ||
| - **Features:** RBAC, SSO, audit logging, centralized management console | ||
| - **Pricing:** $10K-50K annual contracts | ||
| - **Target:** Regulated industries (healthcare, finance, legal) | ||
| - **Investment:** 3-4 developers, 6 months | ||
| - **Revenue Potential:** $1-5M ARR within 12 months | ||
|
|
||
| **2. Managed Hosting Service** | ||
| - **Offering:** Fully managed Molt instances with SLA | ||
| - **Pricing:** $50-200/agent/month | ||
| - **Target:** SMBs and teams without DevOps resources | ||
| - **Investment:** Infrastructure + 2-3 SREs | ||
| - **Revenue Potential:** $500K-2M ARR within 12 months | ||
|
|
||
| **3. Marketplace Monetization** | ||
| - **Model:** 20-30% revenue share on paid plugins | ||
| - **Initiative:** Certified developer program, quality standards | ||
| - **Investment:** Platform development, marketing | ||
| - **Revenue Potential:** $100-500K ARR within 18 months | ||
|
|
||
| **4. Strategic Integrations** | ||
| - **Priorities:** Salesforce, Microsoft 365, Google Workspace, Atlassian | ||
| - **Deliverable:** Pre-built, certified connectors | ||
| - **Impact:** Expands enterprise use cases | ||
|
|
||
| **5. Compliance Certifications** | ||
| - **Targets:** SOC2 Type II, HIPAA attestation, ISO 27001 | ||
| - **Investment:** $150K-300K | ||
| - **Impact:** Unlocks enterprise procurement | ||
|
|
||
| ### 8.3 Long-Term Positioning (18+ months) | ||
|
|
||
| **1. Define Local-First AI Category** | ||
| - **Strategy:** Thought leadership, standards development, ecosystem building | ||
| - **Goal:** Become the default choice for privacy-preserving AI agents | ||
| - **Activities:** Conference talks, white papers, open standards initiatives | ||
|
|
||
| **2. Vertical Solutions** | ||
| - **Healthcare:** HIPAA-compliant medical assistant | ||
| - **Legal:** Privilege-aware legal research agent | ||
| - **Finance:** Compliant financial advisory agent | ||
| - **Government:** Classified-capable secure agent | ||
|
|
||
| **3. Enterprise Platform Play** | ||
| - **Vision:** Multi-tenant, scalable Molt deployment for large organizations | ||
| - **Features:** Centralized admin, policy enforcement, usage analytics | ||
| - **Competition:** Position against Salesforce Einstein, Microsoft Copilot | ||
|
|
||
| **4. Ecosystem Leadership** | ||
| - **Initiatives:** | ||
| - Host annual Molt conference | ||
| - Sponsor research on privacy-preserving AI | ||
| - Develop open standards for local AI agents | ||
| - Build partnerships with hardware vendors (e.g., AI PCs) | ||
|
|
||
| ### 8.4 Risk Mitigation | ||
|
|
||
| **Security Incident Response Plan:** | ||
| 1. Establish security advisory board | ||
| 2. Implement bug bounty program ($5K-50K rewards) | ||
| 3. Automated vulnerability scanning in CI/CD | ||
| 4. Quarterly penetration testing | ||
| 5. Rapid response team for critical issues | ||
|
|
||
| **Competitive Response:** | ||
| 1. Monitor cloud providers for private deployment offerings | ||
| 2. Emphasize true data sovereignty vs. "private cloud" | ||
| 3. Build switching tools from cloud to Molt | ||
| 4. Focus on TCO advantages of self-hosting | ||
|
|
||
| **Sustainability:** | ||
| 1. Diversify funding (enterprise, managed hosting, marketplace) | ||
| 2. Build professional services team | ||
| 3. Establish foundation or sustainable governance model | ||
| 4. Create clear path to profitability | ||
|
|
||
| --- | ||
|
|
||
| ## 9. Competitive Matrix Summary | ||
|
|
||
| | Feature/Capability | Molt | LangChain | CrewAI | LlamaIndex | ChatGPT | Claude | | ||
| |-------------------|------|-----------|--------|------------|---------|--------| | ||
| | **Deployment Model** | Self-hosted | Flexible | Flexible | Flexible | Cloud | Cloud | | ||
| | **Privacy Control** | Maximum | High | High | High | Low | Low | | ||
| | **Setup Complexity** | High | High | Medium | High | None | None | | ||
| | **Multi-Platform Chat** | ✅ Native (13+) | ❌ Custom | ❌ Custom | ❌ None | ❌ Web only | ❌ Web only | | ||
| | **Action Execution** | ✅ Shell, files | ⚖️ Framework | ⚖️ Framework | ❌ Limited | ❌ None | ❌ None | | ||
| | **Proactive Behavior** | ✅ Yes | ❌ No | ❌ No | ❌ No | ❌ No | ❌ No | | ||
| | **Memory Management** | ✅ Persistent | ⚖️ Developer impl. | ⚖️ Task-based | ✅ Advanced | ⚖️ Limited | ⚖️ Limited | | ||
| | **Enterprise Features** | ❌ Minimal | ⚖️ Available | ⚖️ Available | ✅ Strong | ✅ Strong | ✅ Strong | | ||
| | **Security Model** | ⚠️ High risk | ⚖️ Depends | ⚖️ Depends | ⚖️ Depends | ✅ Professional | ✅ Professional | | ||
| | **Documentation** | ⚖️ Community | ✅ Professional | ✅ Good | ✅ Professional | ✅ Excellent | ✅ Excellent | | ||
| | **Cost (Monthly)** | $20-50 | Varies | Varies | Varies | $20 | Usage-based | | ||
| | **Target User** | Power users | Developers | Developers | Data engineers | Everyone | Everyone | | ||
| | **Production Ready** | ⚠️ Limited | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes | | ||
|
|
||
| **Legend:** | ||
| - ✅ Strong capability or advantage | ||
| - ⚖️ Adequate or competitive parity | ||
| - ❌ Weak or absent | ||
| - ⚠️ Concerning or risky | ||
|
|
||
| --- | ||
|
|
||
| ## 10. Conclusion | ||
|
|
||
| ### 10.1 Market Position Assessment | ||
|
|
||
| Molt (Moltbot) occupies a **unique and defensible niche** in the AI agent landscape as the leading open-source, privacy-first, self-hosted agent platform with native multi-platform integration. With 60,000-100,000 GitHub stars and an estimated 300,000-400,000 users, Molt has achieved remarkable product-market fit within its target segment of privacy-conscious power users and developers. | ||
|
|
||
| **Positioning Summary:** | ||
| - **Differentiation:** Clear and compelling for privacy-focused users | ||
| - **Market Size:** Significant but niche (estimated 5-10% of total agent market) | ||
| - **Growth Trajectory:** Rapid (hypergrowth phase) | ||
| - **Sustainability:** Requires monetization strategy to support ongoing development | ||
|
|
||
| ### 10.2 Strategic Verdict | ||
|
|
||
| **Strengths to Leverage:** | ||
| 1. Privacy-first architecture in an increasingly privacy-conscious market | ||
| 2. Multi-platform messaging integration (unique capability) | ||
| 3. Vibrant open-source community and ecosystem | ||
| 4. System-level automation capabilities | ||
| 5. Cost efficiency (no subscription fees) | ||
|
|
||
| **Critical Gaps to Address:** | ||
| 1. Enterprise-grade security and features | ||
| 2. Setup complexity and technical barriers | ||
| 3. Production readiness and support | ||
| 4. Compliance certifications | ||
| 5. Professional documentation and onboarding | ||
|
|
||
| **Recommended Strategy:** | ||
| **"Open Core" Enterprise Model** - Maintain open-source core while building enterprise edition and managed services to fund sustainable development and address enterprise requirements. | ||
|
|
||
| ### 10.3 Investment Thesis | ||
|
|
||
| **For Users:** | ||
| Molt is an **excellent choice** for: | ||
| - Privacy-conscious individuals and teams | ||
| - Developers seeking customizable automation | ||
| - Organizations with data sovereignty requirements | ||
| - Technical teams with self-hosting capabilities | ||
|
|
||
| Molt is **not yet suitable** for: | ||
| - Non-technical users | ||
| - Mission-critical enterprise applications | ||
| - Organizations requiring compliance certifications | ||
| - Teams needing professional support and SLA | ||
|
|
||
| **For Investors:** | ||
| Molt represents a **high-risk, high-reward opportunity**: | ||
|
|
||
| **Bullish Factors:** | ||
| - Large and growing addressable market (privacy-preserving AI) | ||
| - Strong product-market fit evidenced by rapid adoption | ||
| - Defensible technical moat (comprehensive platform) | ||
| - Network effects (plugin marketplace, community) | ||
| - Clear enterprise upsell pathway | ||
|
|
||
| **Risk Factors:** | ||
| - Security vulnerabilities could damage reputation | ||
| - Monetization model unproven | ||
| - Competition from well-funded cloud platforms | ||
| - Technical complexity limits addressable market | ||
| - Sustainability of open-source model | ||
|
|
||
| **Recommended Approach:** Seed or Series A investment contingent on: | ||
| 1. Security audit and hardening completion | ||
| 2. Enterprise edition roadmap | ||
| 3. Clear governance and sustainability model | ||
| 4. Founding/core team commitment | ||
|
|
||
| **Valuation Range:** $20-50M (pre-revenue, community-stage open-source) | ||
|
|
||
| ### 10.4 Final Assessment | ||
|
|
||
| Molt has successfully carved out a distinctive position in the AI agent landscape by prioritizing privacy, system integration, and user control over ease of use and cloud convenience. This positioning resonates strongly with its target audience but limits broader market appeal. | ||
|
|
||
| **The platform's future success depends on:** | ||
| 1. Maintaining security integrity as primary value proposition | ||
| 2. Developing sustainable monetization without compromising open-source ethos | ||
| 3. Building enterprise capabilities to expand addressable market | ||
| 4. Balancing rapid innovation with production stability | ||
| 5. Establishing governance model to ensure long-term viability | ||
|
|
||
| **Market Outlook:** | ||
| As AI agents become more powerful and invasive, privacy concerns will intensify. Molt is well-positioned to benefit from this trend, provided it can overcome current limitations in security, usability, and enterprise readiness. The next 12-18 months will be critical in determining whether Molt can transition from a developer-loved open-source project to a sustainable, enterprise-grade platform. | ||
|
|
||
| --- | ||
|
|
||
| ## 11. Sources and References | ||
|
|
||
| ### Primary Sources | ||
|
|
||
| 1. **Molt Official Documentation** | ||
| - [Molt.bot Official Site](https://www.molt.bot/) | ||
| - [Moltbot GitHub Repository](https://github.com/moltbot/moltbot) | ||
| - [Molt Documentation - Multi-Agent Routing](https://docs.molt.bot/concepts/multi-agent) | ||
| - [DeepWiki - Moltbot Technical Documentation](https://deepwiki.com/moltbot/moltbot) | ||
|
|
||
| 2. **Technical Analysis** | ||
| - [Sterlites - Moltbot Local-First AI Agents Guide](https://sterlites.com/blog/moltbot-local-first-ai-agents-guide-2026) | ||
| - [AICYBR - The Ultimate Guide to Moltbot](https://aicybr.com/blog/moltbot-guide) | ||
| - [CurateClick - Moltbot Complete Guide 2026](https://curateclick.com/blog/2026-moltbot-complete-guide) | ||
| - [DEV Community - Moltbot Ultimate Personal AI Assistant Guide](https://dev.to/czmilo/moltbot-the-ultimate-personal-ai-assistant-guide-for-2026-d4e) | ||
|
|
||
| 3. **Security Analysis** | ||
| - [OX Security - One Step Away From a Massive Data Breach](https://www.ox.security/blog/one-step-away-from-a-massive-data-breach-what-we-found-inside-moltbot/) | ||
| - [Snyk - Clawdbot AI Assistant Security Analysis](https://snyk.io/articles/clawdbot-ai-assistant/) | ||
| - [Collabnix - Moltbot Security: A Developer's Guide](https://collabnix.com/securing-moltbot-a-developers-guide-to-ai-agent-security/) | ||
| - [BleepingComputer - Viral Moltbot AI Assistant Raises Data Security Concerns](https://www.bleepingcomputer.com/news/security/viral-moltbot-ai-assistant-raises-concerns-over-data-security/) | ||
| - [The Register - Clawdbot Becomes Moltbot, But Can't Shed Security Concerns](https://www.theregister.com/2026/01/27/clawdbot_moltbot_security_concerns/) | ||
|
|
||
| 4. **Feature and Use Case Analysis** | ||
| - [Hostinger - What is Moltbot? How the Local AI Agent Works](https://www.hostinger.com/tutorials/what-is-moltbot) | ||
| - [Metana - What Is Moltbot? Everything You Need to Know in 2026](https://metana.io/blog/what-is-moltbot-everything-you-need-to-know-in-2026/) | ||
| - [Metana - Moltbot: The Open-Source Personal AI Assistant](https://metana.io/blog/moltbot-the-open-source-personal-ai-assistant-thats-taking-over-in-2026/) | ||
| - [FelloAI - Moltbot Complete Overview](https://felloai.com/moltbot-complete-overview/) | ||
| - [Growth Jockey - Moltbot Guide: Installation, Pricing, Architecture & Use-Cases](https://www.growthjockey.com/blogs/clawdbot-moltbot) | ||
| - [AI Multiple - Moltbot Use Cases and Security](https://research.aimultiple.com/moltbot/) | ||
| - [Analytics Vidhya - I Tested Clawdbot and Built My Own Local AI Agent](https://www.analyticsvidhya.com/blog/2026/01/clawdbot-guide/) | ||
|
|
||
| 5. **Cost and Pricing Analysis** | ||
| - [Macaron - Is Moltbot Free? True Cost Breakdown 2026](https://macaron.im/blog/is-moltbot-free-cost) | ||
|
|
||
| ### Competitive Analysis Sources | ||
|
|
||
| 6. **LangChain and CrewAI Comparison** | ||
| - [SelectHub - LangChain vs CrewAI](https://www.selecthub.com/ai-agent-framework-tools/langchain-vs-crewai/) | ||
| - [AgentFrame Guide - LangChain vs CrewAI: Complete Comparison](https://agentframe.guide/blog/langchain-vs-crewai-complete-comparison-features-pros-cons/) | ||
| - [Leanware - LangChain vs CrewAI: Full Comparison & Use-Case Guide](https://www.leanware.co/insights/langchain-vs-crewai) | ||
| - [Scalekit - LangChain vs CrewAI for Multi-Agent Workflows](https://www.scalekit.com/blog/langchain-vs-crewai-multi-agent-workflows) | ||
| - [DataCamp - CrewAI vs LangGraph vs AutoGen](https://www.datacamp.com/tutorial/crewai-vs-langgraph-vs-autogen) | ||
| - [Smiansh - LangChain Agents vs AutoGen vs CrewAI Comparison](https://www.smiansh.com/blogs/langchain-agents-vs-autogen-vs-crewai-comparison/) | ||
|
|
||
| 7. **AI Agent Framework Landscape** | ||
| - [Digital Applied - MCP vs LangChain vs CrewAI: Agent Framework Comparison 2026](https://www.digitalapplied.com/blog/mcp-vs-langchain-vs-crewai-agent-framework-comparison) | ||
| - [DataCamp - The Best AI Agents in 2026](https://www.datacamp.com/blog/best-ai-agents) | ||
| - [Genta Dev - Top 10 AI Agent Frameworks & Tools in 2026](https://genta.dev/resources/best-ai-agent-frameworks-2026) | ||
| - [AlphaMatch - Top 7 Agentic AI Frameworks in 2026](https://www.alphamatch.ai/blog/top-agentic-ai-frameworks-2026) | ||
| - [Turing - A Detailed Comparison of Top 6 AI Agent Frameworks](https://www.turing.com/resources/ai-agent-frameworks) | ||
| - [USAII - AI Agents in 2026: A Comparative Guide](https://www.usaii.org/ai-insights/resources/ai-agents-in-2026-a-comparative-guide-to-tools-frameworks-and-platforms) | ||
| - [AI Agents Directory - Landscape & Ecosystem (January 2026)](https://aiagentsdirectory.com/landscape) | ||
| - [Sider AI - 11 Best CrewAI Alternatives for Multi-Agent AI](https://sider.ai/blog/ai-tools/best-crewai-alternatives-for-multi-agent-ai-in-2025) | ||
| - [Agent for Everything - Top 9 CrewAI Alternatives](https://agentforeverything.com/crewai-alternatives/) | ||
| - [Claude Artifact - Comparing Agentic AI Frameworks](https://claude.ai/public/artifacts/e7c1cf72-338c-4b70-bab2-fff4bf0ac553) | ||
|
|
||
| ### Monetization and Business Model Sources | ||
|
|
||
| 8. **AI Platform Monetization** | ||
| - [Orb - AI Monetization in 2025: 4 Pricing Strategies That Drive Revenue](https://www.withorb.com/blog/ai-monetization) | ||
| - [UserPilot - Monetizing in the AI Era: New Pricing Models for a Changing SaaS Landscape](https://userpilot.com/blog/ai-saas-monetization/) | ||
| - [Alguna - 6 AI Monetization Platforms (Every CRO Should Know About)](https://blog.alguna.com/ai-monetization-platform/) | ||
| - [StartupTalky - Monetizing AI: Proven Business Models and Pitfalls to Avoid](https://startuptalky.com/monetizing-ai-business-models/) | ||
| - [Getmonetizely - The Ultimate Guide to Pricing Machine Learning Models](https://www.getmonetizely.com/articles/the-ultimate-guide-to-pricing-machine-learning-models-monetization-strategies-for-ai-as-a-service) | ||
| - [DEV Community - Building and Monetizing AI Model APIs](https://dev.to/zuplo/building-and-monetizing-ai-model-apis-3hgp) | ||
| - [Morgan Stanley - AI Monetization: The Race to ROI in 2025](https://www.morganstanley.com/insights/articles/ai-monetization-race-to-roi-tmt) | ||
|
|
||
| 9. **Go-To-Market Strategy** | ||
| - [Apollo - Go-to-Market Strategy – Frameworks, Examples & Best Practices](https://www.apollo.io/insights/go-to-market) | ||
| - [Slideworks - Complete Go-To-Market (GTM) Strategy Framework with Examples](https://slideworks.io/resources/go-to-market-gtm-strategy) | ||
| - [Agency Analytics - Go-To-Market Strategy: What It Is & How to Build One](https://agencyanalytics.com/blog/go-to-market-strategy) | ||
| - [Rev-Geni - Ultimate SaaS Go-To-Market Strategy](https://revgeni.ai/ultimate-saas-go-to-market-strategy/) | ||
| - [UserPilot - 12 SaaS Go-to-Market Strategy Examples From Top Companies](https://userpilot.com/blog/best-gtm-strategy-examples-saas/) | ||
| - [Cascade - Go-To-Market Strategy Overview + 6 Best Examples](https://www.cascade.app/blog/best-go-to-market-strategies) | ||
| - [Miro - Go-to-Market Strategy Examples for Product Launches](https://miro.com/strategic-planning/go-to-market-strategy-examples/) | ||
| - [ProductLed - The 6 Steps to Building a Winning Product Adoption Strategy](https://productled.com/blog/product-adoption-strategy) | ||
|
|
||
| ### Additional References | ||
|
|
||
| 10. **Community and Project Information** | ||
| - [Moltbot.you - Official Project Site](https://moltbot.you/) | ||
| - [Molt-bot.io - Personal AI Assistant That Actually Does Things](https://molt-bot.io/) | ||
| - [PCMag - Clawdbot (Now Moltbot) Is the Hot New AI Agent](https://www.pcmag.com/news/clawdbot-now-moltbot-is-hot-new-ai-agent-safe-to-use-or-risky) | ||
| - [TechBuzz - Moltbot Viral Surge Exposes AI Agent Security Risks](https://www.techbuzz.ai/articles/moltbot-viral-surge-exposes-ai-agent-security-risks) | ||
| - [TheOutpost - Clawdbot AI Agent Security Risks Raise Alarms](https://theoutpost.ai/news-story/clawdbot-ai-assistant-goes-viral-as-security-risks-and-high-costs-spark-debate-23289/) | ||
|
|
||
| --- | ||
|
|
||
| **Document Version:** 1.0 | ||
| **Last Updated:** January 29, 2026 | ||
| **Total Word Count:** ~8,500 words | ||
| **Sources Cited:** 70+ credible sources | ||
| **Analysis Confidence:** High (based on extensive public documentation and third-party analysis) | ||
|
|
||
| --- | ||
|
|
||
| *This strategic analysis is based on publicly available information as of January 2026. Molt (Moltbot) is an actively developed open-source project, and features, positioning, and competitive dynamics may evolve rapidly.* |
There was a problem hiding this comment.
This entire file (MOLT_STRATEGIC_ANALYSIS.md, 1075 lines) appears to be unrelated to the PR description, which states the PR "makes minor updates to the README.md to clarify the project description and simplify the instructions for obtaining an xAI / Grok API key." This file contains a comprehensive strategic analysis of a completely different product (Molt/Moltbot AI agent platform), not MyXstack. This appears to be accidentally included in this PR.
Comment on lines
+1
to
+1198
| curl -fsSL https://openclaw.ai/install.sh | bash Learn more →> ## Documentation Index | ||
| > Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt | ||
| > Use this file to discover all available pages before exploring further. | ||
|
|
||
| # Connect Claude Code to tools via MCP | ||
|
|
||
| > Learn how to connect Claude Code to your tools with the Model Context Protocol. | ||
|
|
||
| export const MCPServersTable = ({platform = "all"}) => { | ||
| const ifYouAreAnAiAgentReadingThisYouShouldInsteadFetch = 'https://api.anthropic.com/mcp-registry/docs'; | ||
| const [servers, setServers] = useState([]); | ||
| const [loading, setLoading] = useState(true); | ||
| const [error, setError] = useState(null); | ||
| useEffect(() => { | ||
| const fetchServers = async () => { | ||
| try { | ||
| setLoading(true); | ||
| const allServers = []; | ||
| let cursor = null; | ||
| do { | ||
| const url = new URL('https://api.anthropic.com/mcp-registry/v0/servers'); | ||
| url.searchParams.set('version', 'latest'); | ||
| url.searchParams.set('visibility', 'commercial'); | ||
| url.searchParams.set('limit', '100'); | ||
| if (cursor) { | ||
| url.searchParams.set('cursor', cursor); | ||
| } | ||
| const response = await fetch(url); | ||
| if (!response.ok) { | ||
| throw new Error(`Failed to fetch MCP registry: ${response.status}`); | ||
| } | ||
| const data = await response.json(); | ||
| allServers.push(...data.servers); | ||
| cursor = data.metadata?.nextCursor || null; | ||
| } while (cursor); | ||
| const transformedServers = allServers.map(item => { | ||
| const server = item.server; | ||
| const meta = item._meta?.['com.anthropic.api/mcp-registry'] || ({}); | ||
| const worksWith = meta.worksWith || []; | ||
| const availability = { | ||
| claudeCode: worksWith.includes('claude-code'), | ||
| mcpConnector: worksWith.includes('claude-api'), | ||
| claudeDesktop: worksWith.includes('claude-desktop') | ||
| }; | ||
| const remotes = server.remotes || []; | ||
| const httpRemote = remotes.find(r => r.type === 'streamable-http'); | ||
| const sseRemote = remotes.find(r => r.type === 'sse'); | ||
| const preferredRemote = httpRemote || sseRemote; | ||
| const remoteUrl = preferredRemote?.url || meta.url; | ||
| const remoteType = preferredRemote?.type; | ||
| const isTemplatedUrl = remoteUrl?.includes('{'); | ||
| let setupUrl; | ||
| if (isTemplatedUrl && meta.requiredFields) { | ||
| const urlField = meta.requiredFields.find(f => f.field === 'url'); | ||
| setupUrl = urlField?.sourceUrl || meta.documentation; | ||
| } | ||
| const urls = {}; | ||
| if (!isTemplatedUrl) { | ||
| if (remoteType === 'streamable-http') { | ||
| urls.http = remoteUrl; | ||
| } else if (remoteType === 'sse') { | ||
| urls.sse = remoteUrl; | ||
| } | ||
| } | ||
| let envVars = []; | ||
| if (server.packages && server.packages.length > 0) { | ||
| const npmPackage = server.packages.find(p => p.registryType === 'npm'); | ||
| if (npmPackage) { | ||
| urls.stdio = `npx -y ${npmPackage.identifier}`; | ||
| if (npmPackage.environmentVariables) { | ||
| envVars = npmPackage.environmentVariables; | ||
| } | ||
| } | ||
| } | ||
| return { | ||
| name: meta.displayName || server.title || server.name, | ||
| description: meta.oneLiner || server.description, | ||
| documentation: meta.documentation, | ||
| urls: urls, | ||
| envVars: envVars, | ||
| availability: availability, | ||
| customCommands: meta.claudeCodeCopyText ? { | ||
| claudeCode: meta.claudeCodeCopyText | ||
| } : undefined, | ||
| setupUrl: setupUrl | ||
| }; | ||
| }); | ||
| setServers(transformedServers); | ||
| setError(null); | ||
| } catch (err) { | ||
| setError(err.message); | ||
| console.error('Error fetching MCP registry:', err); | ||
| } finally { | ||
| setLoading(false); | ||
| } | ||
| }; | ||
| fetchServers(); | ||
| }, []); | ||
| const generateClaudeCodeCommand = server => { | ||
| if (server.customCommands && server.customCommands.claudeCode) { | ||
| return server.customCommands.claudeCode; | ||
| } | ||
| const serverSlug = server.name.toLowerCase().replace(/[^a-z0-9]/g, '-'); | ||
| if (server.urls.http) { | ||
| return `claude mcp add ${serverSlug} --transport http ${server.urls.http}`; | ||
| } | ||
| if (server.urls.sse) { | ||
| return `claude mcp add ${serverSlug} --transport sse ${server.urls.sse}`; | ||
| } | ||
| if (server.urls.stdio) { | ||
| const envFlags = server.envVars && server.envVars.length > 0 ? server.envVars.map(v => `--env ${v.name}=YOUR_${v.name}`).join(' ') : ''; | ||
| const baseCommand = `claude mcp add ${serverSlug} --transport stdio`; | ||
| return envFlags ? `${baseCommand} ${envFlags} -- ${server.urls.stdio}` : `${baseCommand} -- ${server.urls.stdio}`; | ||
| } | ||
| return null; | ||
| }; | ||
| if (loading) { | ||
| return <div>Loading MCP servers...</div>; | ||
| } | ||
| if (error) { | ||
| return <div>Error loading MCP servers: {error}</div>; | ||
| } | ||
| const filteredServers = servers.filter(server => { | ||
| if (platform === "claudeCode") { | ||
| return server.availability.claudeCode; | ||
| } else if (platform === "mcpConnector") { | ||
| return server.availability.mcpConnector; | ||
| } else if (platform === "claudeDesktop") { | ||
| return server.availability.claudeDesktop; | ||
| } else if (platform === "all") { | ||
| return true; | ||
| } else { | ||
| throw new Error(`Unknown platform: ${platform}`); | ||
| } | ||
| }); | ||
| return <> | ||
| <style jsx>{` | ||
| .cards-container { | ||
| display: grid; | ||
| gap: 1rem; | ||
| margin-bottom: 2rem; | ||
| } | ||
| .server-card { | ||
| border: 1px solid var(--border-color, #e5e7eb); | ||
| border-radius: 6px; | ||
| padding: 1rem; | ||
| } | ||
| .command-row { | ||
| display: flex; | ||
| align-items: center; | ||
| gap: 0.25rem; | ||
| } | ||
| .command-row code { | ||
| font-size: 0.75rem; | ||
| overflow-x: auto; | ||
| } | ||
| `}</style> | ||
|
|
||
| <div className="cards-container"> | ||
| {filteredServers.map(server => { | ||
| const claudeCodeCommand = generateClaudeCodeCommand(server); | ||
| const mcpUrl = server.urls.http || server.urls.sse; | ||
| const commandToShow = platform === "claudeCode" ? claudeCodeCommand : mcpUrl; | ||
| return <div key={server.name} className="server-card"> | ||
| <div> | ||
| {server.documentation ? <a href={server.documentation}> | ||
| <strong>{server.name}</strong> | ||
| </a> : <strong>{server.name}</strong>} | ||
| </div> | ||
|
|
||
| <p style={{ | ||
| margin: '0.5rem 0', | ||
| fontSize: '0.9rem' | ||
| }}> | ||
| {server.description} | ||
| </p> | ||
|
|
||
| {server.setupUrl && <p style={{ | ||
| margin: '0.25rem 0', | ||
| fontSize: '0.8rem', | ||
| fontStyle: 'italic', | ||
| opacity: 0.7 | ||
| }}> | ||
| Requires user-specific URL.{' '} | ||
| <a href={server.setupUrl} style={{ | ||
| textDecoration: 'underline' | ||
| }}> | ||
| Get your URL here | ||
| </a>. | ||
| </p>} | ||
|
|
||
| {commandToShow && !server.setupUrl && <> | ||
| <p style={{ | ||
| display: 'block', | ||
| fontSize: '0.75rem', | ||
| fontWeight: 500, | ||
| minWidth: 'fit-content', | ||
| marginTop: '0.5rem', | ||
| marginBottom: 0 | ||
| }}> | ||
| {platform === "claudeCode" ? "Command" : "URL"} | ||
| </p> | ||
| <div className="command-row"> | ||
| <code> | ||
| {commandToShow} | ||
| </code> | ||
| </div> | ||
| </>} | ||
| </div>; | ||
| })} | ||
| </div> | ||
| </>; | ||
| }; | ||
|
|
||
| Claude Code can connect to hundreds of external tools and data sources through the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction), an open source standard for AI-tool integrations. MCP servers give Claude Code access to your tools, databases, and APIs. | ||
|
|
||
| ## What you can do with MCP | ||
|
|
||
| With MCP servers connected, you can ask Claude Code to: | ||
|
|
||
| * **Implement features from issue trackers**: "Add the feature described in JIRA issue ENG-4521 and create a PR on GitHub." | ||
| * **Analyze monitoring data**: "Check Sentry and Statsig to check the usage of the feature described in ENG-4521." | ||
| * **Query databases**: "Find emails of 10 random users who used feature ENG-4521, based on our PostgreSQL database." | ||
| * **Integrate designs**: "Update our standard email template based on the new Figma designs that were posted in Slack" | ||
| * **Automate workflows**: "Create Gmail drafts inviting these 10 users to a feedback session about the new feature." | ||
|
|
||
| ## Popular MCP servers | ||
|
|
||
| Here are some commonly used MCP servers you can connect to Claude Code: | ||
|
|
||
| <Warning> | ||
| Use third party MCP servers at your own risk - Anthropic has not verified | ||
| the correctness or security of all these servers. | ||
| Make sure you trust MCP servers you are installing. | ||
| Be especially careful when using MCP servers that could fetch untrusted | ||
| content, as these can expose you to prompt injection risk. | ||
| </Warning> | ||
|
|
||
| <MCPServersTable platform="claudeCode" /> | ||
|
|
||
| <Note> | ||
| **Need a specific integration?** [Find hundreds more MCP servers on GitHub](https://github.com/modelcontextprotocol/servers), or build your own using the [MCP SDK](https://modelcontextprotocol.io/quickstart/server). | ||
| </Note> | ||
|
|
||
| ## Installing MCP servers | ||
|
|
||
| MCP servers can be configured in three different ways depending on your needs: | ||
|
|
||
| ### Option 1: Add a remote HTTP server | ||
|
|
||
| HTTP servers are the recommended option for connecting to remote MCP servers. This is the most widely supported transport for cloud-based services. | ||
|
|
||
| ```bash theme={null} | ||
| # Basic syntax | ||
| claude mcp add --transport http <name> <url> | ||
|
|
||
| # Real example: Connect to Notion | ||
| claude mcp add --transport http notion https://mcp.notion.com/mcp | ||
|
|
||
| # Example with Bearer token | ||
| claude mcp add --transport http secure-api https://api.example.com/mcp \ | ||
| --header "Authorization: Bearer your-token" | ||
| ``` | ||
|
|
||
| ### Option 2: Add a remote SSE server | ||
|
|
||
| <Warning> | ||
| The SSE (Server-Sent Events) transport is deprecated. Use HTTP servers instead, where available. | ||
| </Warning> | ||
|
|
||
| ```bash theme={null} | ||
| # Basic syntax | ||
| claude mcp add --transport sse <name> <url> | ||
|
|
||
| # Real example: Connect to Asana | ||
| claude mcp add --transport sse asana https://mcp.asana.com/sse | ||
|
|
||
| # Example with authentication header | ||
| claude mcp add --transport sse private-api https://api.company.com/sse \ | ||
| --header "X-API-Key: your-key-here" | ||
| ``` | ||
|
|
||
| ### Option 3: Add a local stdio server | ||
|
|
||
| Stdio servers run as local processes on your machine. They're ideal for tools that need direct system access or custom scripts. | ||
|
|
||
| ```bash theme={null} | ||
| # Basic syntax | ||
| claude mcp add [options] <name> -- <command> [args...] | ||
|
|
||
| # Real example: Add Airtable server | ||
| claude mcp add --transport stdio --env AIRTABLE_API_KEY=YOUR_KEY airtable \ | ||
| -- npx -y airtable-mcp-server | ||
| ``` | ||
|
|
||
| <Note> | ||
| **Important: Option ordering** | ||
|
|
||
| All options (`--transport`, `--env`, `--scope`, `--header`) must come **before** the server name. The `--` (double dash) then separates the server name from the command and arguments that get passed to the MCP server. | ||
|
|
||
| For example: | ||
|
|
||
| * `claude mcp add --transport stdio myserver -- npx server` → runs `npx server` | ||
| * `claude mcp add --transport stdio --env KEY=value myserver -- python server.py --port 8080` → runs `python server.py --port 8080` with `KEY=value` in environment | ||
|
|
||
| This prevents conflicts between Claude's flags and the server's flags. | ||
| </Note> | ||
|
|
||
| ### Managing your servers | ||
|
|
||
| Once configured, you can manage your MCP servers with these commands: | ||
|
|
||
| ```bash theme={null} | ||
| # List all configured servers | ||
| claude mcp list | ||
|
|
||
| # Get details for a specific server | ||
| claude mcp get github | ||
|
|
||
| # Remove a server | ||
| claude mcp remove github | ||
|
|
||
| # (within Claude Code) Check server status | ||
| /mcp | ||
| ``` | ||
|
|
||
| ### Dynamic tool updates | ||
|
|
||
| Claude Code supports MCP `list_changed` notifications, allowing MCP servers to dynamically update their available tools, prompts, and resources without requiring you to disconnect and reconnect. When an MCP server sends a `list_changed` notification, Claude Code automatically refreshes the available capabilities from that server. | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * Use the `--scope` flag to specify where the configuration is stored: | ||
| * `local` (default): Available only to you in the current project (was called `project` in older versions) | ||
| * `project`: Shared with everyone in the project via `.mcp.json` file | ||
| * `user`: Available to you across all projects (was called `global` in older versions) | ||
| * Set environment variables with `--env` flags (for example, `--env KEY=value`) | ||
| * Configure MCP server startup timeout using the MCP\_TIMEOUT environment variable (for example, `MCP_TIMEOUT=10000 claude` sets a 10-second timeout) | ||
| * Claude Code will display a warning when MCP tool output exceeds 10,000 tokens. To increase this limit, set the `MAX_MCP_OUTPUT_TOKENS` environment variable (for example, `MAX_MCP_OUTPUT_TOKENS=50000`) | ||
| * Use `/mcp` to authenticate with remote servers that require OAuth 2.0 authentication | ||
| </Tip> | ||
|
|
||
| <Warning> | ||
| **Windows Users**: On native Windows (not WSL), local MCP servers that use `npx` require the `cmd /c` wrapper to ensure proper execution. | ||
|
|
||
| ```bash theme={null} | ||
| # This creates command="cmd" which Windows can execute | ||
| claude mcp add --transport stdio my-server -- cmd /c npx -y @some/package | ||
| ``` | ||
|
|
||
| Without the `cmd /c` wrapper, you'll encounter "Connection closed" errors because Windows cannot directly execute `npx`. (See the note above for an explanation of the `--` parameter.) | ||
| </Warning> | ||
|
|
||
| ### Plugin-provided MCP servers | ||
|
|
||
| [Plugins](/en/plugins) can bundle MCP servers, automatically providing tools and integrations when the plugin is enabled. Plugin MCP servers work identically to user-configured servers. | ||
|
|
||
| **How plugin MCP servers work**: | ||
|
|
||
| * Plugins define MCP servers in `.mcp.json` at the plugin root or inline in `plugin.json` | ||
| * When a plugin is enabled, its MCP servers start automatically | ||
| * Plugin MCP tools appear alongside manually configured MCP tools | ||
| * Plugin servers are managed through plugin installation (not `/mcp` commands) | ||
|
|
||
| **Example plugin MCP configuration**: | ||
|
|
||
| In `.mcp.json` at plugin root: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "database-tools": { | ||
| "command": "${CLAUDE_PLUGIN_ROOT}/servers/db-server", | ||
| "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config.json"], | ||
| "env": { | ||
| "DB_URL": "${DB_URL}" | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Or inline in `plugin.json`: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "name": "my-plugin", | ||
| "mcpServers": { | ||
| "plugin-api": { | ||
| "command": "${CLAUDE_PLUGIN_ROOT}/servers/api-server", | ||
| "args": ["--port", "8080"] | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| **Plugin MCP features**: | ||
|
|
||
| * **Automatic lifecycle**: Servers start when plugin enables, but you must restart Claude Code to apply MCP server changes (enabling or disabling) | ||
| * **Environment variables**: Use `${CLAUDE_PLUGIN_ROOT}` for plugin-relative paths | ||
| * **User environment access**: Access to same environment variables as manually configured servers | ||
| * **Multiple transport types**: Support stdio, SSE, and HTTP transports (transport support may vary by server) | ||
|
|
||
| **Viewing plugin MCP servers**: | ||
|
|
||
| ```bash theme={null} | ||
| # Within Claude Code, see all MCP servers including plugin ones | ||
| /mcp | ||
| ``` | ||
|
|
||
| Plugin servers appear in the list with indicators showing they come from plugins. | ||
|
|
||
| **Benefits of plugin MCP servers**: | ||
|
|
||
| * **Bundled distribution**: Tools and servers packaged together | ||
| * **Automatic setup**: No manual MCP configuration needed | ||
| * **Team consistency**: Everyone gets the same tools when plugin is installed | ||
|
|
||
| See the [plugin components reference](/en/plugins-reference#mcp-servers) for details on bundling MCP servers with plugins. | ||
|
|
||
| ## MCP installation scopes | ||
|
|
||
| MCP servers can be configured at three different scope levels, each serving distinct purposes for managing server accessibility and sharing. Understanding these scopes helps you determine the best way to configure servers for your specific needs. | ||
|
|
||
| ### Local scope | ||
|
|
||
| Local-scoped servers represent the default configuration level and are stored in `~/.claude.json` under your project's path. These servers remain private to you and are only accessible when working within the current project directory. This scope is ideal for personal development servers, experimental configurations, or servers containing sensitive credentials that shouldn't be shared. | ||
|
|
||
| <Note> | ||
| The term "local scope" for MCP servers differs from general local settings. MCP local-scoped servers are stored in `~/.claude.json` (your home directory), while general local settings use `.claude/settings.local.json` (in the project directory). See [Settings](/en/settings#settings-files) for details on settings file locations. | ||
| </Note> | ||
|
|
||
| ```bash theme={null} | ||
| # Add a local-scoped server (default) | ||
| claude mcp add --transport http stripe https://mcp.stripe.com | ||
|
|
||
| # Explicitly specify local scope | ||
| claude mcp add --transport http stripe --scope local https://mcp.stripe.com | ||
| ``` | ||
|
|
||
| ### Project scope | ||
|
|
||
| Project-scoped servers enable team collaboration by storing configurations in a `.mcp.json` file at your project's root directory. This file is designed to be checked into version control, ensuring all team members have access to the same MCP tools and services. When you add a project-scoped server, Claude Code automatically creates or updates this file with the appropriate configuration structure. | ||
|
|
||
| ```bash theme={null} | ||
| # Add a project-scoped server | ||
| claude mcp add --transport http paypal --scope project https://mcp.paypal.com/mcp | ||
| ``` | ||
|
|
||
| The resulting `.mcp.json` file follows a standardized format: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "mcpServers": { | ||
| "shared-server": { | ||
| "command": "/path/to/server", | ||
| "args": [], | ||
| "env": {} | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| For security reasons, Claude Code prompts for approval before using project-scoped servers from `.mcp.json` files. If you need to reset these approval choices, use the `claude mcp reset-project-choices` command. | ||
|
|
||
| ### User scope | ||
|
|
||
| User-scoped servers are stored in `~/.claude.json` and provide cross-project accessibility, making them available across all projects on your machine while remaining private to your user account. This scope works well for personal utility servers, development tools, or services you frequently use across different projects. | ||
|
|
||
| ```bash theme={null} | ||
| # Add a user server | ||
| claude mcp add --transport http hubspot --scope user https://mcp.hubspot.com/anthropic | ||
| ``` | ||
|
|
||
| ### Choosing the right scope | ||
|
|
||
| Select your scope based on: | ||
|
|
||
| * **Local scope**: Personal servers, experimental configurations, or sensitive credentials specific to one project | ||
| * **Project scope**: Team-shared servers, project-specific tools, or services required for collaboration | ||
| * **User scope**: Personal utilities needed across multiple projects, development tools, or frequently used services | ||
|
|
||
| <Note> | ||
| **Where are MCP servers stored?** | ||
|
|
||
| * **User and local scope**: `~/.claude.json` (in the `mcpServers` field or under project paths) | ||
| * **Project scope**: `.mcp.json` in your project root (checked into source control) | ||
| * **Managed**: `managed-mcp.json` in system directories (see [Managed MCP configuration](#managed-mcp-configuration)) | ||
| </Note> | ||
|
|
||
| ### Scope hierarchy and precedence | ||
|
|
||
| MCP server configurations follow a clear precedence hierarchy. When servers with the same name exist at multiple scopes, the system resolves conflicts by prioritizing local-scoped servers first, followed by project-scoped servers, and finally user-scoped servers. This design ensures that personal configurations can override shared ones when needed. | ||
|
|
||
| ### Environment variable expansion in `.mcp.json` | ||
|
|
||
| Claude Code supports environment variable expansion in `.mcp.json` files, allowing teams to share configurations while maintaining flexibility for machine-specific paths and sensitive values like API keys. | ||
|
|
||
| **Supported syntax:** | ||
|
|
||
| * `${VAR}` - Expands to the value of environment variable `VAR` | ||
| * `${VAR:-default}` - Expands to `VAR` if set, otherwise uses `default` | ||
|
|
||
| **Expansion locations:** | ||
| Environment variables can be expanded in: | ||
|
|
||
| * `command` - The server executable path | ||
| * `args` - Command-line arguments | ||
| * `env` - Environment variables passed to the server | ||
| * `url` - For HTTP server types | ||
| * `headers` - For HTTP server authentication | ||
|
|
||
| **Example with variable expansion:** | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "mcpServers": { | ||
| "api-server": { | ||
| "type": "http", | ||
| "url": "${API_BASE_URL:-https://api.example.com}/mcp", | ||
| "headers": { | ||
| "Authorization": "Bearer ${API_KEY}" | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| If a required environment variable is not set and has no default value, Claude Code will fail to parse the config. | ||
|
|
||
| ## Practical examples | ||
|
|
||
| {/* ### Example: Automate browser testing with Playwright | ||
|
|
||
| ```bash | ||
| # 1. Add the Playwright MCP server | ||
| claude mcp add --transport stdio playwright -- npx -y @playwright/mcp@latest | ||
|
|
||
| # 2. Write and run browser tests | ||
| > "Test if the login flow works with test@example.com" | ||
| > "Take a screenshot of the checkout page on mobile" | ||
| > "Verify that the search feature returns results" | ||
| ``` */} | ||
|
|
||
| ### Example: Monitor errors with Sentry | ||
|
|
||
| ```bash theme={null} | ||
| # 1. Add the Sentry MCP server | ||
| claude mcp add --transport http sentry https://mcp.sentry.dev/mcp | ||
|
|
||
| # 2. Use /mcp to authenticate with your Sentry account | ||
| > /mcp | ||
|
|
||
| # 3. Debug production issues | ||
| > "What are the most common errors in the last 24 hours?" | ||
| > "Show me the stack trace for error ID abc123" | ||
| > "Which deployment introduced these new errors?" | ||
| ``` | ||
|
|
||
| ### Example: Connect to GitHub for code reviews | ||
|
|
||
| ```bash theme={null} | ||
| # 1. Add the GitHub MCP server | ||
| claude mcp add --transport http github https://api.githubcopilot.com/mcp/ | ||
|
|
||
| # 2. In Claude Code, authenticate if needed | ||
| > /mcp | ||
| # Select "Authenticate" for GitHub | ||
|
|
||
| # 3. Now you can ask Claude to work with GitHub | ||
| > "Review PR #456 and suggest improvements" | ||
| > "Create a new issue for the bug we just found" | ||
| > "Show me all open PRs assigned to me" | ||
| ``` | ||
|
|
||
| ### Example: Query your PostgreSQL database | ||
|
|
||
| ```bash theme={null} | ||
| # 1. Add the database server with your connection string | ||
| claude mcp add --transport stdio db -- npx -y @bytebase/dbhub \ | ||
| --dsn "postgresql://readonly:pass@prod.db.com:5432/analytics" | ||
|
|
||
| # 2. Query your database naturally | ||
| > "What's our total revenue this month?" | ||
| > "Show me the schema for the orders table" | ||
| > "Find customers who haven't made a purchase in 90 days" | ||
| ``` | ||
|
|
||
| ## Authenticate with remote MCP servers | ||
|
|
||
| Many cloud-based MCP servers require authentication. Claude Code supports OAuth 2.0 for secure connections. | ||
|
|
||
| <Steps> | ||
| <Step title="Add the server that requires authentication"> | ||
| For example: | ||
|
|
||
| ```bash theme={null} | ||
| claude mcp add --transport http sentry https://mcp.sentry.dev/mcp | ||
| ``` | ||
| </Step> | ||
|
|
||
| <Step title="Use the /mcp command within Claude Code"> | ||
| In Claude code, use the command: | ||
|
|
||
| ``` | ||
| > /mcp | ||
| ``` | ||
|
|
||
| Then follow the steps in your browser to login. | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * Authentication tokens are stored securely and refreshed automatically | ||
| * Use "Clear authentication" in the `/mcp` menu to revoke access | ||
| * If your browser doesn't open automatically, copy the provided URL | ||
| * OAuth authentication works with HTTP servers | ||
| </Tip> | ||
|
|
||
| ### Use pre-configured OAuth credentials | ||
|
|
||
| Some MCP servers don't support automatic OAuth setup. If you see an error like "Incompatible auth server: does not support dynamic client registration," the server requires pre-configured credentials. Register an OAuth app through the server's developer portal first, then provide the credentials when adding the server. | ||
|
|
||
| <Steps> | ||
| <Step title="Register an OAuth app with the server"> | ||
| Create an app through the server's developer portal and note your client ID and client secret. | ||
|
|
||
| Many servers also require a redirect URI. If so, choose a port and register a redirect URI in the format `http://localhost:PORT/callback`. Use that same port with `--callback-port` in the next step. | ||
| </Step> | ||
|
|
||
| <Step title="Add the server with your credentials"> | ||
| Choose one of the following methods. The port used for `--callback-port` can be any available port. It just needs to match the redirect URI you registered in the previous step. | ||
|
|
||
| <Tabs> | ||
| <Tab title="claude mcp add"> | ||
| Use `--client-id` to pass your app's client ID. The `--client-secret` flag prompts for the secret with masked input: | ||
|
|
||
| ```bash theme={null} | ||
| claude mcp add --transport http \ | ||
| --client-id your-client-id --client-secret --callback-port 8080 \ | ||
| my-server https://mcp.example.com/mcp | ||
| ``` | ||
| </Tab> | ||
|
|
||
| <Tab title="claude mcp add-json"> | ||
| Include the `oauth` object in the JSON config and pass `--client-secret` as a separate flag: | ||
|
|
||
| ```bash theme={null} | ||
| claude mcp add-json my-server \ | ||
| '{"type":"http","url":"https://mcp.example.com/mcp","oauth":{"clientId":"your-client-id","callbackPort":8080}}' \ | ||
| --client-secret | ||
| ``` | ||
| </Tab> | ||
|
|
||
| <Tab title="CI / env var"> | ||
| Set the secret via environment variable to skip the interactive prompt: | ||
|
|
||
| ```bash theme={null} | ||
| MCP_CLIENT_SECRET=your-secret claude mcp add --transport http \ | ||
| --client-id your-client-id --client-secret --callback-port 8080 \ | ||
| my-server https://mcp.example.com/mcp | ||
| ``` | ||
| </Tab> | ||
| </Tabs> | ||
| </Step> | ||
|
|
||
| <Step title="Authenticate in Claude Code"> | ||
| Run `/mcp` in Claude Code and follow the browser login flow. | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * The client secret is stored securely in your system keychain (macOS) or a credentials file, not in your config | ||
| * If the server uses a public OAuth client with no secret, use only `--client-id` without `--client-secret` | ||
| * These flags only apply to HTTP and SSE transports. They have no effect on stdio servers | ||
| * Use `claude mcp get <name>` to verify that OAuth credentials are configured for a server | ||
| </Tip> | ||
|
|
||
| ## Add MCP servers from JSON configuration | ||
|
|
||
| If you have a JSON configuration for an MCP server, you can add it directly: | ||
|
|
||
| <Steps> | ||
| <Step title="Add an MCP server from JSON"> | ||
| ```bash theme={null} | ||
| # Basic syntax | ||
| claude mcp add-json <name> '<json>' | ||
|
|
||
| # Example: Adding an HTTP server with JSON configuration | ||
| claude mcp add-json weather-api '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}' | ||
|
|
||
| # Example: Adding a stdio server with JSON configuration | ||
| claude mcp add-json local-weather '{"type":"stdio","command":"/path/to/weather-cli","args":["--api-key","abc123"],"env":{"CACHE_DIR":"/tmp"}}' | ||
|
|
||
| # Example: Adding an HTTP server with pre-configured OAuth credentials | ||
| claude mcp add-json my-server '{"type":"http","url":"https://mcp.example.com/mcp","oauth":{"clientId":"your-client-id","callbackPort":8080}}' --client-secret | ||
| ``` | ||
| </Step> | ||
|
|
||
| <Step title="Verify the server was added"> | ||
| ```bash theme={null} | ||
| claude mcp get weather-api | ||
| ``` | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * Make sure the JSON is properly escaped in your shell | ||
| * The JSON must conform to the MCP server configuration schema | ||
| * You can use `--scope user` to add the server to your user configuration instead of the project-specific one | ||
| </Tip> | ||
|
|
||
| ## Import MCP servers from Claude Desktop | ||
|
|
||
| If you've already configured MCP servers in Claude Desktop, you can import them: | ||
|
|
||
| <Steps> | ||
| <Step title="Import servers from Claude Desktop"> | ||
| ```bash theme={null} | ||
| # Basic syntax | ||
| claude mcp add-from-claude-desktop | ||
| ``` | ||
| </Step> | ||
|
|
||
| <Step title="Select which servers to import"> | ||
| After running the command, you'll see an interactive dialog that allows you to select which servers you want to import. | ||
| </Step> | ||
|
|
||
| <Step title="Verify the servers were imported"> | ||
| ```bash theme={null} | ||
| claude mcp list | ||
| ``` | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * This feature only works on macOS and Windows Subsystem for Linux (WSL) | ||
| * It reads the Claude Desktop configuration file from its standard location on those platforms | ||
| * Use the `--scope user` flag to add servers to your user configuration | ||
| * Imported servers will have the same names as in Claude Desktop | ||
| * If servers with the same names already exist, they will get a numerical suffix (for example, `server_1`) | ||
| </Tip> | ||
|
|
||
| ## Use Claude Code as an MCP server | ||
|
|
||
| You can use Claude Code itself as an MCP server that other applications can connect to: | ||
|
|
||
| ```bash theme={null} | ||
| # Start Claude as a stdio MCP server | ||
| claude mcp serve | ||
| ``` | ||
|
|
||
| You can use this in Claude Desktop by adding this configuration to claude\_desktop\_config.json: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "mcpServers": { | ||
| "claude-code": { | ||
| "type": "stdio", | ||
| "command": "claude", | ||
| "args": ["mcp", "serve"], | ||
| "env": {} | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| <Warning> | ||
| **Configuring the executable path**: The `command` field must reference the Claude Code executable. If the `claude` command is not in your system's PATH, you'll need to specify the full path to the executable. | ||
|
|
||
| To find the full path: | ||
|
|
||
| ```bash theme={null} | ||
| which claude | ||
| ``` | ||
|
|
||
| Then use the full path in your configuration: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "mcpServers": { | ||
| "claude-code": { | ||
| "type": "stdio", | ||
| "command": "/full/path/to/claude", | ||
| "args": ["mcp", "serve"], | ||
| "env": {} | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| Without the correct executable path, you'll encounter errors like `spawn claude ENOENT`. | ||
| </Warning> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * The server provides access to Claude's tools like View, Edit, LS, etc. | ||
| * In Claude Desktop, try asking Claude to read files in a directory, make edits, and more. | ||
| * Note that this MCP server is only exposing Claude Code's tools to your MCP client, so your own client is responsible for implementing user confirmation for individual tool calls. | ||
| </Tip> | ||
|
|
||
| ## MCP output limits and warnings | ||
|
|
||
| When MCP tools produce large outputs, Claude Code helps manage the token usage to prevent overwhelming your conversation context: | ||
|
|
||
| * **Output warning threshold**: Claude Code displays a warning when any MCP tool output exceeds 10,000 tokens | ||
| * **Configurable limit**: You can adjust the maximum allowed MCP output tokens using the `MAX_MCP_OUTPUT_TOKENS` environment variable | ||
| * **Default limit**: The default maximum is 25,000 tokens | ||
|
|
||
| To increase the limit for tools that produce large outputs: | ||
|
|
||
| ```bash theme={null} | ||
| # Set a higher limit for MCP tool outputs | ||
| export MAX_MCP_OUTPUT_TOKENS=50000 | ||
| claude | ||
| ``` | ||
|
|
||
| This is particularly useful when working with MCP servers that: | ||
|
|
||
| * Query large datasets or databases | ||
| * Generate detailed reports or documentation | ||
| * Process extensive log files or debugging information | ||
|
|
||
| <Warning> | ||
| If you frequently encounter output warnings with specific MCP servers, consider increasing the limit or configuring the server to paginate or filter its responses. | ||
| </Warning> | ||
|
|
||
| ## Use MCP resources | ||
|
|
||
| MCP servers can expose resources that you can reference using @ mentions, similar to how you reference files. | ||
|
|
||
| ### Reference MCP resources | ||
|
|
||
| <Steps> | ||
| <Step title="List available resources"> | ||
| Type `@` in your prompt to see available resources from all connected MCP servers. Resources appear alongside files in the autocomplete menu. | ||
| </Step> | ||
|
|
||
| <Step title="Reference a specific resource"> | ||
| Use the format `@server:protocol://resource/path` to reference a resource: | ||
|
|
||
| ``` | ||
| > Can you analyze @github:issue://123 and suggest a fix? | ||
| ``` | ||
|
|
||
| ``` | ||
| > Please review the API documentation at @docs:file://api/authentication | ||
| ``` | ||
| </Step> | ||
|
|
||
| <Step title="Multiple resource references"> | ||
| You can reference multiple resources in a single prompt: | ||
|
|
||
| ``` | ||
| > Compare @postgres:schema://users with @docs:file://database/user-model | ||
| ``` | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * Resources are automatically fetched and included as attachments when referenced | ||
| * Resource paths are fuzzy-searchable in the @ mention autocomplete | ||
| * Claude Code automatically provides tools to list and read MCP resources when servers support them | ||
| * Resources can contain any type of content that the MCP server provides (text, JSON, structured data, etc.) | ||
| </Tip> | ||
|
|
||
| ## Scale with MCP Tool Search | ||
|
|
||
| When you have many MCP servers configured, tool definitions can consume a significant portion of your context window. MCP Tool Search solves this by dynamically loading tools on-demand instead of preloading all of them. | ||
|
|
||
| ### How it works | ||
|
|
||
| Claude Code automatically enables Tool Search when your MCP tool descriptions would consume more than 10% of the context window. You can [adjust this threshold](#configure-tool-search) or disable tool search entirely. When triggered: | ||
|
|
||
| 1. MCP tools are deferred rather than loaded into context upfront | ||
| 2. Claude uses a search tool to discover relevant MCP tools when needed | ||
| 3. Only the tools Claude actually needs are loaded into context | ||
| 4. MCP tools continue to work exactly as before from your perspective | ||
|
|
||
| ### For MCP server authors | ||
|
|
||
| If you're building an MCP server, the server instructions field becomes more useful with Tool Search enabled. Server instructions help Claude understand when to search for your tools, similar to how [skills](/en/skills) work. | ||
|
|
||
| Add clear, descriptive server instructions that explain: | ||
|
|
||
| * What category of tasks your tools handle | ||
| * When Claude should search for your tools | ||
| * Key capabilities your server provides | ||
|
|
||
| ### Configure tool search | ||
|
|
||
| Tool search runs in auto mode by default, meaning it activates only when your MCP tool definitions exceed the context threshold. If you have few tools, they load normally without tool search. This feature requires models that support `tool_reference` blocks: Sonnet 4 and later, or Opus 4 and later. Haiku models do not support tool search. | ||
|
|
||
| Control tool search behavior with the `ENABLE_TOOL_SEARCH` environment variable: | ||
|
|
||
| | Value | Behavior | | ||
| | :--------- | :--------------------------------------------------------------------------------- | | ||
| | `auto` | Activates when MCP tools exceed 10% of context (default) | | ||
| | `auto:<N>` | Activates at custom threshold, where `<N>` is a percentage (e.g., `auto:5` for 5%) | | ||
| | `true` | Always enabled | | ||
| | `false` | Disabled, all MCP tools loaded upfront | | ||
|
|
||
| ```bash theme={null} | ||
| # Use a custom 5% threshold | ||
| ENABLE_TOOL_SEARCH=auto:5 claude | ||
|
|
||
| # Disable tool search entirely | ||
| ENABLE_TOOL_SEARCH=false claude | ||
| ``` | ||
|
|
||
| Or set the value in your [settings.json `env` field](/en/settings#available-settings). | ||
|
|
||
| You can also disable the MCPSearch tool specifically using the `disallowedTools` setting: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "permissions": { | ||
| "deny": ["MCPSearch"] | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ## Use MCP prompts as commands | ||
|
|
||
| MCP servers can expose prompts that become available as commands in Claude Code. | ||
|
|
||
| ### Execute MCP prompts | ||
|
|
||
| <Steps> | ||
| <Step title="Discover available prompts"> | ||
| Type `/` to see all available commands, including those from MCP servers. MCP prompts appear with the format `/mcp__servername__promptname`. | ||
| </Step> | ||
|
|
||
| <Step title="Execute a prompt without arguments"> | ||
| ``` | ||
| > /mcp__github__list_prs | ||
| ``` | ||
| </Step> | ||
|
|
||
| <Step title="Execute a prompt with arguments"> | ||
| Many prompts accept arguments. Pass them space-separated after the command: | ||
|
|
||
| ``` | ||
| > /mcp__github__pr_review 456 | ||
| ``` | ||
|
|
||
| ``` | ||
| > /mcp__jira__create_issue "Bug in login flow" high | ||
| ``` | ||
| </Step> | ||
| </Steps> | ||
|
|
||
| <Tip> | ||
| Tips: | ||
|
|
||
| * MCP prompts are dynamically discovered from connected servers | ||
| * Arguments are parsed based on the prompt's defined parameters | ||
| * Prompt results are injected directly into the conversation | ||
| * Server and prompt names are normalized (spaces become underscores) | ||
| </Tip> | ||
|
|
||
| ## Managed MCP configuration | ||
|
|
||
| For organizations that need centralized control over MCP servers, Claude Code supports two configuration options: | ||
|
|
||
| 1. **Exclusive control with `managed-mcp.json`**: Deploy a fixed set of MCP servers that users cannot modify or extend | ||
| 2. **Policy-based control with allowlists/denylists**: Allow users to add their own servers, but restrict which ones are permitted | ||
|
|
||
| These options allow IT administrators to: | ||
|
|
||
| * **Control which MCP servers employees can access**: Deploy a standardized set of approved MCP servers across the organization | ||
| * **Prevent unauthorized MCP servers**: Restrict users from adding unapproved MCP servers | ||
| * **Disable MCP entirely**: Remove MCP functionality completely if needed | ||
|
|
||
| ### Option 1: Exclusive control with managed-mcp.json | ||
|
|
||
| When you deploy a `managed-mcp.json` file, it takes **exclusive control** over all MCP servers. Users cannot add, modify, or use any MCP servers other than those defined in this file. This is the simplest approach for organizations that want complete control. | ||
|
|
||
| System administrators deploy the configuration file to a system-wide directory: | ||
|
|
||
| * macOS: `/Library/Application Support/ClaudeCode/managed-mcp.json` | ||
| * Linux and WSL: `/etc/claude-code/managed-mcp.json` | ||
| * Windows: `C:\Program Files\ClaudeCode\managed-mcp.json` | ||
|
|
||
| <Note> | ||
| These are system-wide paths (not user home directories like `~/Library/...`) that require administrator privileges. They are designed to be deployed by IT administrators. | ||
| </Note> | ||
|
|
||
| The `managed-mcp.json` file uses the same format as a standard `.mcp.json` file: | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "mcpServers": { | ||
| "github": { | ||
| "type": "http", | ||
| "url": "https://api.githubcopilot.com/mcp/" | ||
| }, | ||
| "sentry": { | ||
| "type": "http", | ||
| "url": "https://mcp.sentry.dev/mcp" | ||
| }, | ||
| "company-internal": { | ||
| "type": "stdio", | ||
| "command": "/usr/local/bin/company-mcp-server", | ||
| "args": ["--config", "/etc/company/mcp-config.json"], | ||
| "env": { | ||
| "COMPANY_API_URL": "https://internal.company.com" | ||
| } | ||
| } | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Option 2: Policy-based control with allowlists and denylists | ||
|
|
||
| Instead of taking exclusive control, administrators can allow users to configure their own MCP servers while enforcing restrictions on which servers are permitted. This approach uses `allowedMcpServers` and `deniedMcpServers` in the [managed settings file](/en/settings#settings-files). | ||
|
|
||
| <Note> | ||
| **Choosing between options**: Use Option 1 (`managed-mcp.json`) when you want to deploy a fixed set of servers with no user customization. Use Option 2 (allowlists/denylists) when you want to allow users to add their own servers within policy constraints. | ||
| </Note> | ||
|
|
||
| #### Restriction options | ||
|
|
||
| Each entry in the allowlist or denylist can restrict servers in three ways: | ||
|
|
||
| 1. **By server name** (`serverName`): Matches the configured name of the server | ||
| 2. **By command** (`serverCommand`): Matches the exact command and arguments used to start stdio servers | ||
| 3. **By URL pattern** (`serverUrl`): Matches remote server URLs with wildcard support | ||
|
|
||
| **Important**: Each entry must have exactly one of `serverName`, `serverCommand`, or `serverUrl`. | ||
|
|
||
| #### Example configuration | ||
|
|
||
| ```json theme={null} | ||
| { | ||
| "allowedMcpServers": [ | ||
| // Allow by server name | ||
| { "serverName": "github" }, | ||
| { "serverName": "sentry" }, | ||
|
|
||
| // Allow by exact command (for stdio servers) | ||
| { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem"] }, | ||
| { "serverCommand": ["python", "/usr/local/bin/approved-server.py"] }, | ||
|
|
||
| // Allow by URL pattern (for remote servers) | ||
| { "serverUrl": "https://mcp.company.com/*" }, | ||
| { "serverUrl": "https://*.internal.corp/*" } | ||
| ], | ||
| "deniedMcpServers": [ | ||
| // Block by server name | ||
| { "serverName": "dangerous-server" }, | ||
|
|
||
| // Block by exact command (for stdio servers) | ||
| { "serverCommand": ["npx", "-y", "unapproved-package"] }, | ||
|
|
||
| // Block by URL pattern (for remote servers) | ||
| { "serverUrl": "https://*.untrusted.com/*" } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| #### How command-based restrictions work | ||
|
|
||
| **Exact matching**: | ||
|
|
||
| * Command arrays must match **exactly** - both the command and all arguments in the correct order | ||
| * Example: `["npx", "-y", "server"]` will NOT match `["npx", "server"]` or `["npx", "-y", "server", "--flag"]` | ||
|
|
||
| **Stdio server behavior**: | ||
|
|
||
| * When the allowlist contains **any** `serverCommand` entries, stdio servers **must** match one of those commands | ||
| * Stdio servers cannot pass by name alone when command restrictions are present | ||
| * This ensures administrators can enforce which commands are allowed to run | ||
|
|
||
| **Non-stdio server behavior**: | ||
|
|
||
| * Remote servers (HTTP, SSE, WebSocket) use URL-based matching when `serverUrl` entries exist in the allowlist | ||
| * If no URL entries exist, remote servers fall back to name-based matching | ||
| * Command restrictions do not apply to remote servers | ||
|
|
||
| #### How URL-based restrictions work | ||
|
|
||
| URL patterns support wildcards using `*` to match any sequence of characters. This is useful for allowing entire domains or subdomains. | ||
|
|
||
| **Wildcard examples**: | ||
|
|
||
| * `https://mcp.company.com/*` - Allow all paths on a specific domain | ||
| * `https://*.example.com/*` - Allow any subdomain of example.com | ||
| * `http://localhost:*/*` - Allow any port on localhost | ||
|
|
||
| **Remote server behavior**: | ||
|
|
||
| * When the allowlist contains **any** `serverUrl` entries, remote servers **must** match one of those URL patterns | ||
| * Remote servers cannot pass by name alone when URL restrictions are present | ||
| * This ensures administrators can enforce which remote endpoints are allowed | ||
|
|
||
| <Accordion title="Example: URL-only allowlist"> | ||
| ```json theme={null} | ||
| { | ||
| "allowedMcpServers": [ | ||
| { "serverUrl": "https://mcp.company.com/*" }, | ||
| { "serverUrl": "https://*.internal.corp/*" } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| **Result**: | ||
|
|
||
| * HTTP server at `https://mcp.company.com/api`: ✅ Allowed (matches URL pattern) | ||
| * HTTP server at `https://api.internal.corp/mcp`: ✅ Allowed (matches wildcard subdomain) | ||
| * HTTP server at `https://external.com/mcp`: ❌ Blocked (doesn't match any URL pattern) | ||
| * Stdio server with any command: ❌ Blocked (no name or command entries to match) | ||
| </Accordion> | ||
|
|
||
| <Accordion title="Example: Command-only allowlist"> | ||
| ```json theme={null} | ||
| { | ||
| "allowedMcpServers": [ | ||
| { "serverCommand": ["npx", "-y", "approved-package"] } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| **Result**: | ||
|
|
||
| * Stdio server with `["npx", "-y", "approved-package"]`: ✅ Allowed (matches command) | ||
| * Stdio server with `["node", "server.js"]`: ❌ Blocked (doesn't match command) | ||
| * HTTP server named "my-api": ❌ Blocked (no name entries to match) | ||
| </Accordion> | ||
|
|
||
| <Accordion title="Example: Mixed name and command allowlist"> | ||
| ```json theme={null} | ||
| { | ||
| "allowedMcpServers": [ | ||
| { "serverName": "github" }, | ||
| { "serverCommand": ["npx", "-y", "approved-package"] } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| **Result**: | ||
|
|
||
| * Stdio server named "local-tool" with `["npx", "-y", "approved-package"]`: ✅ Allowed (matches command) | ||
| * Stdio server named "local-tool" with `["node", "server.js"]`: ❌ Blocked (command entries exist but doesn't match) | ||
| * Stdio server named "github" with `["node", "server.js"]`: ❌ Blocked (stdio servers must match commands when command entries exist) | ||
| * HTTP server named "github": ✅ Allowed (matches name) | ||
| * HTTP server named "other-api": ❌ Blocked (name doesn't match) | ||
| </Accordion> | ||
|
|
||
| <Accordion title="Example: Name-only allowlist"> | ||
| ```json theme={null} | ||
| { | ||
| "allowedMcpServers": [ | ||
| { "serverName": "github" }, | ||
| { "serverName": "internal-tool" } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| **Result**: | ||
|
|
||
| * Stdio server named "github" with any command: ✅ Allowed (no command restrictions) | ||
| * Stdio server named "internal-tool" with any command: ✅ Allowed (no command restrictions) | ||
| * HTTP server named "github": ✅ Allowed (matches name) | ||
| * Any server named "other": ❌ Blocked (name doesn't match) | ||
| </Accordion> | ||
|
|
||
| #### Allowlist behavior (`allowedMcpServers`) | ||
|
|
||
| * `undefined` (default): No restrictions - users can configure any MCP server | ||
| * Empty array `[]`: Complete lockdown - users cannot configure any MCP servers | ||
| * List of entries: Users can only configure servers that match by name, command, or URL pattern | ||
|
|
||
| #### Denylist behavior (`deniedMcpServers`) | ||
|
|
||
| * `undefined` (default): No servers are blocked | ||
| * Empty array `[]`: No servers are blocked | ||
| * List of entries: Specified servers are explicitly blocked across all scopes | ||
|
|
||
| #### Important notes | ||
|
|
||
| * **Option 1 and Option 2 can be combined**: If `managed-mcp.json` exists, it has exclusive control and users cannot add servers. Allowlists/denylists still apply to the managed servers themselves. | ||
| * **Denylist takes absolute precedence**: If a server matches a denylist entry (by name, command, or URL), it will be blocked even if it's on the allowlist | ||
| * Name-based, command-based, and URL-based restrictions work together: a server passes if it matches **either** a name entry, a command entry, or a URL pattern (unless blocked by denylist) | ||
|
|
||
| <Note> | ||
| **When using `managed-mcp.json`**: Users cannot add MCP servers through `claude mcp add` or configuration files. The `allowedMcpServers` and `deniedMcpServers` settings still apply to filter which managed servers are actually loaded. | ||
| </Note> |
There was a problem hiding this comment.
This entire file (1198 lines) appears to be unrelated to the PR description. It contains documentation about Claude Code's MCP (Model Context Protocol) integration, not MyXstack's xMCP server implementation. The content discusses "Claude Code" as a tool and its MCP server configuration, which is completely different from this project's purpose of being an autonomous X (Twitter) agent. This appears to be accidentally included in this PR.
Comment on lines
+1
to
+336
| # GitHub Copilot Instructions for MyXstack | ||
|
|
||
| ## Repository Overview | ||
|
|
||
| MyXstack is an autonomous AI agent system for X (Twitter) that uses Grok AI via the xMCP (Model Context Protocol) server. The agent monitors mentions, analyzes conversations using AI, and autonomously responds with context-aware actions. | ||
|
|
||
| ## Technology Stack | ||
|
|
||
| - **Language**: TypeScript (ES2022) | ||
| - **Runtime**: Node.js 18+ | ||
| - **AI Service**: Grok (xAI API) | ||
| - **Protocol**: Model Context Protocol (MCP) | ||
| - **APIs**: X (Twitter) API v2 | ||
| - **Build Tool**: TypeScript Compiler (tsc) | ||
|
|
||
| ## Project Structure | ||
|
|
||
| ``` | ||
| src/ | ||
| ├── index.ts # Main entry point | ||
| ├── examples.ts # Usage examples | ||
| ├── types/ # TypeScript type definitions | ||
| ├── services/ | ||
| │ ├── config.ts # Configuration management | ||
| │ ├── xapi.ts # X API client | ||
| │ ├── grok.ts # Grok AI service | ||
| │ └── agent.ts # Autonomous agent orchestrator | ||
| └── mcp/ | ||
| └── server.ts # xMCP server implementation | ||
| ``` | ||
|
|
||
| ## Coding Standards | ||
|
|
||
| ### TypeScript | ||
|
|
||
| - **Strict Mode**: Always maintain strict TypeScript compilation | ||
| - **Types**: Use explicit types; avoid `any` except when absolutely necessary | ||
| - **Async/Await**: Prefer async/await over raw promises | ||
| - **Error Handling**: Always wrap API calls in try-catch blocks | ||
| - **Null Safety**: Use optional chaining (`?.`) and nullish coalescing (`??`) | ||
| - **ES Modules**: Use ES module syntax (`import`/`export`), not CommonJS | ||
|
|
||
| ### Naming Conventions | ||
|
|
||
| - **Classes**: PascalCase (e.g., `XAPIClient`, `AutonomousAgent`) | ||
| - **Interfaces/Types**: PascalCase (e.g., `AgentConfig`, `XApiResponse`) | ||
| - **Functions/Methods**: camelCase (e.g., `fetchMentions`, `analyzeAndDecide`) | ||
| - **Constants**: UPPER_SNAKE_CASE (e.g., `DEFAULT_POLLING_INTERVAL`) | ||
| - **Files**: kebab-case for multi-word (e.g., `x-api.ts`) or camelCase for single word | ||
|
|
||
| ### Code Organization | ||
|
|
||
| - **Single Responsibility**: Each service/class should have one clear purpose | ||
| - **Interface Segregation**: Define clear interfaces for external dependencies | ||
| - **Dependency Injection**: Pass dependencies through constructors | ||
| - **Configuration**: All environment variables should be loaded via `config.ts` | ||
| - **Simulation Mode**: Support simulation/mock mode for all external API calls | ||
|
|
||
| ### Documentation | ||
|
|
||
| - **Public Methods**: Add JSDoc comments explaining purpose, parameters, and return values | ||
| - **Complex Logic**: Add inline comments for non-obvious algorithms | ||
| - **Type Definitions**: Document interfaces with descriptions of each field | ||
| - **Examples**: Include usage examples in JSDoc for key functions | ||
|
|
||
| ## Build and Development | ||
|
|
||
| ### Building | ||
|
|
||
| ```bash | ||
| npm run build # Compile TypeScript to dist/ | ||
| npm run clean # Remove dist/ directory | ||
| ``` | ||
|
|
||
| ### Running | ||
|
|
||
| ```bash | ||
| npm start # Run compiled code | ||
| npm run dev # Build and run | ||
| npm run examples # Run usage examples | ||
| ``` | ||
|
|
||
| ### Environment Variables | ||
|
|
||
| Required environment variables (see `.env.example`): | ||
| - `X_USERNAME`: X account username to monitor | ||
| - `X_BEARER_TOKEN`: X API bearer token for read operations | ||
| - `X_CONSUMER_KEY`, `X_CONSUMER_SECRET`: OAuth 1.0a credentials | ||
| - `X_ACCESS_TOKEN`, `X_ACCESS_TOKEN_SECRET`: OAuth user tokens | ||
| - `XAI_API_KEY`: xAI/Grok API key | ||
| - `POLLING_INTERVAL_MS`: Optional, defaults to 30000ms | ||
|
|
||
| **IMPORTANT**: Never commit credentials or `.env` files. Always use environment variables. | ||
|
|
||
| ## Testing Strategy | ||
|
|
||
| ### Current Status | ||
| - No formal test suite yet | ||
| - Manual testing via simulation mode | ||
| - Integration testing with real APIs in development | ||
|
|
||
| ### When Adding Tests | ||
| - Place tests in `src/__tests__/` directory | ||
| - Use a standard testing framework (e.g., Jest, Vitest) | ||
| - Write unit tests for services | ||
| - Mock external API calls | ||
| - Test error handling paths | ||
|
|
||
| ## API Integration Patterns | ||
|
|
||
| ### X API Client (`xapi.ts`) | ||
|
|
||
| When adding new X API features: | ||
| 1. Add method to `XAPIClient` class | ||
| 2. Include simulation/mock mode support | ||
| 3. Handle rate limiting gracefully | ||
| 4. Parse and normalize response data | ||
| 5. Add proper error handling with descriptive messages | ||
|
|
||
| Example pattern: | ||
| ```typescript | ||
| async newFeature(param: string): Promise<Result> { | ||
| if (this.config.simulation) { | ||
| return this.mockResult(); | ||
| } | ||
|
|
||
| try { | ||
| const response = await fetch(/* API call */); | ||
| if (!response.ok) { | ||
| throw new Error(`API error: ${response.status}`); | ||
| } | ||
| return await response.json(); | ||
| } catch (error) { | ||
| console.error('❌ Error:', error); | ||
| throw error; | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| ### Grok AI Service (`grok.ts`) | ||
|
|
||
| When modifying AI analysis: | ||
| 1. Keep prompts clear and specific | ||
| 2. Provide sufficient context to the AI | ||
| 3. Parse responses defensively | ||
| 4. Include fallback behavior for unexpected responses | ||
| 5. Support simulation mode with realistic mock data | ||
|
|
||
| ### MCP Server (`mcp/server.ts`) | ||
|
|
||
| When adding new MCP tools: | ||
| 1. Register tool in `getTools()` method | ||
| 2. Add handler in tool invocation logic | ||
| 3. Follow MCP specification for tool schema | ||
| 4. Document tool capabilities in description | ||
| 5. Return structured, type-safe results | ||
|
|
||
| ## Security Best Practices | ||
|
|
||
| ### API Keys and Credentials | ||
| - **Never hardcode**: All credentials must be in environment variables | ||
| - **Validation**: Validate all credentials at startup | ||
| - **Logging**: Never log credentials or tokens | ||
| - **Error Messages**: Don't expose credentials in error messages | ||
|
|
||
| ### Input Validation | ||
| - **User Input**: Sanitize all user-generated content before processing | ||
| - **API Responses**: Validate structure of all API responses | ||
| - **Type Checking**: Use TypeScript types to catch errors at compile time | ||
|
|
||
| ### Rate Limiting | ||
| - **Respect Limits**: Honor X API rate limits | ||
| - **Graceful Degradation**: Handle rate limit errors gracefully | ||
| - **Backoff**: Implement exponential backoff for retries | ||
|
|
||
| ### Data Privacy | ||
| - **Minimal Storage**: Don't persist sensitive user data | ||
| - **In-Memory Only**: Current design uses in-memory tracking | ||
| - **No Logs**: Don't log private conversation content | ||
|
|
||
| ## Error Handling | ||
|
|
||
| ### Pattern to Follow | ||
| ```typescript | ||
| try { | ||
| // Operation | ||
| } catch (error) { | ||
| console.error('❌ Descriptive error message:', error); | ||
| // Graceful fallback or re-throw if critical | ||
| if (isCritical) throw error; | ||
| return fallbackValue; | ||
| } | ||
| ``` | ||
|
|
||
| ### Logging Conventions | ||
| - ✅ Success: Green checkmark | ||
| - ❌ Error: Red X | ||
| - ⚠️ Warning: Yellow warning | ||
| - 📬 Mention: Envelope | ||
| - 🤖 AI Activity: Robot | ||
| - 🧵 Thread: Thread emoji | ||
| - ⏳ Waiting: Hourglass | ||
|
|
||
| ## Agent Architecture | ||
|
|
||
| ### Main Components | ||
|
|
||
| 1. **Configuration Manager** (`config.ts`): Centralized configuration loading | ||
| 2. **X API Client** (`xapi.ts`): Interface to X API | ||
| 3. **Grok Service** (`grok.ts`): AI analysis and decision-making | ||
| 4. **Autonomous Agent** (`agent.ts`): Main orchestration loop | ||
| 5. **xMCP Server** (`mcp/server.ts`): MCP protocol implementation | ||
|
|
||
| ### Processing Flow | ||
|
|
||
| ``` | ||
| Poll for mentions → Fetch thread context → | ||
| Analyze with Grok → Make decision → | ||
| Execute action → Mark as processed → Wait → Repeat | ||
| ``` | ||
|
|
||
| ### Adding New Action Types | ||
|
|
||
| 1. Add to `AgentActionType` enum in `types/index.ts` | ||
| 2. Update `AgentAction` interface if needed | ||
| 3. Implement handler in `agent.ts` `executeAction()` method | ||
| 4. Update Grok prompts to recognize new action type | ||
| 5. Add simulation mode support | ||
| 6. Document in ARCHITECTURE.md | ||
|
|
||
| ## Performance Considerations | ||
|
|
||
| - **Memory**: Keep processed mentions map bounded | ||
| - **CPU**: Minimize blocking operations | ||
| - **Network**: Batch requests when possible | ||
| - **Polling**: Use appropriate intervals (default: 30s) | ||
|
|
||
| ## Deployment | ||
|
|
||
| ### Environment Setup | ||
| 1. Clone repository | ||
| 2. Run `npm install` | ||
| 3. Copy `.env.example` to `.env` | ||
| 4. Configure all required environment variables | ||
| 5. Run `npm run build` | ||
| 6. Run `npm start` | ||
|
|
||
| ### Production Considerations | ||
| - Use process manager (PM2, systemd) for restarts | ||
| - Monitor logs for errors | ||
| - Set up alerts for failures | ||
| - Consider containerization (Docker) | ||
| - Use proper logging service | ||
| - Implement health checks | ||
|
|
||
| ## Common Tasks | ||
|
|
||
| ### Adding a New X API Endpoint | ||
| 1. Add method to `XAPIClient` in `src/services/xapi.ts` | ||
| 2. Include simulation mode mock | ||
| 3. Update types in `src/types/index.ts` if needed | ||
| 4. Add error handling | ||
| 5. Document in USAGE.md | ||
|
|
||
| ### Modifying Agent Behavior | ||
| 1. Update decision logic in `GrokService` (`src/services/grok.ts`) | ||
| 2. Adjust prompts to guide AI behavior | ||
| 3. Test with simulation mode first | ||
| 4. Update ARCHITECTURE.md with changes | ||
|
|
||
| ### Adding New MCP Tools | ||
| 1. Define tool schema in `mcp/server.ts` `getTools()` | ||
| 2. Implement tool handler in `CallToolRequestSchema` handler | ||
| 3. Test with MCP client | ||
| 4. Document tool capabilities | ||
|
|
||
| ## Documentation Updates | ||
|
|
||
| When making changes, update relevant documentation: | ||
| - **ARCHITECTURE.md**: System design and component changes | ||
| - **USAGE.md**: Usage examples and new features | ||
| - **README.md**: Setup instructions and overview | ||
| - **DEPLOYMENT.md**: Deployment-related changes | ||
| - **.env.example**: New environment variables | ||
|
|
||
| ## Git Workflow | ||
|
|
||
| - **Branches**: Create feature branches from `main` | ||
| - **Commits**: Use descriptive commit messages | ||
| - **PRs**: Include description of changes and testing performed | ||
| - **Code Review**: All changes should be reviewed | ||
|
|
||
| ## AI Agent Development Principles | ||
|
|
||
| 1. **Context Awareness**: Always provide full conversation context to AI | ||
| 2. **Explainability**: Log AI reasoning and confidence levels | ||
| 3. **Safety**: Include guardrails and review before posting | ||
| 4. **Autonomy**: Design for minimal human intervention | ||
| 5. **Adaptability**: Make behavior configurable and tunable | ||
| 6. **Monitoring**: Track agent actions and outcomes | ||
| 7. **Graceful Degradation**: Handle failures without crashing | ||
|
|
||
| ## Future Enhancements to Consider | ||
|
|
||
| When extending the codebase: | ||
| - Database integration for persistent state | ||
| - Web dashboard for monitoring | ||
| - Webhook support for real-time notifications | ||
| - Multi-account support | ||
| - Advanced analytics and metrics | ||
| - Conversation memory/context retention | ||
| - Multi-modal support (images, videos) | ||
| - Integration with other AI models | ||
| - Advanced rate limit management | ||
|
|
||
| ## Questions or Issues? | ||
|
|
||
| Refer to: | ||
| - **ARCHITECTURE.md** for system design | ||
| - **USAGE.md** for usage examples | ||
| - **DEPLOYMENT.md** for deployment guides | ||
| - **README.md** for quick start | ||
|
|
||
| ## Copilot Specific Guidance | ||
|
|
||
| When suggesting code: | ||
| 1. **Follow existing patterns** in the codebase | ||
| 2. **Maintain type safety** - use TypeScript properly | ||
| 3. **Include error handling** for all external calls | ||
| 4. **Support simulation mode** for testing | ||
| 5. **Add appropriate logging** with emojis per convention | ||
| 6. **Update documentation** when changing behavior | ||
| 7. **Consider rate limits** for X API operations | ||
| 8. **Preserve security** - never expose credentials | ||
| 9. **Think about scale** - avoid unbounded memory growth | ||
| 10. **Test thoroughly** - include simulation mode testing |
There was a problem hiding this comment.
This file (336 lines) is a duplicate of the custom coding guidelines that are already embedded in the review system. While having GitHub Copilot instructions can be useful for the repository, this file duplicates content and is unrelated to the PR description which only mentions "minor updates to the README.md." If intended to be added, this should be in a separate PR focused on development tooling.
| } | ||
|
|
||
| private parseThread(tweets: any[]): XThread | null { | ||
| private parseThread(tweets: { created_at: string; [key: string]: any }[]): XThread | null { |
There was a problem hiding this comment.
This type annotation improvement is unrelated to the PR description which states the PR "makes minor updates to the README.md to clarify the project description and simplify the instructions for obtaining an xAI / Grok API key." While improving type safety is valuable, code changes like this should be in a separate PR focused on code quality improvements, not bundled with documentation updates. This makes it harder to review and track changes properly.
| } | ||
|
|
||
| private parseThread(tweets: any[]): XThread | null { | ||
| private parseThread(tweets: { created_at: string; [key: string]: any }[]): XThread | null { |
There was a problem hiding this comment.
The type annotation improvement for parseThread is good and adds type safety. However, this creates an inconsistency with other similar methods in the same file. The parseMentions method at line 163 uses any[], and parsePost at line 171 uses any for the tweet parameter. For consistency with the coding guideline that states "Use explicit types; avoid any except when absolutely necessary," these methods should also have explicit type annotations similar to parseThread. Consider defining a proper Tweet interface and using it consistently across all parsing methods.
Update CODEOWNERS to assign new reviewers
Comment on lines
+18
to
+19
| if (!/^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?:/.test(pr.title)) { | ||
| issues.push('⚠️ PR title should follow conventional commits format'); |
There was a problem hiding this comment.
The PR validation workflow enforces conventional commit format for PR titles, but this current PR itself doesn't follow that format. The title "updates to the README.md" should follow the pattern: type(scope): description.
For example:
docs: update README.md project description and xAI instructionsdocs(readme): simplify xAI API key setup instructions
This is self-referential: the workflow being added would fail this PR.
Comment on lines
+13
to
+39
| const issues = []; | ||
|
|
||
| if (pr.title.length < 10) { | ||
| issues.push('❌ PR title too short (minimum 10 characters)'); | ||
| } | ||
| if (!/^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?:/.test(pr.title)) { | ||
| issues.push('⚠️ PR title should follow conventional commits format'); | ||
| } | ||
|
|
||
| if (!pr.body || pr.body.length < 20) { | ||
| issues.push('❌ PR description is required (minimum 20 characters)'); | ||
| } | ||
|
|
||
| const totalChanges = (pr.additions || 0) + (pr.deletions || 0); | ||
| if (totalChanges > 500) { | ||
| issues.push(`⚠️ Large PR detected (${totalChanges} lines changed)`); | ||
| } | ||
|
|
||
| if (issues.length > 0) { | ||
| const comment = `## 🔍 PR Validation\n\n${issues.join('\n')}`; | ||
| await github.rest.issues.createComment({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: pr.number, | ||
| body: comment | ||
| }); | ||
| core.setFailed('PR validation failed'); |
There was a problem hiding this comment.
The PR validation check marks PRs as failed if they exceed 500 lines of changes. This current PR contains over 2,800 lines of changes (mostly from the addition of large documentation files), which means:
- This workflow would flag the PR introducing it as too large
- The 500-line threshold may be too restrictive for legitimate large refactorings or documentation additions
- Consider making this a warning instead of a failure, or increasing the threshold
Additionally, the check doesn't distinguish between documentation, tests, and code changes. Large documentation PRs (like documentation improvements) might reasonably exceed 500 lines without being problematic.
Suggested change
| const issues = []; | |
| if (pr.title.length < 10) { | |
| issues.push('❌ PR title too short (minimum 10 characters)'); | |
| } | |
| if (!/^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?:/.test(pr.title)) { | |
| issues.push('⚠️ PR title should follow conventional commits format'); | |
| } | |
| if (!pr.body || pr.body.length < 20) { | |
| issues.push('❌ PR description is required (minimum 20 characters)'); | |
| } | |
| const totalChanges = (pr.additions || 0) + (pr.deletions || 0); | |
| if (totalChanges > 500) { | |
| issues.push(`⚠️ Large PR detected (${totalChanges} lines changed)`); | |
| } | |
| if (issues.length > 0) { | |
| const comment = `## 🔍 PR Validation\n\n${issues.join('\n')}`; | |
| await github.rest.issues.createComment({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| issue_number: pr.number, | |
| body: comment | |
| }); | |
| core.setFailed('PR validation failed'); | |
| const errors = []; | |
| const warnings = []; | |
| if (pr.title.length < 10) { | |
| errors.push('❌ PR title too short (minimum 10 characters)'); | |
| } | |
| if (!/^(feat|fix|docs|style|refactor|test|chore|perf|ci|build|revert)(\(.+\))?:/.test(pr.title)) { | |
| warnings.push('⚠️ PR title should follow conventional commits format'); | |
| } | |
| if (!pr.body || pr.body.length < 20) { | |
| errors.push('❌ PR description is required (minimum 20 characters)'); | |
| } | |
| const totalChanges = (pr.additions || 0) + (pr.deletions || 0); | |
| if (totalChanges > 500) { | |
| warnings.push(`⚠️ Large PR detected (${totalChanges} lines changed)`); | |
| } | |
| const allMessages = [...errors, ...warnings]; | |
| if (allMessages.length > 0) { | |
| const comment = `## 🔍 PR Validation\n\n${allMessages.join('\n')}`; | |
| await github.rest.issues.createComment({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| issue_number: pr.number, | |
| body: comment | |
| }); | |
| if (errors.length > 0) { | |
| core.setFailed('PR validation failed'); | |
| } |
Comment on lines
+16
to
+38
| if (text.includes('bug') || text.includes('error')) labels.push('bug'); | ||
| if (text.includes('feature') || text.includes('enhancement')) labels.push('enhancement'); | ||
| if (text.includes('docs') || text.includes('documentation')) labels.push('documentation'); | ||
| if (text.includes('question') || text.includes('help')) labels.push('question'); | ||
| if (text.includes('urgent') || text.includes('critical')) labels.push('priority:high'); | ||
|
|
||
| labels.push('needs-triage'); | ||
|
|
||
| if (labels.length > 0) { | ||
| await github.rest.issues.addLabels({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: issue.number, | ||
| labels: labels | ||
| }); | ||
| } | ||
|
|
||
| await github.rest.issues.createComment({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: issue.number, | ||
| body: '👋 Thanks for opening this issue! It has been automatically labeled for triage.' | ||
| }); |
There was a problem hiding this comment.
Similar to the auto-label workflow, the issue triage workflow references labels ('bug', 'enhancement', 'documentation', 'question', 'priority:high', 'needs-triage') that may not exist in the repository.
The workflow should either:
- Include error handling to gracefully skip missing labels
- Document that these labels must be created before enabling the workflow
- Include a setup script or documentation about creating the required labels
Additionally, the workflow will comment on every new issue, which might be considered noise for some projects. Consider making this behavior configurable.
Comment on lines
4
to
26
| @@ -16,11 +16,11 @@ | |||
| /api/ @groupthinking | |||
|
|
|||
| # Infrastructure | |||
| /.github/ @groupthinking | |||
| *.yml @groupthinking | |||
| *.yaml @groupthinking | |||
| Dockerfile @groupthinking | |||
| /.github/ @Claude | |||
| *.yml @Claude | |||
| *.yaml @Claude | |||
| Dockerfile @Claude | |||
|
|
|||
| # Documentation | |||
| *.md @groupthinking | |||
| /docs/ @groupthinking | |||
| *.md @Copilot | |||
| /docs/ @Copilot | |||
There was a problem hiding this comment.
The CODEOWNERS file now references GitHub usernames that don't appear to be valid or appropriate for this project:
- @codex - appears to be a reference to OpenAI's Codex, not a GitHub user
- @vercel - references the Vercel company account, but this project doesn't appear to be affiliated with Vercel
- @claude - appears to be a reference to Anthropic's Claude AI, not a GitHub user
- @Copilot - appears to be a reference to GitHub Copilot, not a user account
CODEOWNERS should reference actual GitHub usernames or team names that will be assigned as reviewers. Using AI product names as code owners will likely cause GitHub's CODEOWNERS feature to fail. Consider using actual team member usernames like @groupthinking (which is used for backend files) or removing the CODEOWNERS file if there are no designated owners.
Comment on lines
+30
to
+35
| if (labels.size > 0) { | ||
| await github.rest.issues.addLabels({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: context.payload.pull_request.number, | ||
| labels: Array.from(labels) |
There was a problem hiding this comment.
The auto-labeling workflow will attempt to add labels like 'documentation', 'tests', 'ci/cd', 'javascript', 'python', and 'styling' to pull requests. However, this workflow doesn't check if these labels actually exist in the repository before trying to add them.
If these labels don't exist, the workflow will fail with a "Label does not exist" error. Before merging this workflow, ensure that all referenced labels are created in the repository settings, or add error handling to gracefully skip missing labels.
Suggested change
| if (labels.size > 0) { | |
| await github.rest.issues.addLabels({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| issue_number: context.payload.pull_request.number, | |
| labels: Array.from(labels) | |
| // Fetch existing labels in the repository to avoid "Label does not exist" errors | |
| const { data: repoLabels } = await github.rest.issues.listLabelsForRepo({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| per_page: 100, | |
| }); | |
| const existingLabelNames = new Set(repoLabels.map(label => label.name)); | |
| const labelsToAdd = Array.from(labels).filter(label => existingLabelNames.has(label)); | |
| if (labelsToAdd.length > 0) { | |
| await github.rest.issues.addLabels({ | |
| owner: context.repo.owner, | |
| repo: context.repo.repo, | |
| issue_number: context.payload.pull_request.number, | |
| labels: labelsToAdd, |
| } | ||
|
|
||
| private parseThread(tweets: any[]): XThread | null { | ||
| private parseThread(tweets: { created_at: string; [key: string]: any }[]): XThread | null { |
There was a problem hiding this comment.
Unexpected any. Specify a different type.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request makes minor updates to the
README.mdto clarify the project description and simplify the instructions for obtaining an xAI / Grok API key.