The MCP Family in My Dev Environment: A Full Overview

Preface

If you use AI coding assistants regularly, you have surely heard of MCP. It is becoming the “lingua franca” through which AI applications connect to the outside world. This article is not a rehash of the protocol spec — it is a full overview of the MCP servers I actually run in my current dev environment: what each one is, what it can do, its representative tools, and how to combine them into practical workflows.

1. What is MCP

MCP (Model Context Protocol) is an open protocol that addresses an age-old problem: how AI applications can access external tools and data in a standardized way.

Before MCP, every AI application integrating with every tool had to write a private adapter — like every appliance needing its own proprietary socket. MCP defines a unified “socket standard”:

• MCP Server: exposes capabilities, e.g. “I have a code graph you can query” or “I can control a browser”.
• MCP Client: AI applications (such as Codex, Claude Desktop) connect to these servers and hand tool calls to the model.
• Tools: callable capabilities exposed by the server. Each tool has a name, parameters and a description; the model picks the right tool for the task automatically.

In one sentence: MCP is the USB-C of AI — one protocol, everything connected.

2. Overview of my MCP environment

Here is the list of MCP servers actually available in my environment (as of August 2026):

Server	Role	Representative capabilities
codebase-memory-mcp	Code knowledge graph	Whole-repo indexing, graph search, call-chain tracing, architecture analysis
godot-mcp	Godot game engine	Scene building, scripting, shaders, animation, run and export
playwright	Browser automation	Navigate, click, screenshot, network capture, accessibility snapshot
local_rag	Local vector knowledge base	Document ingestion, hybrid retrieval, incremental sync
node_repl	Node.js executor	Persistent kernel to run JS, dynamically load npm packages
chart_mcp	Data visualization	matplotlib / seaborn / pyecharts chart generation
imagemagick_mcp	Image processing	Format conversion, filters, metadata reading
multi_agent	Multi-agent orchestration	Parallel subtasks, pipeline collaboration

Let’s go through them one by one.

3. An individual look

1. codebase-memory-mcp: turning the repo into a queryable graph

This is the one I use most. It indexes the entire code repository into a semantic knowledge graph: functions, classes, routes and files as nodes; calls, dependencies and data flows as edges.

Core tools:

Tool	Purpose
index_repository	Full index of the repo (supports full / moderate / fast modes)
search_graph	Search code symbols via keyword, regex or semantic modes
trace_path	Trace call chains: who calls it, and who it calls
get_code_snippet	Directly read the source of a function/class
query_graph	Write complex Cypher queries, e.g. find hot functions with excessive cyclomatic complexity
get_architecture	One-click architecture overview (Leiden community detection auto-partitions modules)
detect_changes	Compare branches/time points to detect code changes and impact
manage_adr	Distill architecture insights into Architecture Decision Records

Two interesting capabilities:

• Hot-path analysis: the graph annotates every function with complexity attributes like transitive_loop_depth (transitive loop depth) and linear_scan_in_loop (linear scans inside loops); a single Cypher query can surface potential O(n²) hazards.
• Cross-repo tracing: by matching HTTP route nodes, you can identify inter-service call relationships.

Taking this repo (zhimalab, an Astro static site) as an example, the index result is 13,408 nodes and 48,074 edges — afterwards, all code lookups go through the graph instead of raw grep.

2. godot-mcp: driving the game engine with AI directly

Godot is an open-source game engine; godot-mcp exposes the editor’s capabilities as 100+ tools covering nearly the whole game-development pipeline:

• Scenes: create_scene / add_node / clone_node / edit_scene batch operations
• Scripting: create_script / write_script / validate_script, even editor_run_gdscript to execute code right in the editor context
• Rendering: create_shader / write_shader, plus VisualShader node-graph editing
• Animation & physics: animation tracks and keyframes, collision bodies, physics materials, joints, vehicles
• Run & validate: editor_play / run_project / capture_screenshot / export_project / validate_project

This means AI can form a closed loop of “build a scene → write scripts → run it → screenshot to inspect → fix bugs”, instead of just generating code you have to paste in manually.

3. playwright: giving AI a browser that can see and click

Playwright is a well-known browser automation framework. As an MCP, it lets the model operate a real browser directly:

• Interaction: browser_navigate / click / type / fill_form / select_option / drag
• Observation: browser_snapshot (accessibility-tree snapshot — better suited than a screenshot for AI to “understand” a page), browser_take_screenshot
• Diagnostics: browser_network_requests to capture API requests, browser_console_messages to read console errors
• Advanced: browser_run_code_unsafe to execute arbitrary Playwright code snippets

Typical scenario: after writing a page, let AI open the browser itself, visit, click, and screenshot to verify the styling — much faster than manual verification.

