DEV Community: Trần Hoàng Tú

Why I Built Chrome DevTools for AI Agents — AgentLens

Trần Hoàng Tú — Sun, 29 Mar 2026 18:27:04 +0000

My AI agent kept failing in production. The error showed up at step 7, but the actual bug was at step 3. I spent 4 hours reading through trace logs before finding it.

That's when I realized: we need Chrome DevTools for AI agents.

The Problem Nobody Talks About

Everyone's building AI agents. LangChain, CrewAI, AutoGen — the frameworks are amazing. But when your agent breaks in production, you're on your own.

Traditional logging gives you API calls and timestamps. But it doesn't answer:

Why did the agent choose tool A over tool B?
Where exactly did the reasoning go wrong?
Was it a context window overflow or a hallucinated tool call?

I've debugged hundreds of AI agent failures. The patterns are always the same:

Context window overflow — agent stuffs too much into the prompt
Tool selection errors — wrong tool for the task
Infinite loops — agent keeps retrying the same failed approach
Hallucinated tool calls — agent invents tools that don't exist
Missing error handling — silent failures cascade

What I Built

AgentLens is an open-source, self-hosted observability platform. Think of it as Chrome DevTools, but for AI agents.

Trace Everything

Drop in 2 lines of code:

import agentlens

@agentlens.trace
def my_agent(query):
    # Every tool call, LLM call, and decision is recorded
    pass

Replay Like a Flight Recorder

Time-travel through your agent's execution step-by-step. See exactly what happened at each point. Edit inputs at any step and see how the output changes.

AI Autopsy (My Favorite Feature)

Click "Autopsy" on a failed trace. AI analyzes the full execution tree and tells you:

Root cause: "Context window overflow at step 4"
Severity: Critical
Suggested fix: "Add a summarization step between search and analysis"

This is the feature no one else has. LangSmith doesn't have it. Langfuse doesn't have it.

MCP Protocol Tracing

If you're using MCP (Model Context Protocol) — which Claude, Cursor, and Windsurf all use — AgentLens is the only tool that traces MCP calls visually.

from agentlens.integrations.mcp import patch_mcp
patch_mcp()  # Auto-instruments all MCP tool calls

Why Self-Hosted?

I believe your agent data should stay on your infrastructure:

No vendor lock-in
No data leaving your network
No per-seat pricing
Free forever, unlimited traces

The Tech Stack

Backend: FastAPI + SQLModel (SQLite for dev, PostgreSQL for prod)
Dashboard: React 19 + Vite + Tailwind CSS
SDKs: Python, TypeScript, .NET 8, Go CLI
Deploy: docker compose up — that's it

Try It

pip install agentlens-observe
docker compose up  # Dashboard at http://localhost:3000

GitHub: github.com/tranhoangtu-it/agentlens

Star it if you find it useful. Every star helps an open-source developer keep going.

How I Built mcpman — A Universal MCP Server Package Manager for 10+ AI IDEs

Trần Hoàng Tú — Thu, 26 Mar 2026 03:15:21 +0000

When I first started working with the Model Context Protocol (MCP), I noticed something frustrating: each AI IDE had its own way of managing MCP servers. Claude Desktop had one config format, VS Code needed another, Cursor required yet another approach.

That's when I built mcpman — a universal package manager for MCP servers that works seamlessly across Claude, VS Code, Cursor, Windsurf, Zed, and 10+ other AI IDEs.

The Problem: MCP Configuration Chaos

The Model Context Protocol opened up incredible possibilities for AI-assisted development. But each IDE implemented MCP differently:

Claude Desktop uses a JSON config file in a specific directory
VS Code extensions need settings in settings.json
Cursor has its own configuration system
Windsurf, Zed, Codeium, Aider — all different

If you wanted to use the same MCP server across multiple IDEs, you'd manually find the right config file for each IDE, learn the specific format, keep them in sync, and debug inconsistencies.

Why I Built mcpman

The real catalyst came when I was helping a colleague set up multiple MCP servers. We spent 45 minutes just getting the configurations right.

That's when I asked: What if there was a single command-line tool that could install, manage, and update MCP servers across all IDEs at once?

# Install an MCP server once, and it works everywhere
mcpman install postgres-server

# List all installed servers
mcpman list

# Remove a server across all IDEs
mcpman uninstall postgres-server

Architecture & Tech Decisions

Why TypeScript

Cross-platform — Works on macOS, Linux, Windows
IDE agnostic — Parse and write to different config formats
Fast iteration — Mature ecosystem for file manipulation
Familiar — Most developers using AI IDEs know JavaScript

The Core Architecture

mcpman is built around a few key concepts:

Config Adapters — Each IDE has an adapter that knows how to read/write its native config format.

Server Registry — A central registry of known MCP servers.

CLI Interface — Simple commands that delegate to the right adapter.

Sync Engine — Detects changes and propagates across IDEs.

┌─────────────────────────────────┐
│         CLI Commands            │
│  (install, list, uninstall)     │
└────────────┬────────────────────┘
             │
┌────────────▼────────────────────┐
│      mcpman Core Engine         │
│  (Config parsing, validation)   │
└────────────┬────────────────────┘
             │
    ┌────────┴────────┬─────────┬──────────┐
    │                 │         │          │
