Power your agent
คำสั่งของผู้เผยแพร่เอง ไม่ใช่เอนด์พอยต์ของ PlugMCP
Host a copy with our keys and logs.
npx -y @debugbundle/[email protected]Claude Code ไม่มีลิงก์ติดตั้งสำหรับคำสั่งแบบโลคัล ให้คัดลอกคำสั่งด้านล่างแล้วรันในเทอร์มินัล
claude mcp add debugbundle-mcp -- npx -y @debugbundle/mcp@1.24.0รันในเทอร์มินัล
{ "mcpServers": { "debugbundle-mcp": { "command": "npx", "args": [ "-y", "@debugbundle/[email protected]" ] } }}claude_desktop_config.json
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
Production debugging bundles for AI agents, with runtime error reporting and incident response.
DebugBundle provides runtime error reporting, crash reporting, incident response, endpoint health checks, and product analytics for humans and AI agents. It captures runtime failures, groups them into incidents, and publishes deterministic debug bundles. Its monitoring scope is customer-facing runtime behavior and endpoint health, not generic infrastructure metrics.
MCP server for runtime error reporting, incident response, health checks, debug bundles, and product analytics
Works with AI coding agents including Codex, Claude Code, and Gemini CLI, as well as Cursor and GitHub Copilot. See the dedicated Codex, Claude Code, and Gemini CLI setup guides for native packages and direct MCP connections.
Modern AI agents are useful only when they get enough trustworthy context. DebugBundle packages the facts around a production incident into a versioned bundle instead of leaving agents to scrape dashboards, logs, traces, and chat threads.
Key properties:
.debugbundle/local/events/, then connect to DebugBundle Cloud when ready.Project owners can publish a status page from Project → Health → Public status page. The button sits immediately left of Create health check and opens the shared settings modal. Choose a title and checks using searchable multi-select dropdowns; optionally add projects you own in the same account through Other projects. Turn on Enable public page to save and publish the initial settings immediately, then copy the stable link from its read-only input using the copy icon on the right. Paste it into your website. For an existing page, the switch saves visibility immediately; other title/project/check edits need Save status settings. New checks remain private; turning off the switch removes public access when the automatic save succeeds. Preview status page opens the saved public view in a dialog. Closing settings discards unsaved edits; reopening loads the saved configuration.
Public pages follow the device light/dark setting, including changes while open, independently of your dashboard theme preference. They reuse Health Status rows and 30-day availability history with a small clickable logo above the underlined Powered by DebugBundle attribution. Daily tooltips update on every adjacent block across the shared health views. Project/check names are public; endpoint URLs, errors, service/environment labels, incidents and account data remain private. API/CLI/MCP provide the same management operations. See the status-page contract and self-host deployment.
For local end-to-end verification, use the normal Docker stack (make dev), which initializes empty databases and migrates installed ones without resetting data. make dev-mock also simulates status settings, selection, preview, publish/unpublish and local anonymous pages for UI review. Restore real API routing with make dev-mock-off to verify persistence, authorization and migrations against the real stack. Follow the local verification checklist.
AnalyticsBundle extends debugging from incident evidence to product-usage evidence without turning DebugBundle into a long-term raw-event store. It is opt-in browser analytics for the questions a human or agent needs to improve a product: visits and active users, routes and funnels, device/browser/OS/language segments, feature use, friction markers, incident impact, and bounded structured journey replay.
See the repository public interface contract for API/CLI/MCP parity and the self-host guide for retention and upgrade behavior.
Choose the path that matches how you want to evaluate DebugBundle.
Use Cloud when you are preparing a hosted deployment or want team-visible incidents, alerts, webhooks, GitHub automation, API access, and MCP access.
npm install -g @debugbundle/cli
debugbundle setup
debugbundle login
debugbundle connect
debugbundle connect creates or selects a cloud project, creates a write-only project token, and updates .debugbundle/local/connection.json. Put the shown project token in your hosted environment:
DEBUGBUNDLE_PROJECT_TOKEN=dbundle_proj_xxxxxxxxxxxx
Add the smallest SDK or ingestion path that matches your app, deploy it with the token configured, then verify ingestion:
debugbundle verify cloud --project-id proj_01HXYZ... --trigger-5xx
debugbundle incidents --source cloud
debugbundle inspect inc_01HXYZ...
See the full Cloud quickstart and connect-to-cloud guide.
Use local-only mode when you want captured data and bundles to stay on the machine or storage volume where the SDK and CLI run.
npm install -g @debugbundle/cli
debugbundle setup --project-mode local-only
Initialize an SDK in local mode where supported, or use debugbundle watch for existing logs. After triggering a test error:
debugbundle process
debugbundle incidents --source local
debugbundle inspect inc_local_...
Local events are written under .debugbundle/local/events/; generated bundles are written under .debugbundle/bundles/. See the local-only guide.
All SDKs follow the same universal interface: init, captureException, captureError, captureLog, captureRequest, captureMessage, setContext, probe, and flush.
npm install @debugbundle/sdk-node
import { debugbundle } from "@debugbundle/sdk-node";
debugbundle.init({
projectToken: process.env.DEBUGBUNDLE_PROJECT_TOKEN,
environment: "production",
service: "api"
});
debugbundle.captureExceptions();
debugbundle.captureRejections();
Express, Fastify, Next.js, pino, winston, bunyan, local file transport, remote capture policy, probes, and browser relay handlers are supported.
npm install @debugbundle/sdk-browser
import { createDebugBundleBrowserSdk } from "@debugbundle/sdk-browser";
const debugbundle = createDebugBundleBrowserSdk();
debugbundle.init({
transportMode: "relay",
endpoint: "/debugbundle/browser",
environment: "production",
service: "web"
});
For full-stack apps, prefer a backend browser relay so project tokens stay server-side. Same-origin relay paths are simplest; split frontend/backend deployments can use explicit browser relay mode with an absolute backend relay URL and backend origin allowlisting. Frontend-only deployments can send directly to DebugBundle Cloud with a dedicated public write-only token and an allowed-origin restriction. See Browser Relay Setup.
pip install debugbundle-python
import os
import debugbundle
debugbundle.init(
project_token=os.environ["DEBUGBUNDLE_PROJECT_TOKEN"],
environment="production",
service="api",
)
debugbundle.capture_exceptions()
debugbundle.capture_logging()
Django, Flask, FastAPI, Python logging, structlog, loguru, local file transport, remote capture policy, probes, and browser relay helpers are supported.
composer require debugbundle/sdk-php
<?php
use DebugBundle\DebugBundle;
DebugBundle::init([
'projectToken' => getenv('DEBUGBUNDLE_PROJECT_TOKEN'),
'environment' => 'production',
'service' => 'api',
]);
DebugBundle::captureErrors();
DebugBundle::captureExceptions();
DebugBundle::captureShutdown();
Laravel, Symfony, Monolog, local file transport, remote capture policy, probes, and browser relay adapters are supported.
gem install debugbundle
require "debugbundle"
DebugBundle.init(
project_token: ENV["DEBUGBUNDLE_PROJECT_TOKEN"],
environment: "production",
service: "api"
)
DebugBundle.capture_exceptions
Rails, Rack, Sidekiq, Ruby Logger, Semantic Logger, local file transport, remote capture policy, probes, and browser relay handlers are supported.
<dependency>
<groupId>com.debugbundle</groupId>
<artifactId>debugbundle-spring-boot-starter</artifactId>
<version>0.1.0</version>
</dependency>
debugbundle:
project-token: ${DEBUGBUNDLE_PROJECT_TOKEN}
environment: production
service: api
project-mode: connected
The Spring Boot starter supports servlet request capture, MVC exception capture, Logback capture, remote config, probes, and an optional browser relay route.
go get github.com/debugbundle/debugbundle-go
client := debugbundle.New(debugbundle.Config{
ProjectToken: os.Getenv("DEBUGBUNDLE_PROJECT_TOKEN"),
Environment: "production",
Service: "api",
})
defer func() { _ = client.Flush(context.Background()) }()
net/http, Gin, Echo, slog, zap, zerolog, local file transport, remote capture policy, probes, and browser relay handlers are supported.
Install DebugBundle from the WordPress.org plugin directory, then open Settings -> DebugBundle and save your project token. The plugin bundles backend PHP capture, frontend browser capture, and a WordPress REST relay so the project token stays server-side.
The CLI is the daily operational entry point:
npm install -g @debugbundle/cli
debugbundle setup
debugbundle doctor
debugbundle verify local
debugbundle verify cloud --trigger-5xx
debugbundle incidents
debugbundle inspect <incident-id>
Automation can use the HTTP API directly or the MCP server for agent workflows:
Marketplace-managed MCP clients can run npx @debugbundle/mcp and provide DEBUGBUNDLE_MEMBER_TOKEN in the MCP server environment. The official MCP Registry name is com.debugbundle/mcp; project tokens are SDK write-only ingestion credentials and must not be used for MCP retrieval or management.
The separate OpenAI Plugin 1.0.0 production candidate combines a tailored skill with an OAuth-protected twenty-three-tool read-only remote projection plus the owner-approved existing-app consent, synthetic-reviewer, and Settings revocation surfaces. Its nine analytics tools expose bounded aggregate usage, route, device, acquisition, action, funnel, journey-pattern, and incident-impact metrics while excluding individual journeys, custom dimensions, analytics bundles/opportunities, and mutations. It is active at the permanent https://mcp.debugbundle.com/mcp origin for owner-approved Developer Mode validation, preserves the stdio/OpenClaw surface, and is not submitted, published, or publicly installable.
For local visual review without a real provider interaction, run make dev-openai-plugin-preview and open http://localhost:5291/__dev/openai-plugin. The opt-in development route uses the production UI components with deterministic synthetic data and provides every consent/reviewer/Settings state, all 64 scope subsets, and 390 px, 768 px, and 1280 px iframe viewports. Its actions stay in browser memory and never call OAuth, reviewer, grant, or revocation APIs. The route is absent from production builds, and preview evidence does not replace manual accessibility, MCP Inspector, outside-network reviewer, ChatGPT Developer Mode, deployed, submission, or publication validation.
apps/
api/ Fastify ingestion and retrieval API
worker/ BullMQ processing worker for normalization, grouping, bundles, alerts, and webhooks
cli/ @debugbundle/cli command-line interface
mcp/ @debugbundle/mcp server for agent workflows
web/ React/Vite app for interactive project and incident management
packages/
auth/ Auth, sessions, token generation, token hashing
bundle-engine/ Deterministic bundle assembly
event-normalizer/ Event validation, normalization, classification, fingerprinting
log-parser/ CLI log ingestion parser registry
redaction/ Sensitive data scrubbing
retrieval-client/ Shared retrieval API client used by CLI and MCP
shared-types/ Zod schemas, TypeScript types, bundle/event contracts
storage/ Postgres, Redis, S3-compatible storage adapters and migrations
sdks/
debugbundle-js/ Local clone of the JS SDK repo
debugbundle-python/ Local clone of the Python SDK repo
debugbundle-php/ Local clone of the PHP SDK repo
debugbundle-java/ Local clone of the Java SDK repo
debugbundle-go/ Local clone of the Go SDK repo
debugbundle-wordpress/ Local clone of the WordPress plugin repo
debugbundle-ruby/ Local clone of the Ruby SDK repo
site/
Public docs, marketing, reference, and blog site clone
The SDKs are standalone repositories under the debugbundle GitHub organization. This core repository owns the product services, shared contracts, CLI/MCP surfaces, and core-owned shared JS packages.
Use the Make targets so routine commands run in Docker-scoped environments.
make install
make infra-up
make infra-bootstrap
make dev
Local services:
Useful checks:
make lint
make typecheck
make test
make build
make ci
make dev requires DEBUGBUNDLE_PROBE_TRIGGER_SECRET and ANALYTICS_HASH_SECRET in .env. Start from .env.example, then keep local-only overrides in .env.local when needed.
After make install, run make dev-mock and open http://localhost:5291/dashboard.
It restarts only the web container and automatically signs the preview in as
[email protected]. Synthetic projects, incidents, improvements, 30-day health
history, alert/capture rules, webhook endpoints and delivery history, project and
member tokens, members/invitations, billing, provider connections, and GitHub
deliveries are served locally, so the data works in your ordinary browser.
SayCheese has analytics enabled with sample funnels, flows, journeys, opportunities
and generated artifacts. TaskTime includes empty and analytics-disabled states.
Project edits, incident/improvement actions, rule and health-check edits, webhook
creation/tests, token creation/revocation, invitations/member edits, probe
activation, weekly reports, repository selection, and analytics settings/flows/
funnels/bundle generation and public status publication are simulated in memory.
Public status pages start private; select checks and publish in Project Health to
open a loopback share link. Mock project/check IDs use UUIDs so the normal strict
forms work, including newly created records. Publication choices paginate, new
checks remain private, and restarting resets publications along with other edits.
Failed-delivery clearing uses
the normal browser-only behavior. Billing checkout and portal links stay in the
local preview; capacity changes only update mock state. Mock credentials are
deliberately unusable with real installations. No real checks, notifications,
GitHub dispatches, OAuth interactions, payments or database writes are made.
Unknown API operations still return an explicit preview error without contacting
the backend. External provider authorization and private operator tools require
normal development. After a mock logout, use any valid email and code 123456 to
return to the demo account; the same code is used for simulated account deletion.
make dev-mock again to reset the simulated server data. Browser preferences
and cleared-delivery IDs remain in local storage; use Show cleared to inspect them.make dev-mock-off to return the frontend to your real local API.The supported self-host bootstrap lives in deploy/selfhost/.
git clone https://github.com/debugbundle/debugbundle.git
cd debugbundle/deploy/selfhost
cp .env.example .env
docker compose up -d
The self-host stack includes the web app, API, worker, PostgreSQL, Redis, and LocalStack S3. See Self-Hosting and deploy/selfhost/README.md.
The canonical public product release is the root debugbundle repository tag and GitHub Release (v*). Package-specific releases are separate:
cli-v* for @debugbundle/climcp-v* for @debugbundle/mcpshared-js-v* for @debugbundle/shared-types and @debugbundle/redactionStandalone SDK repositories publish and version their own release surfaces independently:
debugbundle-js for @debugbundle/sdk-node and @debugbundle/sdk-browserdebugbundle-python for debugbundle-pythondebugbundle-php for debugbundle/sdk-phpdebugbundle-java for Maven artifactsdebugbundle-go for Go modulesdebugbundle-wordpress for the WordPress pluginThe v1 release train publishes dependency roots before dependent wrappers:
@debugbundle/shared-types and @debugbundle/redaction from the core repo first.@debugbundle/sdk-node and @debugbundle/sdk-browser from debugbundle-js after the matching shared-package version exists on npm.Our own hosted/source-deployed dogfooding surfaces intentionally consume published packages rather than implicit workspace links. After a successful registry publish, bump the pinned versions in the root package.json, hosted app apps/web/package.json, and public-site site/package.json before running hosted validation or deployment.
Read CONTRIBUTING.md before opening a pull request. The short version:
make lint, make typecheck, make test, and make build before asking for review.Do not report vulnerabilities in public issues. Use GitHub private vulnerability reporting for this repository:
See SECURITY.md for scope and response expectations.
DebugBundle core, SDKs, and executable developer tools use Apache-2.0. Service-required exceptions are limited to the WordPress plugin (GPL-2.0-or-later) and portable ClawHub/Smithery instruction skill (MIT-0). See the licensing policy.
The web app vendors the unchanged shadcn 4.1.2 Tailwind stylesheet in
apps/web/src/styles/shadcn.css, including its upstream MIT license. This preserves
the current component animations and data variants without installing the component
generator and its unused vulnerable glob-parser dependency in the app. Existing
shadcn components and components.json remain the source of the UI. Inspect component docs with make ui-component-docs UI_COMPONENTS='dialog input-group' and preview registry changes with make ui-component-add UI_COMPONENTS=input-group UI_COMPONENT_FLAGS='--dry-run'. Review existing component differences before applying changes; preserve local primitives and shared utilities. Run the
component generator separately through its package runner when needed, and review
any generated dependency/import changes against the dependency audit before adoption.
make audit checks the installed dependency graph for high and critical advisories;
core CI and core publication enforce the same threshold. Dependency refreshes use
bounded vulnerable-version overrides and preserve independently published SDK pins.
MCP server for runtime error reporting, incident response, health checks, debug bundles, and product analytics
{ "mcpServers": { "debugbundle-mcp": { "command": "npx", "args": [ "-y", "@debugbundle/[email protected]" ] } }}เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
@debugbundle/mcp ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-11-14 MCP server for runtime error reporting, incident response, health checks, debug bundles, and product analytics