4. local_rag: a private knowledge base that runs locally

local_rag is a fully-local RAG (retrieval-augmented generation) service:

• ingest_file: ingest PDF / DOCX / TXT / Markdown
• ingest_data: ingest in-memory content like scraped web text and clipboard
• query_documents: hybrid retrieval (keywords + semantic vectors)
• read_chunk_neighbors: inspect context around a hit
• sync_start: reconcile with disk, incrementally ingest and auto-clean deleted files

Its biggest value is privacy: documents never leave the machine — ideal for sensitive material like product docs, personal notes, or paper PDFs.

5. node_repl: a resident Node execution environment

node_repl provides a persistent Node.js kernel; the benefit is state persists across calls:

• Run arbitrary JavaScript (supports top-level await)
• Dynamically import npm packages (pair with js_add_node_module_dir to add module search paths)
• Resident variables and bindings reusable across calls
• Can even interoperate with libraries like Playwright

It suits scenarios that truly need execution: data processing, script validation, algorithm experiments.

6. chart_mcp: charts in one sentence

generate_chart renders charts internally with Python (matplotlib / seaborn / pyecharts), outputting PNG / SVG / interactive HTML, while list_charts manages the artifacts. Great for pairing data charts with tech blog posts.

7. imagemagick_mcp: an image-processing toolbox

A wrapper around ImageMagick:

• magick_convert: format conversion, resize, compression, grayscale
• magick_filter: blur, sharpen, sketch, oil paint, desaturate and other filters
• magick_info: read metadata such as format, dimensions, color space, bit depth

8. multi_agent: getting multiple AIs to work in parallel

Beyond single-machine tools, my environment also supports multi-agent orchestration: spawn_agent creates sub-agents, send_input dispatches tasks, wait_agent waits for results. It is ideal for splitting “research”, “implementation” and “testing” into independent parallel tasks.

4. Skills: another layer of “capability packs”

Alongside MCP servers there is a Skills mechanism — reusable instruction documents that encode the complete “how to do X” process:

Skill	Purpose
imagegen	AI-generated/edited bitmap images
archify	One-click architecture / sequence / flow diagrams (HTML+SVG, exportable)
openai-docs	Retrieve OpenAI official documentation
plugin-creator / skill-creator / skill-installer	Create, install and manage Codex plugins and skills
browser:control-in-app-browser	Control the in-app browser
template-creator	Turn reference documents into reusable templates

In simple terms: MCP manages the “hands” (what tools can be called), Skills manage the “brain” (knowing how to do it).

5. Combined workflows

A single tool is a point; combined, they form a plane. Here are a few combos I actually use:

Workflow 1: quickly understand an unfamiliar repo

index_repository  →  search_graph to find entry symbols
                  →  trace_path to trace call chains
                  →  get_code_snippet to read key implementations
                  →  get_architecture to see the overall architecture

Workflow 2: writing a tech blog with data charts

chart_mcp generates data charts (PNG/SVG)
  →  imagemagick compresses / crops / adds watermark
  →  Playwright screenshots to verify page layout

Workflow 3: AI-assisted game development

godot-mcp builds scenes + writes scripts
  →  editor_play to run
  →  capture_screenshot to inspect
  →  validate_project to verify reference integrity

Workflow 4: private document Q&A

local_rag ingests PDFs / web pages
  →  query_documents retrieves answers (data never leaves the machine)

Workflow 5: web feature verification

Playwright opens the page → snapshot to understand structure → click / fill forms
  →  network_requests to capture APIs → console to check errors → screenshot for records

6. Lessons and reminders

1. Tools are for humans, and names follow patterns. MCP tools are usually exposed as mcp__server__tool; seeing the name tells you which server it comes from.

2. Be permission-aware. For tools like browser automation, file writing and media permissions, confirm the scope of effect — especially “arbitrary code execution” capabilities like browser_run_code_unsafe.

3. Local-first. Services like local_rag and codebase-memory run locally; data never leaves your machine, so sensitive projects can use them with confidence.

4. Combinations matter more than single points. A single MCP server is just a capability unit; real efficiency gains come from orchestrating them into workflows — and that’s what I want to stress at the end of this article: in the second half of AI coding, the competition is not about the model, but the ecosystem of tools around it.

Conclusion

MCP turned “AI can only chat” into “AI can get work done.” From code graphs to game engines, from browsers to local knowledge bases, this ecosystem is maturing fast. If you haven’t tried it yet, start with one or two high-frequency scenarios: install a knowledge-graph server for code understanding, or a Playwright server for web verification — the moment you experience “AI opening a browser itself to check a page”, there’s no going back.