┌───▼────┐  ┌────┬────▼──┐  ┌──▼────┐  ┌─▼────┐
│ Claude │  │VS  │ Cursor │  │Zed    │  │...   │
│Desktop │  │Code│        │  │       │  │      │
└────────┘  └────┴────────┘  └───────┘  └──────┘

Config Adapter Pattern

Each IDE gets its own adapter class:

interface ConfigAdapter {
  read(path: string): Promise<ServerConfig[]>;
  write(path: string, config: ServerConfig[]): Promise<void>;
  getConfigPath(): string;
}

This means adding support for a new IDE = implementing one adapter class.

The Team Sync Feature

One of my favorite features — share configurations via a manifest file:

// mcpman.json in your project
{
  "servers": [
    {
      "name": "postgres-server",
      "source": "npm:mcpman-postgres"
    },
    {
      "name": "api-client",
      "source": "github:myorg/mcp-api-client"
    }
  ]
}

Then anyone on your team runs:

mcpman sync

Team MCP configuration in minutes instead of hours.

Lessons Learned

1. Fragmentation is Real — Every single IDE does things differently. This is both a pain point and an opportunity.

2. Testing Across Platforms is Hard — macOS, Windows, Linux all handle file paths differently. Docker helped a lot.

3. Backwards Compatibility Matters — Even early on, breaking changes hurt. Now mcpman auto-migrates old configs.

4. Documentation is Everything — First version had great features nobody knew about. I now spend equal time on docs and code.

What's Next

GUI for managing servers
Central repository of verified MCP servers
Server versioning and auto-updates
IDE plugin that shows available servers in your editor

Try mcpman

npm install -g mcpman
mcpman list  # Detect your installed IDEs

⭐ github.com/tranhoangtu-it/mcpman

I'm Trần Hoàng Tú, a full-stack developer from Vietnam building practical open-source tools. Check out my other projects:

AI Hallucination Firewall — Pre-commit proxy detecting hallucinated code
AgentLens — Self-hosted AI agent observability
RT Translator Desktop — Offline meeting translation with Whisper + Ollama

Website: tuth.site | GitHub: @tranhoangtu-it

I built the missing package manager for MCP servers

Trần Hoàng Tú — Fri, 27 Feb 2026 17:30:17 +0000

If you use Claude Desktop, Cursor, VS Code, or Windsurf with MCP servers, you know the pain: manually editing JSON config files, each client storing configs differently, no way to know if a server is healthy, and no version pinning.

I built mcpman to fix this.

## What is MCP?

Model Context Protocol (MCP) is Anthropic's open standard that lets AI assistants connect to external tools and data sources. Think of MCP servers as plugins for your AI coding assistant.

The problem? Installing and managing these servers is still manual and fragmented.

## The gap nobody filled

I researched every existing tool:

| Tool | Focus | Limitation |
|------|-------|-----------|
| Smithery CLI | Registry | Claude-only, no health checks |
| mcpm.sh | Config editing | Limited multi-client, no lockfile |
| mcp-get | Package install | Dead (redirected to Smithery) |

Nobody owned the operational layer — health monitoring, version pinning, cross-client sync, reproducible setups.

## Enter mcpman


sh
  # Install an MCP server across all your AI clients
  npx mcpman install @modelcontextprotocol/server-filesystem

  # See what's installed with health status
  npx mcpman list

  # Run diagnostics
  npx mcpman doctor

  # Reproducible team setup
  npx mcpman init

  What it does

  - install <server> — resolves from npm, Smithery, or GitHub. Auto-detects installed clients and configures them all.
  - list — shows every installed server with health indicators (green/yellow/red).
  - doctor — runs 4-layer diagnostics: runtime check, env var validation, process spawn, MCP JSON-RPC handshake.
  - remove — clean uninstall from all clients at once.
  - init — creates mcpman.lock for reproducible team setups. Share your MCP config like you share package-lock.json.

  Multi-client support

  mcpman manages configs for all 4 major AI clients:

  - Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json
  - Cursor — ~/.cursor/mcp.json
  - VS Code — workspace .vscode/settings.json
  - Windsurf — ~/.codeium/windsurf/mcp_config.json

  One mcpman install writes to all of them.

  Architecture

  Built with TypeScript and these focused libraries:

  - citty — declarative CLI framework (zero boilerplate)
  - @clack/prompts — beautiful interactive UX
  - picocolors — terminal colors (3x smaller than chalk)
  - nanospinner — progress spinners

  The entire CLI is ~45KB bundled. No daemon, no background process.

  The doctor is in

  My favorite feature. mcpman doctor runs parallel health checks:

  1. Runtime check — is node/python/uvx installed?
  2. Env var validation — are required API keys set?
  3. Process spawn — does the server binary actually start?
  4. MCP handshake — does it respond to initialize JSON-RPC?

  npx mcpman doctor

    ✓ server-filesystem    healthy
    ⚠ server-github        missing GITHUB_TOKEN
    ✗ server-slack         process crashed

  Try it

  npm install -g mcpman
  # or just use npx
  npx mcpman install @modelcontextprotocol/server-filesystem

  59 tests passing. MIT licensed. Contributions welcome.

  GitHub: github.com/tranhoangtu-it/mcpman
  npm: npmjs.com/package/mcpman

  What's next (v0.2)

  - Encrypted credential management (no more API keys in JSON)
  - Cross-client config sync
  - Security scanning + trust scoring
  - Auto-update notifications

  ---
  What MCP server management pain points have you hit? I'd love to hear your feedback.