DEV Community: Albert Alov

How react-render-profile-mcp works under the hood - and what it found in a real project

Albert Alov — Fri, 22 May 2026 13:26:21 +0000

I've been building react-render-profile-mcp for a few months — an MCP server that decodes React DevTools Profiler exports so AI agents can diagnose and now fix render performance. Earlier posts covered v0.1 and v0.3.1. This is v1.0.

I want to do two things in this post: show what it actually found on a real open source project, then explain how the engine works inside — because "it's just an MCP wrapper" is not the right mental model. 🐸

Act 1 — What it found on slash-admin

I ran the full cycle on slash-admin, a real React admin dashboard with Zustand and React Router. Target: UserProfile in src/pages/management/user/profile/index.tsx.

Diagnostics

get_render_summary → find_spurious_renders → analyze_compiler_efficacy → suggest_memoization

12 spurious renders on UserProfile
42ms wasted
Trigger: UNSTABLE_PARENT_REF
Invalidation Index: 22.5
ROI score: 2.5 (threshold is 1.5)

The problem was two inline constants inside the render body:

function UserProfile() {
  const bgStyle: CSSProperties = {
    position: "absolute",
    inset: 0,
    background: `url(${bannerImage})`,
    backgroundSize: "cover",
    backgroundRepeat: "no-repeat",
  };

  const tabs = [
    { icon: , title: "\"Profile\" },"
    { icon: , title: "\"Followers\" },"
    // ...3 more
  ];

  return ( ... );
}

New object reference on every render. Every memoized child downstream gets invalidated on every pass, regardless of whether anything actually changed.

Auto-remediation and the edge case

remediate_component runs three AST passes. On this file it hit a real edge case immediately:

import type { CSSProperties } from "react";

Type-only import. Adding React.memo to the default export without fixing this would produce a runtime ReferenceError. The remediator detected it, rewrote the import, and continued:

-import type { CSSProperties } from "react";
+import React, { CSSProperties } from "react";

Then the three passes ran:

-function UserProfile() {
-  const bgStyle: CSSProperties = { position: "absolute", inset: 0, ... };
-  const tabs = [{ icon: , title: "\"Profile\" }, ...];"
+const bgStyle: CSSProperties = { position: "absolute", inset: 0, ... };
+const tabs = [{ icon: , title: "\"Profile\" }, ...];"

+function UserProfile() {
   const { avatar, username } = useUserInfo();
   return ( ... );
 }

-export default UserProfile;
+export default React.memo(UserProfile);

This gap in the original implementation was found by running on real code. A new unit test now covers the import type case. 57 tests passing.

42ms of spurious renders eliminated. Zero code written manually.

Act 2 — How it actually works inside

This is the part that matters if you want to understand what's happening, not just that it works.

Layer 1: decoding the profiler format

React DevTools exports version 5 — a format most developers have never had to parse manually. The tricky parts:

changeDescriptions is serialized as Map.entries(), not as a JSON object:

"changeDescriptions": [[3, {"isFirstMount": true}], [4, {"props": []}]]

The parser normalizes this on load into Record so the rest of the code can work uniformly.

operations is an opcode integer array encoding tree mutations. Format:

[rendererID, rootFiberID, stringTableSize, ...strings, ...opcodes]

Opcode 1 (ADD):    [1, id, type, parentID, ownerID, nameStringIdx, keyIdx]
Opcode 2 (REMOVE): [2, count, id1, id2, ...]
Opcode 3 (REORDER_CHILDREN): [3, id, count, ...childIds]

The parser walks this array to reconstruct the fiber name map, parent-child relationships, and unmount counts — all without a React runtime, just integer arithmetic and string table lookups.

Two name resolution strategies, with fallback:

Primary: snapshots map (human-readable, always preferred)
Fallback: decode the string table from operations opcodes

This dual strategy is what makes the parser robust against different DevTools export configurations.

Spurious render detection relies on one non-obvious React behavior: when a component re-renders due to an unstable prop reference but no prop values actually changed, React records props: [] (empty array) in changeDescriptions. props: null means unknown. props: ["value"] means the value prop genuinely changed. The parser uses exactly this signal:

function isSpurious(fiberID: number, commit: ProfileCommit): boolean {
  const desc = commit.changeDescriptions?.[String(fiberID)];
  if (!desc) return false;
  if (desc.isFirstMount || desc.context || desc.didHooksChange) return false;
  if (desc.state && desc.state.length > 0) return false;
  return desc.props !== null && desc.props.length === 0;
}

React 18 concurrent mode false-positive prevention: startTransition and useDeferredValue can cause a component to render multiple times as React speculatively renders and discards incomplete trees. These show up with priorityLevel: "Low Priority" or "Idle". The parser tracks these separately so they don't get flagged as regressions.

Layer 2: the Invalidation Index

analyze_compiler_efficacy computes a score per component:

I = (spurious_count / total_renders) × wasted_ms

This matters because raw wasted_ms alone can be misleading. A component with 100ms wasted across 100 renders (1ms each) has a very different profile than one with 100ms across 2 renders (50ms each). The index captures both the frequency and the cost — which is what determines whether React.memo overhead is actually worth it.

The threshold for suggest_memoization is avgSelfMs > 2ms. Below that, the Object.is comparison overhead of React.memo can exceed the render cost, making memoization actively harmful.

Layer 3: the AST remediation engine

ASTPerformanceRemediator uses ts-morph (TypeScript compiler API wrapper) to perform three passes over the source file:

Pass 1 — static hoisting. Walks the render body looking for VariableStatement nodes whose initializers are ObjectLiteralExpression or ArrayLiteralExpression. For each one, checks if any Identifier inside references a component-scope binding (props, state, hooks). If not — it's static and gets hoisted to module scope. This runs in a loop until no more hoistable statements are found, handling multiple declarations per component.

Pass 2 — useCallback wrapping. Walks ArrowFunction nodes inside the render body. For each one matching an unstable prop name, calls resolveReactiveDependencies — which walks all Identifier descendants of the arrow function and intersects them with the component's local scope bindings. This gives the dependency array automatically, without requiring the developer to reason about it manually.

Pass 3 — React.memo wrapping. Checks if ROI score exceeds 1.5, then finds the default export assignment and rewrites it. The import check (the edge case from slash-admin) now runs first: if the file only has import type ... from "react", it rewrites it to a value import before applying the wrapper.

All three passes operate on the live AST and call saveSync() once at the end — no intermediate file writes, no risk of partial state.

Why no React runtime dependency

Everything described above — opcode decoding, name resolution, spurious render detection, cascade tracing — runs on pure JSON and TypeScript. No React, no DevTools, no browser. This is intentional: the server needs to be fast to start (it runs as an npx command on every MCP client connection) and safe to run in any environment.

Setup

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Export a profile: React DevTools → Profiler tab → Record → interact → Stop → Save icon (💾). Pass the .json path as profile_path.

GitHub: vola-trebla/react-render-profile-mcp
npm: npx react-render-profile-mcp

Questions about the opcode decoder or the dependency inference logic welcome. 🐸

react-render-profile-mcp v0.3.1 - 4 new diagnostic tools for React Compiler, hydration, Zustand, and state cascades

Albert Alov — Fri, 22 May 2026 12:14:59 +0000

A few weeks ago I published a post about react-render-profile-mcp — an MCP server that decodes React DevTools Profiler exports so AI agents can actually diagnose render performance instead of guessing at raw fiber IDs.

v0.1 shipped with 5 tools. v0.3.1 adds 4 more, each targeting a class of problems the original couldn't touch. Here's what's new. 🐸

What was already there (v0.1)

Quick recap for anyone who missed the first post:

get_render_summary — total commits, render time, top components, lifecycle anomaly flags
find_spurious_renders — components that re-rendered with no actual prop/state change
get_hottest_components — ranked by CPU self-time
trace_render_cascade — what triggered a commit and what re-rendered as a result
suggest_memoization — ROI-scored React.memo recommendations

These covered the "something is rendering too much" class of problems. What they couldn't tell you: why your React Compiler isn't helping, where hydration broke, which Zustand selector is in a loop, or how deep a context update actually propagates.

What's new in v0.3.1

1. `analyze_compiler_efficacy`

React Compiler (React 19) and manual React.memo should eliminate spurious renders. Often they don't — because of inline object allocations or unstable parent refs that bypass memoization entirely.

This tool computes an Invalidation Index per component:

I = (spurious_count / total_count) × wasted_ms

High index = memoization is present but not working. The tool tells you exactly why:

{
  "severity": "CRITICAL",
  "component_name": "ProductList",
  "ineffective_render_count": 23,
  "wasted_ms": 84.3,
  "trigger_cause": "UNSTABLE_PARENT_PROP_REFERENCE",
  "recommendation": "Memoize parent props with useMemo/useCallback or hoist static objects out of the parent render function."
}

Without this, your agent might suggest adding React.memo to a component that already has it — and has it for a reason that makes it useless.

2. `diagnose_hydration_and_suspense`

Two separate problems, one tool:

Hydration mismatches — when React discards server HTML and remounts the entire tree from scratch. Shows up as an abnormally long initial mount with a spike of unmounts immediately after. The tool flags these as HYDRATION_MISMATCH_RECOVERY with the affected Suspense boundaries and blocking duration.

Suspense waterfalls — nested boundaries fetching sequentially instead of in parallel. Detected by measuring the gap between consecutive Suspense resolves against a configurable waterfall_threshold_ms (default: 100ms).

{
  "severity": "WARNING",
  "anomaly_type": "NESTED_MOUNT_FETCH_WATERFALL",
  "root_component": "ProfileDetails",
  "blocking_duration_ms": 120.5,
  "recommendation": "Prefetch data at the parent level or use Promise.all."
}

3. `evaluate_external_store_performance`

Zustand and Redux with useSyncExternalStore have two failure modes that are hard to catch manually:

Unstable selector object allocation — a selector returns a new object reference every call, triggering rapid consecutive renders. The tool detects components that render multiple times in consecutive frames and flags the selector as the cause.

Sync concurrency bypass — a heavy store update runs synchronously in a high-priority lane, blocking the main thread. Should be in startTransition instead.

{
  "severity": "CRITICAL",
  "impacted_components": ["CartSummary"],
  "is_infinite_loop": true,
  "trigger_cause": "UNSTABLE_SELECTOR_OBJECT_ALLOCATION",
  "recommendation": "Wrap the selector in useCallback or return primitive values."
}

4. `trace_state_cascade_footprint`

Given a commit index, this reconstructs the virtual component tree and measures how far an update actually propagated:

Which component triggered the update
Whether it went through a context provider or a store subscriber
How many levels deep it reached
How many consumer components re-rendered

{
  "severity": "HIGH_FOOTPRINT",
  "update_trigger_source": "ThemeButton",
  "propagation_channel": "CONTEXT_PROVIDER",
  "cascade_render_depth": 7,
  "rendered_consumer_count": 28,
  "recommendation": "Split the context provider or memoize its value and children."
}

This is the tool that answers "why did 28 components re-render when I clicked one button."

Updated: `find_spurious_renders` trigger classification

The existing tool now classifies why a render was spurious, not just that it was:

UNSTABLE_PARENT_REF — parent passed a new object/array/function reference with identical values
CONTEXT_UPDATE — context changed, but this component doesn't actually use the changed value
INTENTIONAL_CONCURRENT_YIELD — React's scheduler, not a bug

This matters because React.memo fixes the first case but can't help with the second. The recommendation now reflects the correct fix path.

Recommended agent workflow (updated)

1. get_render_summary              → overview + lifecycle_anomaly flags
2. find_spurious_renders           → classify unnecessary renders by trigger type
3. analyze_compiler_efficacy       → check where React.memo / Compiler is being bypassed
4. diagnose_hydration_and_suspense → catch hydration recovery + Suspense waterfalls
5. evaluate_external_store_performance → Zustand/Redux selector loops + sync bypasses
6. trace_state_cascade_footprint   → propagation depth for expensive commits
7. suggest_memoization             → ROI-scored final recommendations

Setup (unchanged)

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Export a profile from React DevTools → Profiler tab → Record → Save. Pass the .json path as profile_path to any tool.

npm: react-render-profile-mcp
GitHub: vola-trebla/react-render-profile-mcp

Happy to answer questions about the hydration detection heuristics or the Invalidation Index math. And if you're hitting a React performance pattern this doesn't cover yet — open an issue. 🐸

Your AI agent just read your .env file. You have no idea what it did next.

Albert Alov — Sun, 17 May 2026 19:10:59 +0000

AI agents are helpful, not malicious. That's what makes them dangerous around secrets. Here's an MCP server that catches secret exposure before the agent gets there.

Here's a scene that's more common than anyone admits.

You're debugging a config issue. You ask your AI agent to look at src/config.ts. The file has this:

export const config = {
  db: { url: process.env.DATABASE_URL, password: process.env.DB_PASSWORD },
  jwt: { secret: process.env.JWT_SECRET },
};

// Added during debugging last Tuesday, never removed
console.log("Config loaded:", JSON.stringify(config));
console.log(process.env.AWS_SECRET_ACCESS_KEY);

The agent reads the file, executes the tool, and your AWS secret key is now sitting in its context window. It might summarize it. It might include it in generated code. It might pass it to another tool that logs everything.

None of this requires the agent to be malicious. It just needs to be helpful.

env-secret-exposure-analyzer-mcp catches this before it happens. 🔐

🙈 The three ways secrets leak

1. Hardcoded in source files

The classic. Someone puts a token directly in code "just to test" and commits it. Or copies a .env value into a constant because it's easier. Or the most common one: a connection string with the password embedded right there in the URL.

DATABASE_URL=postgres://admin:p@ssw0rd123@prod.db.internal:5432/app

An agent reading any file that imports this config now has your prod database password.

2. `.env` not in `.gitignore`

Your .env has 40 keys. AWS credentials, Stripe keys, JWT secrets, OAuth tokens, encryption keys. It's not in .gitignore. One git push and it's in the repository forever — even if you delete it, it stays in git history.

The agent doesn't know this is dangerous. It reads files. That's its job.

3. `console.log` that never got removed

The debug line that gets committed on Friday and nobody notices until Monday. Except by then, every time the app starts, it dumps credentials to stdout. If you have log aggregation, those secrets are now in your observability platform too.

console.log("Starting server with config:", JSON.stringify(config));
// config contains { db: { password: "..." }, jwt: { secret: "..." } }

🔧 How the scanner works

Three tools, three attack surfaces.

`scan_for_secrets`

Scans source files, config files, and .env files for 20+ patterns. Returns severity, file, line, and a masked preview — the scanner never returns the full secret value, even in its own output.

After building the initial version with the obvious patterns (AWS, GitHub, Stripe), we did something simple: created a realistic .env with everything a real project might have and ran the scanner against it.

First run: 3 findings.

That's not good enough. A real .env has database URLs, JWT secrets, SendGrid keys, Twilio tokens, Google OAuth secrets, Sentry DSNs, webhook secrets, encryption keys. We were missing most of it.

We fixed the patterns:

Database URLs with embedded credentials — had to handle passwords containing @ (the character that separates credentials from host)
Stripe webhook secrets (whsec_), Google OAuth (GOCSPX-), Sentry DSN with flexible key length
Generic patterns for JWT secrets, session secrets, encryption keys — with a (?!process\.env) lookahead to avoid false positives on password: process.env.X which is actually correct code

After fixes: 16 findings. Everything in the file.

`check_gitignore_coverage`

Walks the project root and checks if sensitive files (.env, .env.local, secrets.json, private keys, certificates) are covered by .gitignore. Correctly ignores .env.example and .env.sample — those are supposed to be committed.

`scan_for_log_leaks`

Scans for console.log / logger calls that print process.env variables or objects with secret-sounding names. Catches both direct leaks:

console.log(process.env.AWS_SECRET_ACCESS_KEY); // HIGH

And indirect ones:

console.log("Config:", JSON.stringify(config)); // HIGH — config contains env vars
console.log("env:", process.env);               // CRITICAL — dumps everything

🐸 The most ironic moment of this build

When writing the tests, I created fixture files with fake-but-realistic secrets:

GITHUB_TOKEN=ghp_AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AWS_ACCESS_KEY_ID=AKIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

GitHub push protection blocked the push.

A secret scanner — blocked by GitHub's secret scanner — because its own test fixtures looked too much like real secrets. Even the obviously fake ones. ghp_ followed by 40 A's is still ghp_ followed by 40 alphanumeric characters, which is exactly the GitHub token format.

The fix: create fixture files programmatically in os.tmpdir() at test time. They never touch the git repo. The tests pass, the push goes through, and somewhere in the universe a security engineer nods approvingly.

beforeAll(() => {
  leakyDir = fs.mkdtempSync(path.join(os.tmpdir(), "env-mcp-leaky-"));
  fs.writeFileSync(
    path.join(leakyDir, ".env"),
    [`GITHUB_TOKEN=ghp_${"A".repeat(40)}`, `AWS_ACCESS_KEY_ID=AKIA${"A".repeat(16)}`].join("\n"),
  );
});

afterAll(() => {
  fs.rmSync(leakyDir, { recursive: true, force: true });
});

✅ Does it actually work?

After publishing, I verified the full MCP protocol layer — not just the functions in isolation, but the actual stdio transport that Claude Desktop uses:

printf '{"jsonrpc":"2.0","id":1,"method":"initialize",...}\n
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"scan_for_secrets",...}}\n' \
  | node dist/index.js

Response:

{
  "result": {
    "content": [{
      "type": "text",
      "text": "Secret Scan Results\n  Files scanned: 9\n  Findings: 16\n\n  [CRITICAL] .env:7 — Database URL with password\n  [CRITICAL] .env:17 — AWS Access Key\n  ..."
    }]
  },
  "jsonrpc": "2.0",
  "id": 2
}

Error handling too — bad path returns "isError": true with a readable message, doesn't crash the server.

For a security tool, "it compiles" is not good enough. The protocol has to work.

⚡ Setup

{
  "mcpServers": {
    "secret-scanner": {
      "command": "npx",
      "args": ["-y", "env-secret-exposure-analyzer-mcp"]
    }
  }
}

Then ask your agent:

"Scan this project for exposed secrets, check if .env is in .gitignore, and find any console.log calls that might be leaking credentials."

🐸 The pattern

Every tool in this series exists because an AI agent hits a wall — something it structurally cannot know without the right tool.

With secrets, the wall is subtle. The agent doesn't know what's sensitive just by looking. It doesn't know p@ssw0rd123 in a connection string is a production password. It doesn't know that JWT_SECRET=abc123verysecretkey in a .env file means something if that file gets committed.

The scanner knows. It has the patterns, the gitignore logic, the log analysis. It tells the agent exactly what's dangerous before the agent gets near it.

📦 Links

npm: npmjs.com/package/env-secret-exposure-analyzer-mcp
GitHub: github.com/vola-trebla/env-secret-exposure-analyzer-mcp

Your AI agent reads tsconfig.json. It has absolutely no idea what it means

Albert Alov — Sun, 17 May 2026 18:43:30 +0000

Your agent sees "extends": "@tsconfig/strictest" and hallucinates the rest. Here's an MCP server that uses the TypeScript compiler API to resolve the full inheritance chain and return what actually applies.

Here's a scene that happens more than you'd think.

You ask your AI agent to help with a TypeScript error. It reads your tsconfig.json, sees this:

{
  "extends": "@tsconfig/strictest",
  "compilerOptions": {
    "paths": { "@/*": ["./src/*"] }
  }
}

And confidently suggests:

// "This should work fine — I don't see strict mode enabled"
const users = getUsers();
const first = users[0].name; // ❌ Object is possibly 'undefined'

It's wrong. @tsconfig/strictest sets noUncheckedIndexedAccess: true. users[0] is User | undefined, not User. The agent doesn't know this because it never looked inside @tsconfig/strictest. It just guessed.

This is tsconfig-inheritance-flattener-mcp. 🔍

🙈 What the agent actually sees

When your agent reads tsconfig.json, it reads exactly what's in the file. Nothing more.

The extends field points to a package or another file — and the agent stops there. It doesn't chase the chain. It doesn't know what that base config sets. It fills in the blanks from training data, and training data is not your project.

In a typical monorepo this chain can be 3 levels deep:

apps/web/tsconfig.json
  → tsconfig.base.json
    → node_modules/@tsconfig/strictest/tsconfig.json

The final target, module, moduleResolution, strict, paths, baseUrl — all of it is scattered across these files. Without resolving the full chain, the agent is flying blind.

🔧 What the TypeScript compiler API actually knows

Here's the thing: TypeScript already solves this problem. Every time tsc runs, it resolves the full chain and produces a single merged set of compiler options. The API is right there:

const raw = ts.readConfigFile(configPath, ts.sys.readFile);
const parsed = ts.parseJsonConfigFileContent(
  raw.config, ts.sys, path.dirname(configPath), {}, configPath
);
// parsed.options = fully merged CompilerOptions ✅

We're not reimplementing anything. We're just exposing what TypeScript already computes — via MCP, so your agent can ask.

🛠️ Three tools

`get_effective_compiler_options`

Resolves the full extends chain and returns the merged options that actually apply. Enums come back as readable strings, not magic numbers ("ES2022" not 9, "NodeNext" not 199).

Effective TypeScript Configuration
  Config:            /project/apps/web/tsconfig.json
  Inheritance chain: /project/apps/web/tsconfig.json
                     → /project/tsconfig.base.json
                     → node_modules/@tsconfig/strictest/tsconfig.json

Compiler Options (merged):
  target: "ES2022"
  module: "NodeNext"
  moduleResolution: "NodeNext"
  strict: true
  noUncheckedIndexedAccess: true
  exactOptionalPropertyTypes: true
  baseUrl: "/project"
  paths: { "@/*": ["apps/web/src/*"] }

Now the agent knows why users[0] is User | undefined. No guessing.

`resolve_module_alias`

Maps @/hooks/useAuth to the physical file on disk. Uses the resolved paths and baseUrl from the full inheritance chain — not just what's in the nearest tsconfig.json.

Alias Resolution: @/hooks/useAuth
  Config:   /project/apps/web/tsconfig.json
  Base URL: /project

Resolved physical paths:
  /project/apps/web/src/hooks/useAuth.ts   ✓ exists

When the agent needs to navigate to the file behind an import, it no longer has to guess the folder structure.

`analyze_project_references`

Validates the references array in monorepo root configs. Checks that each referenced package has composite: true — without it, TypeScript's incremental build silently breaks.

Project References Analysis
  Config: /project/tsconfig.json
  References found: 2

  [✓] packages/shared → /project/packages/shared/tsconfig.json
  [✗] packages/legacy → /project/packages/legacy/tsconfig.json (NOT FOUND)

Violations:
  ✗ packages/shared is referenced but does not have composite: true
    Fix: add "composite": true to packages/shared/tsconfig.json

⚡ Setup

{
  "mcpServers": {
    "tsconfig-flattener": {
      "command": "npx",
      "args": ["-y", "tsconfig-inheritance-flattener-mcp"]
    }
  }
}

That's it. Works in Claude Desktop, Cursor, or any MCP-compatible client.

🐸 The pattern

Every MCP server in this series follows the same logic: find a place where an AI agent is structurally blind — not because it's dumb, but because it literally cannot see the data — and expose that data via a tool.

tsconfig.json inheritance is a perfect example. The agent isn't hallucinating out of laziness. It's hallucinating because the information it needs is locked inside a chain of files it never opened, or inside a npm package it can't inspect at runtime.

The TypeScript compiler API already resolves all of this. We just asked it nicely. 🔍

📦 Links

npm: npmjs.com/package/tsconfig-inheritance-flattener-mcp
GitHub: github.com/vola-trebla/tsconfig-inheritance-flattener-mcp

Your CI Is Always Broken. Your AI Agent Has No Idea What to Do About It.

Albert Alov — Sat, 16 May 2026 21:05:58 +0000

In any real codebase, CI always has something failing. The hard part isn't finding failures — it's knowing which ones block a release. Here's an MCP server that answers that question automatically.

Here's the situation every engineer knows:

You open CI. Something's failing. You need to ship.

Is it a real regression? A known flaky test? An infra blip that'll pass on retry? You open the logs, grep for errors, cross-reference with last week's run history, check what files changed in the PR, and 20 minutes later you have an answer.

Your AI agent can't do any of that. It sees the same raw logs you do. It doesn't know your flakiness history. It doesn't know which tests are affected by the code change. It guesses.

release-readiness-triage-mcp fixes this. 🚦

🧠 The three signals that actually matter

Triaging a CI failure requires correlating three things simultaneously:

1. Error signature deduplication

If 40 tests failed with ECONNREFUSED 127.0.0.1:5432, that's one problem (database didn't start), not 40. Grouping by normalized error signature tells you the real shape of the failure.

2. Flakiness history

Some tests fail 70% of the time on a good day. If a test has a 0.73 flaky probability in your history, its failure today tells you nothing about the code.

3. Code-change correlation

If Button.test.tsx is failing and Button.tsx is in the diff, that's suspicious. If AuthFlow.test.tsx is failing and nothing in auth changed, that's noise.

Without all three signals in one place, you can't answer "is this safe to release?" You just accumulate tabs.

🛠️ The 4 tools

`aggregate_suite_failures`

First pass: normalize, deduplicate, categorize.

CI Run Summary
  Total tests:   847
  Passed:        842
  Failed:        5
  Failure rate:  0.59%
  Error groups:  3

Failure Groups (by frequency):
  [NETWORK] 2x — connect ECONNREFUSED 127.0.0.1:Xms
    • API Suite > health check
    • API Suite > readiness probe
  [ASSERTION] 2x — expect(received).toBe(expected)
    • Search Suite > debounce timing
    • Search Suite > sort order
  [ASSERTION] 1x — Expected null, got <button>Submit</button>
    • Button Suite > renders button correctly

Supports customInfraPatterns — pass cloud-specific strings like "GCP quota exceeded" or "No space left on device" to classify them as infrastructure noise instead of unknown failures.

`cross_reference_flakiness`

Takes your flakiness database and scores each failure:

Flakiness Cross-Reference

  [KNOWN FLAKY] Auth Suite > login with expired token
    Flaky probability: 73%
  [MILDLY FLAKY] Search Suite > debounce timing
    Flaky probability: 22%
  [NO HISTORY] Button Suite > renders button correctly
    Not found in flakiness database

`correlate_code_changes`

Matches changed files against failing tests. Works standalone or with pre-computed affected test lists from ast-impact-mapper-mcp:

Code Change Correlation
  Changed files: 2
  Pre-identified affected tests: 1

  [CORRELATED] Button Suite > renders button correctly
    → Matched via affected test list
  [NOT CORRELATED] Search Suite > debounce timing
  [NOT CORRELATED] Auth Suite > login with expired token

`generate_release_recommendation`

The final step. Everything combined into one verdict:

## 🔴 Release Recommendation: NO_GO (75% confidence)

> 1 confirmed regression(s) directly correlated with code changes. Do not release.

| Category            | Count |
|---|---|
| Total failures      | 5     |
| 🔴 Real regressions | 1     |
| 🟡 Known flaky      | 2     |
| ⚪ Infra blips      | 2     |
| ❓ Unknown          | 0     |

### 🔴 Blockers (must fix before release)

**Button Suite > renders button correctly**
- Test is directly affected by code changes in this commit
- `Expected null, got <button>Submit</button>`

### ✅ Safe to ignore

- ~~Auth Suite > login with expired token~~ — Historically flaky: 73% failure rate in history
- ~~API Suite > health check~~ — Error pattern matches infrastructure issues (network)
- ~~Search Suite > debounce timing~~ — Mildly flaky: 22% historical failure rate
- ~~Storage Suite > upload avatar~~ — Error pattern matches infrastructure issues (network)

Pass format: "markdown" and the output is ready to paste directly into a GitHub PR comment or Slack message.

🔗 It's a meta-orchestrator

This MCP is designed to sit on top of the other tools in the ecosystem:

flakiness-knowledge-graph-mcp builds the flakiness database from run history — feed its output into cross_reference_flakiness
ast-impact-mapper-mcp computes which tests are affected by a code change via TypeScript AST — feed its output into correlate_code_changes
playwright-trace-decoder-mcp decodes trace files for individual failure root-cause — use it after getting a NO_GO to understand the blocker

The agent orchestrates the chain. Each MCP handles one thing it couldn't do without tool access.

⚡ Setup

{
  "mcpServers": {
    "release-readiness-triage": {
      "command": "npx",
      "args": ["-y", "release-readiness-triage-mcp"]
    }
  }
}

Then just ask:

"Here are the failures from CI, our flakiness history, and the files changed in this PR. Is it safe to release?"

One answer. No log reading.

📦 Links

npm: npmjs.com/package/release-readiness-triage-mcp
GitHub: github.com/vola-trebla/release-readiness-triage-mcp

npx release-readiness-triage-mcp

Your AI Agent Just Broke Your React Performance. It Has No Idea

Albert Alov — Sat, 16 May 2026 20:27:07 +0000

React DevTools Profiler gives you all the data you need to fix re-renders. Your AI agent can't read it. Here's how to fix that with an MCP server.

You open React DevTools Profiler, record a session, and export the .json file. It's got everything: which components re-rendered, how long each one took, which props changed, which hooks fired.

Then you paste it into Claude or Cursor and ask: "What's causing the performance problem?"

The agent stares at raw JSON — thousands of lines of fiber IDs, opcode arrays, and microsecond timestamps — and does its best. But it's reading tea leaves. It doesn't know what a "spurious render" is in this format. It can't decode the operations integer array. It doesn't know that props: [] means a component re-rendered even though no props actually changed.

That's the gap react-render-profile-mcp fills. 🔍

🤔 What the profiler actually exports

React DevTools serializes profiler data in a specific binary-ish format that most developers have never had to parse manually:

{
  "version": 5,
  "dataForRoots": [{
    "commitData": [{
      "changeDescriptions": [[3, {"isFirstMount": true, "props": null}], [4, {...}]],
      "fiberActualDurations": [[3, 15.2], [4, 8.1]],
      "fiberSelfDurations": [[3, 3.9], [4, 4.9]],
      "duration": 15.2,
      "timestamp": 100.0
    }],
    "snapshots": [[3, {"displayName": "App", "children": [4, 5]}]],
    "operations": [1, 0, 3, 2, 65, 112, 112, ...]
  }]
}

A few non-obvious things buried in there:

⚠️ changeDescriptions is an array of pairs, not an object. It's serialized as Map.entries() — [[fiberID, desc], ...]. If you parse it naively as JSON object keys, you'll get garbage.

⚠️ props: [] means spurious render. An empty array means the component re-rendered but zero prop keys actually changed — the reference was unstable. props: null means unknown. props: ["value"] means the value prop genuinely changed.

⚠️ operations is an opcode array. It encodes tree mutations (mount, unmount, reorder) with a string table at the start. You need to decode it to map fiber IDs to component names when snapshots aren't present.

⚠️ fiberSelfDuration ≠ fiberActualDuration. Self = time in this component only. Actual = self + children. For finding hotspots, you want self time.

The MCP server handles all of this so the agent doesn't have to.

🛠️ The 5 tools

`get_render_summary`

High-level overview of the entire recording:

Total commits: 12
Total render time: 847.3ms
Spurious renders: 8
Top components by self time:
  ProductList — 312.4ms (6 renders)
  SearchInput — 89.1ms (12 renders)
  Sidebar — 44.2ms (3 renders)

`find_spurious_renders`

Detects components that re-rendered but had no actual prop or state changes:

Spurious renders found:
  ProductList — 6 spurious renders, 312.4ms wasted
    → props ref changed but no keys differed

This is the classic "missing React.memo" pattern. The component re-renders every time a parent renders, even though nothing it depends on changed.

`get_hottest_components`

Components ranked by total self time across all commits. Useful for finding where to optimize first.

`trace_render_cascade`

Given a commit index, shows what triggered it and what else re-rendered as a result:

Commit 3 — triggered by: SearchInput (hook changed)
Cascade:
  ProductList — re-rendered (unstable props)
  Sidebar — re-rendered (context changed)

This is how you find the root cause instead of just the symptom.

`suggest_memoization`

Combines spurious render detection with self-time data to generate specific recommendations:

Suggestions:
  ProductList → React.memo
    Reason: 6 spurious renders, 312.4ms wasted
    Self time: 52.1ms avg per render

⚡ Setup

{
  "mcpServers": {
    "react-render-profile": {
      "command": "npx",
      "args": ["-y", "react-render-profile-mcp"]
    }
  }
}

Then record a session in React DevTools → Profiler → export as JSON → give the file path to your agent.

🚀 The workflow

Instead of pasting raw JSON and hoping:

"Load the profile at /tmp/myapp.profile.json and find spurious renders"

The agent calls find_spurious_renders with the file path, gets back structured data with component names, counts, and wasted milliseconds — and gives you a concrete list of what to fix.

"Load the profile and trace what caused the slow commit at index 3"

trace_render_cascade returns the trigger component, the cascade, and the reason for each re-render.

The agent goes from "I see some fiber IDs with large durations" to "ProductList is re-rendering 6 times spuriously, wrapping it in React.memo would save 312ms."

📦 Links

npm: npmjs.com/package/react-render-profile-mcp
GitHub: github.com/vola-trebla/react-render-profile-mcp

npx react-render-profile-mcp

Your AI Agent Hallucinates Tailwind Classes. Here's the Fix

Albert Alov — Sat, 16 May 2026 19:38:01 +0000

Your AI agent is confidently writing Tailwind classes that don't exist in your project.

bg-primary-500? Your project uses bg-brand-primary.
p-18? Only valid if your spacing scale includes it.
tw-flex? Only if your config sets prefix: "tw-".

The agent doesn't know. It's working from training data — the default Tailwind docs, not your config.

The Epistemic Blindness

When an agent generates a React component, it has no idea:

Whether bg-brand-primary is a valid class in this project
What your custom spacing scale looks like (is p-18 valid here?)
Whether you're using a custom prefix like tw-
Which brand colors exist beyond the Tailwind defaults
Whether flex grid on the same element is a conflict

It guesses. Custom tokens = hallucinations. Every time.

The Fix: Give the Agent Your Actual Config

tailwind-context-resolver-mcp is an MCP server that loads your tailwind.config.ts/js and exposes its resolved design system as queryable tools.

Before writing a component, the agent can:

→ get_config_summary        understand the project's design system
→ resolve_theme_tokens      query what colors/spacing actually exist
→ validate_class_string     verify the className before committing it
→ detect_css_conflicts      catch flex+grid on the same element

Real output from validate_class_string:

{
  "valid_classes": ["bg-brand-primary", "text-white", "p-4", "hover:dark:bg-brand-secondary"],
  "invalid_classes": ["bg-fake-token"],
  "possibly_valid_classes": ["btn", "prose"],
  "warnings": ["Conflicting multiple layout models: flex, grid"]
}

How It Works

The server uses the same config loading strategy as the Tailwind CLI itself:

jiti loads your tailwind.config.ts at runtime — no ts-node setup needed
tailwindcss/resolveConfig merges your config with Tailwind defaults → full resolved theme
Token-based validation — checks that bg-brand-primary maps to an actual colors.brand.primary token — without running PostCSS or the full JIT pipeline

The class parser handles the full Tailwind syntax:

!hover:dark:bg-brand-primary/50 → strips !, hover:dark:, /50 before lookup
bg-[#ff0000] → arbitrary values are always valid
-mt-4 → negative prefix stripped, looks up spacing token 4
group-hover:text-white → multi-word variants handled correctly
Unknown classes when plugins are active → possibly_valid_classes (can't verify btn or prose without PostCSS)

Setup

Add to Claude Desktop / Cursor / any MCP client:

{
  "mcpServers": {
    "tailwind-context-resolver": {
      "command": "npx",
      "args": ["-y", "tailwind-context-resolver-mcp"]
    }
  }
}

Then pass your config path on each tool call:

config_path: "/absolute/path/to/tailwind.config.ts"

Tailwind v3 Only

v4 uses a CSS-based config format — the programmatic resolveConfig API doesn't apply. The server detects v4 and returns a clear error instead of silently failing.

Your Node.js App Is Slow. Your AI Agent Can't Help - Until Now

Albert Alov — Sat, 16 May 2026 19:05:16 +0000

You've been here before.

The API is dragging. P99 latency is climbing. Someone says "just profile it" — so you run node --cpu-prof and get a file like CPU.20260516.154355.cpuprofile.

You open it. It's 28MB of this:

{
  "nodes": [
    { "id": 1482, "callFrame": { "functionName": "processRequest", "scriptId": "94", "url": "file:///app/dist/server.js", "lineNumber": 847, "columnNumber": 12 }, "hitCount": 3241, "children": [1483, 1490, 1501] },
    { "id": 1483, "callFrame": { "functionName": "parseBody", "scriptId": "94", "url": "file:///app/dist/middleware.js", "lineNumber": 23, "columnNumber": 4 }, "hitCount": 0, "children": [1484] },
    ...
  ],
  "samples": [1482, 1483, 1482, 1490, 1501, 1482, 1483, ...],
  "timeDeltas": [0, 118, 97, 124, 89, 112, ...]
}

Thousands of nodes. Millions of samples. Raw memory addresses. Microsecond tick intervals.

You paste it into Claude. The context window collapses. It hallucinates an answer. You're back to square one.

That's the problem this MCP solves.

Why AI Agents Are Blind to CPU Profiles

A .cpuprofile isn't just "a big file." It's a specific format that requires real computation to be useful:

Exclusive time (self time) = how long a function ran on its own, without counting callees = hitCount × avg(timeDeltas)
Inclusive time = self time + all descendant inclusive times = requires a recursive DFS over the call tree
Hot path = which chain of callers led to the bottleneck = requires building a reverse parent map

An LLM can't do any of this. It can't execute algorithms. It can't traverse a tree across 50,000 nodes. Even if you somehow got the file into context, it would just pattern-match on function names and guess.

The agent needs a bridge — something that runs the math locally and hands back a 10-line summary.

Introducing `v8-cpu-profile-decoder-mcp`

An MCP server that decodes V8 CPU profiles into token-efficient bottleneck summaries for AI agents.

npx v8-cpu-profile-decoder-mcp

Three tools. Each one answers a specific question the agent would otherwise be blind to.

Tool 1: `extract_hottest_functions`

"Which function is burning the most CPU?"

{
  "profile_path": "/app/profiles/CPU.20260516.cpuprofile",
  "top_n": 5,
  "min_self_percent": 1.0
}

Response:

[
  {
    "rank": 1,
    "functionName": "hashPassword",
    "url": "file:///app/dist/auth/crypto.js",
    "lineNumber": 42,
    "selfTimeMs": 1842.5,
    "totalTimeMs": 1842.5,
    "selfPercent": 61.32,
    "hitCount": 3241
  },
  {
    "rank": 2,
    "functionName": "parseJsonBody",
    "url": "file:///app/dist/middleware/body.js",
    "lineNumber": 18,
    "selfTimeMs": 412.1,
    "selfPercent": 13.71,
    "hitCount": 724
  }
]

61% of all CPU time in one function. The agent now knows exactly where to look — without ever reading the raw profile.

V8 internals ((program), (garbage collector), (idle)) are filtered out by default. You get user code only.

Tool 2: `analyze_call_tree_path`

"What's calling my slow function, and how often?"

{
  "profile_path": "/app/profiles/CPU.20260516.cpuprofile",
  "function_name": "hashPassword",
  "top_callers": 3
}

Response:

{
  "targetFunction": "hashPassword",
  "matchedNodes": 2,
  "totalSelfTimeMs": 1842.5,
  "totalPercent": 61.32,
  "callers": [
    {
      "functionName": "loginHandler",
      "url": "file:///app/dist/routes/auth.js",
      "lineNumber": 94,
      "sampleCount": 2180,
      "attributedTimeMs": 1235.4
    },
    {
      "functionName": "validateSession",
      "url": "file:///app/dist/middleware/auth.js",
      "lineNumber": 31,
      "sampleCount": 1061,
      "attributedTimeMs": 607.1
    }
  ]
}

Now the agent knows the full picture: hashPassword is slow, loginHandler is responsible for 67% of those calls, and validateSession is calling it unnecessarily on every request.

Function name matching is partial and case-insensitive — you don't need to know the exact internal name.

Tool 3: `correlate_source_code`

"Which TypeScript file and line is the bottleneck actually from?"

After TypeScript compilation, your profile shows dist/auth/crypto.js:42. That's not where you write code. This tool reads the .js.map source maps and resolves back to the original TypeScript:

{
  "resolved": [
    {
      "rank": 1,
      "generatedUrl": "file:///app/dist/auth/crypto.js",
      "generatedLine": 42,
      "source": {
        "originalFile": "src/auth/crypto.ts",
        "originalLine": 38,
        "originalColumn": 2,
        "originalFunction": "hashPassword"
      },
      "selfTimeMs": 1842.5,
      "selfPercent": 61.32
    }
  ],
  "sourcemapErrors": []
}

The agent can now open src/auth/crypto.ts at line 38 and fix the actual source — not a compiled artifact.

Falls back gracefully to compiled JS locations if no .map file is found.

How the Algorithm Works

Three steps happen locally before anything reaches the agent:

1. Build the node map
Parse the nodes array into Map<id, node> for O(1) lookup.

2. Compute exclusive time

selfTimeMs = hitCount × avg(timeDeltas[1:])

Note: timeDeltas[0] is always 0 per V8 spec (offset from startTime), so we skip it.

3. Compute inclusive time via DFS with memoization

inclusiveTime(node) = selfTime(node) + Σ inclusiveTime(child)

Cached to avoid recomputation on shared subtrees.

The raw profile might have 50,000 nodes and 200,000 samples. What comes back to the agent is 10 ranked objects. That's the token compression that makes this useful.

Setup

npm install -g v8-cpu-profile-decoder-mcp

Claude Desktop (~/.config/claude/claude_desktop_config.json):

{
  "mcpServers": {
    "v8-cpu-profile-decoder-mcp": {
      "command": "npx",
      "args": ["-y", "v8-cpu-profile-decoder-mcp"]
    }
  }
}

Generate a profile:

node --cpu-prof --cpu-prof-dir ./profiles your-script.js
# or for a running server: kill -USR1 <pid> (with --cpu-prof flag)

Then ask your agent:

"Profile is at ./profiles/CPU.cpuprofile — find the bottleneck and suggest a fix"

What the Agent Can Do With This

With a decoded profile in context, an AI agent can:

Identify the hot function and read its source code
Trace who's calling it and how many times
Suggest memoization, caching, or algorithmic improvements
Spot unexpected callers (e.g., validateSession calling hashPassword on every request)
Generate a PR with the fix

Without this MCP, it's guessing from static code. With it, it's working from measured runtime data.

Your AI Agent Can Read the DOM. It Can't See the Screen.

Albert Alov — Sat, 16 May 2026 03:32:46 +0000

Here's a test that passes every time:

await expect(page.locator('.checkout-button')).toBeVisible();

And here's what the AI agent doesn't know: the checkout button is at y: 1450px on a 375px mobile viewport. It exists. It's visible according to the DOM. The test is green. The user can't reach it without scrolling three screens down, and on some devices a sticky cookie banner overlaps it by 60%.

The agent read the accessibility tree. It didn't see the screen.

The gap between the DOM and the render

When an AI agent analyzes a Playwright failure or writes a new test, it works with what Playwright exposes by default: roles, labels, text content, ARIA attributes. This is the right abstraction for functional testing.

But layout bugs don't live in the DOM. They live in the render engine's output — in coordinates, z-indexes, bounding boxes, and intersection ratios. A button can be display: block, visibility: visible, opacity: 1, and completely unreachable by a real user.

Current tools for this problem are either pixel-diff based (noisy, breaks on anti-aliasing) or proprietary enterprise AI (Applitools, Percy). There's no open-source tool that gives an AI agent structured geometric data from a live browser.

That's what playwright-spatial-layout-mcp does.

How it works

The MCP server launches a headless Chromium browser, navigates to a URL, and extracts geometric data using getBoundingClientRect() and getComputedStyle() in a single page.evaluate() call — one browser round-trip per element batch.

Four tools:

extract_bounding_boxes — returns position, size, z-index, and viewport visibility for any set of selectors.

{
  "url": "https://your-app.com/checkout",
  "selectors": [".checkout-button", ".cookie-banner", "nav"],
  "viewport": { "width": 375, "height": 812 }
}

[
  {
    "selector": ".checkout-button",
    "box": { "x": 16, "y": 892, "width": 343, "height": 48 },
    "z_index": "auto",
    "is_visible": true,
    "is_in_viewport": false
  }
]

The button exists. It is not in the viewport. The agent now knows this.

detect_visual_occlusion — computes the intersection ratio between two elements' bounding boxes.

{
  "url": "https://your-app.com/checkout",
  "target_selector": ".checkout-button",
  "overlay_selector": ".cookie-banner"
}

{
  "is_occluded": true,
  "intersection_ratio": 0.61,
  "occluded_area_px": 4128
}

61% of the button's area is under the cookie banner. The agent can now report this as a bug, not a passing test.

verify_spatial_relationships — validates layout rules and returns a pass/fail with a human-readable reason per rule.

Six rule types: left_of, right_of, above, below, contains, not_overlapping.

{
  "url": "https://your-app.com",
  "rules": [
    { "type": "above", "element_a": "nav", "element_b": ".hero" },
    { "type": "not_overlapping", "element_a": ".sidebar", "element_b": ".main-content" }
  ]
}

{
  "passed": false,
  "results": [
    { "passed": true,  "reason": "'nav' bottom (64px) is above '.hero' top (64px)" },
    { "passed": false, "reason": "'.sidebar' and '.main-content' overlap by 12%" }
  ]
}

This is layout spec-as-code — the agent asserts design constraints the same way it asserts functional ones.

compute_viewport_reflow — tracks how element geometry changes across breakpoints. All viewports are processed in parallel.

{
  "url": "https://your-app.com",
  "selectors": [".hero-cta", "nav"],
  "viewports": [
    { "width": 375, "height": 812 },
    { "width": 768, "height": 1024 },
    { "width": 1280, "height": 720 }
  ]
}

[
  {
    "selector": ".hero-cta",
    "shifted": true,
    "max_delta_x": 442,
    "max_delta_y": 318,
    "max_delta_width": 897
  }
]

The CTA moved 442px horizontally and 318px vertically between mobile and desktop. The agent knows which element is most volatile across breakpoints.

What the agent can do with this

Before this MCP, an AI agent writing or debugging Playwright tests operated blind to rendering. It could tell you the button has role="button" and aria-label="Checkout". It could not tell you where the button is on screen.

With spatial data in context, the agent can:

Detect that a passing test covers a button the user can't actually click
Identify which elements are off-screen on mobile before a test suite runs
Verify that a CSS refactor didn't break the layout without running visual regression diffs
Catch z-index wars where one component silently slides under another after a merge

The shift is from "does this element exist in the DOM" to "can a real user reach this element on this device."

Installation

npm install -g playwright-spatial-layout-mcp
npx playwright install chromium

Add to your Claude Desktop config:

{
  "mcpServers": {
    "playwright-spatial-layout-mcp": {
      "command": "npx",
      "args": ["-y", "playwright-spatial-layout-mcp"]
    }
  }
}

Then ask your agent:

"Check if the cookie banner is blocking the checkout button on a 375px viewport"

"Verify that nav is above the hero section and sidebar doesn't overlap main content"

"Which elements shift the most when resizing from desktop to mobile?"

Part of a larger ecosystem

This is the fifth MCP server in a series of open-source tools for the Playwright/TypeScript testing ecosystem:

playwright-trace-decoder-mcp — root-cause analysis from Playwright trace.zip files
flakiness-knowledge-graph-mcp — knowledge graph of flaky test patterns over time
ast-impact-mapper-mcp — TypeScript AST-based test impact analysis
zod-contract-mock-forge-mcp — deterministic mock generation from Zod schemas

Each one addresses a specific blind spot — what the agent can't reason about without structured tool access. Spatial layout was the most visible one.

npm: https://www.npmjs.com/package/playwright-spatial-layout-mcp

GitHub: https://github.com/vola-trebla/playwright-spatial-layout-mcp

Stop Copy-Pasting Zod Schemas to ChatGPT. Build a Mock Forge Instead.

Albert Alov — Sat, 16 May 2026 02:28:01 +0000

If you are using Zod for API contract validation in TypeScript, you already know the pain of writing test data.

You have a schema with 50 nested fields, UUIDs, enums, and email constraints. When it's time to write tests, what do you do? You copy the schema, paste it into Claude or ChatGPT, and ask: "Generate a valid JSON mock for this."

Then you need negative tests. So you ask: "Now generate 10 invalid payloads that break different constraints."

Then you need a Playwright test. "Now write a Playwright script that sends this payload."

It works, but it's tedious. You are acting as a human clipboard between your IDE and the AI.

What if the AI could just read your files, generate the mocks, and scaffold the tests on its own?

Enter the Model Context Protocol (MCP).

What is an MCP Server?

The Model Context Protocol allows AI agents (like Claude Desktop or Cursor) to interact with local tools and data sources. Instead of you pasting data to the AI, the AI fetches data from your environment using defined tools.

I built the zod-contract-mock-forge-mcp to solve the exact problem of API contract testing. It bridges the gap between your Zod schemas and your testing frameworks.

The "Mock Forge" Arsenal

When you connect this MCP server to Claude Desktop, the AI suddenly gains a powerful set of tools:

1. File Discovery (`read_schema_from_file`)

Instead of pasting code, you tell the AI: "Look at user.schema.ts."
The server automatically parses the file, extracts the specific Zod export, and feeds it to the AI. No manual copying.

2. Deterministic Mocking (`generate_valid_mock`)

Need test data? The server leverages @anatine/zod-mock and Faker.js to generate valid, realistic JSON payloads on the fly. You get actual UUIDs, formatted emails, and structurally perfect objects.

3. Deep Boundary Violations (`generate_boundary_violations`)

This is the killer feature for QA and SDETs.
Simple mock generators can give you valid data, but testing requires invalid data. The server performs recursive deep mutation on your schema. It will traverse deep nested objects and arrays to intentionally:

Omit required fields.
Inject type mismatches (e.g., sending a number instead of a string).
Break string constraints (invalid emails, bad UUIDs, wrong URLs).
Violate number and array boundaries (min/max).

The AI can generate a suite of 20 negative test cases in seconds, targeting specific edge cases you might not have thought of.

4. Test Scaffolding (`scaffold_api_contract_test`)

Once the mocks are ready, the AI can use this tool to generate the actual test boilerplate. It supports:

Playwright (for E2E API tests)
Jest / Vitest (for unit testing contracts)
MSW (Mock Service Worker, for frontend mocking)

5. The Smart Fixer (`suggest_contract_fix`)

Tests failing? Hand the failing payload and the schema to the suggest_contract_fix tool. It analyzes the Zod validation error and tells you exactly what went wrong:
"Issue: Expected string, received null at user.profile.avatar. Fix: Make the schema .nullable() or ensure the payload provides a string."

The Workflow in Action

Here is what it looks like when you use an AI agent equipped with the Zod Mock Forge:

You: "Read the CreateOrder schema from src/schemas/order.ts and write a Playwright negative test suite testing all boundary violations."

The AI (automatically):

Calls read_schema_from_file to get the Zod code.
Calls generate_boundary_violations to get 15 different ways to break the payload.
Calls scaffold_api_contract_test to get the Playwright boilerplate.
Writes out a complete order-negative.spec.ts file with 15 distinct test() blocks, each asserting the correct 400 Bad Request response.

Zero copy-pasting. Complete test coverage.

Stop being a clipboard

AI agents are meant to automate tasks, not just generate text. By equipping them with MCP servers like the Zod Contract Mock Forge, you turn a chat interface into a fully automated QA engineer.

Try it out on your own projects:
vola-trebla/zod-contract-mock-forge-mcp

Configure it in your Claude Desktop, point it at your .ts files, and watch it forge your tests.

Stop Spending Two Weeks Configuring Playwright. Use a Skeleton Built for AI Adaptation.🤖

Albert Alov — Sat, 16 May 2026 00:03:29 +0000

Every SDET joining a new project goes through the same ritual.

Run npm init playwright@latest. Spend day one on ESLint, Prettier, Husky. Day two on folder structure debates. Day three writing a Base API client. By the time you write a test that actually validates business logic, a week is gone.

Boilerplates exist to solve this — but they have a fundamental flaw: adapting one to your domain takes almost as long as starting from scratch. You're still hunting down every SamplePageObject and example-login.spec.ts and manually replacing them with your actual app's concepts.

What if the boilerplate came pre-wired for an AI agent to adapt it for you?

What is playwright-ai-skeleton?

It's a production-ready E2E framework built on Playwright and TypeScript, following patterns I've used across multiple real projects:

Page Object Model with strictly private locators — business intent exposed, Playwright internals hidden
Hybrid testing — API clients and UI Page Objects sharing the same Playwright fixture chain
API-first data setup — immutable data builders for fast, reliable state injection without UI
Zod validation — fails fast if .env or API responses don't match the expected schema
Worker-scoped auth — one login per worker instead of one per test, cutting CI time significantly
Pre-wired infrastructure — GitHub Actions, Docker Compose, and a Slack reporter included

But the architecture is not the point. The point is what's inside docs/.

The adaptation guide

The repo ships with two files designed not for human reading, but for AI input:

docs/CONVENTIONS.md — strict architectural rules the AI must follow
docs/ADAPTATION_GUIDE.md — a step-by-step prompt that drives the AI through customizing the skeleton for your specific domain

The entire onboarding flow looks like this:

git clone https://github.com/vola-trebla/playwright-ai-skeleton.git my-project
cd my-project
# Open in Cursor or Claude Code, then:
# "Read docs/ADAPTATION_GUIDE.md and adapt this for an e-commerce app called ShopFrog"

The AI reads the guide, understands the architecture's constraints, and starts a structured conversation:

What is your base URL?
What are your core domain entities?
How does authentication work?

After you answer, it renames files, generates your API clients, scaffolds your Page Objects, sets up Zod schemas, and writes your first smoke test — all consistent with the conventions in CONVENTIONS.md.

From git clone to a compiling, project-specific framework in under 10 minutes.

Why strict conventions matter for AI

AI coding assistants are fast but undirected — ask them to "write a Playwright framework" and you get a mix of outdated patterns, inconsistent selectors, and business logic leaking into locator files.

CONVENTIONS.md constrains the output:

Use getByRole — never raw CSS selectors
Expose login() — never click() on the Page Object surface
Data builders are immutable — no test mutates shared state

The AI doesn't just write code. It writes code that conforms to a specific architectural standard, enforced by the guide it was given.

Try it

git clone https://github.com/vola-trebla/playwright-ai-skeleton.git

Feed docs/ADAPTATION_GUIDE.md to Claude or Copilot. Answer the questions. Ship your first test today.

The infrastructure problem is solved. Your job is testing business logic — not configuring linters.

Stop Running Your Entire Test Suite. Use the AST Instead.

Albert Alov — Fri, 15 May 2026 23:16:54 +0000

You just changed one utility function. CI kicks off. 2,000 Playwright tests start running.

45 minutes later, you get your green light.

This is the state of E2E testing at scale: every PR pays the price of the full suite, regardless of what actually changed. It's not a tooling problem — it's an information problem. Your CI doesn't know which tests depend on your change. So it runs everything.

ast-impact-mapper-mcp fixes that.

🧠 The Idea: Import Graphs Don't Lie

Every TypeScript project is a directed graph of imports. When you change src/utils/auth.ts, the only tests that need to run are the ones that — directly or transitively — import it.

This isn't guesswork based on filenames or folder structure. It's a precise traversal of your actual dependency graph.

The tool uses ts-morph to parse your TypeScript project (including tsconfig.json, path aliases, JS/JSX files) and builds two graphs:

Forward graph: file → files it imports
Reverse graph: file → files that import it

Given a set of changed files, a BFS through the reverse graph finds every test that transitively depends on them. Everything else is safe to skip.

🛠️ Eight Tools for Complete Impact Analysis

Once connected to your AI assistant (Claude, Cursor), the MCP server exposes eight tools:

`get_affected_tests`

The core tool. Give it a list of changed files — or the raw output of git diff --name-only — and get back every test file that transitively imports them.

Supports TypeScript, JavaScript, and JSX. Matches *.spec.ts, *.test.ts, and files inside __tests__/ directories.

`get_affected_tests_by_branch`

Same as above, but the server runs git diff itself. Point it at a base branch (default: main) and it handles everything — no manual file listing needed.

`get_dependency_graph`

Direct imports and importers for any file. Returns JSON by default, or a Mermaid flowchart you can paste straight into GitHub markdown:

graph TD
  "src/fixtures/base-fixture.ts" --> "src/pages/google-home-page.ts"
  "src/fixtures/base-fixture.ts" --> "src/pages/google-results-page.ts"
  "tests/google-pom.spec.ts" --> "src/fixtures/base-fixture.ts"

`explain_impact`

Finds the shortest import chain from a test file to a changed source file. The AI can say exactly why a test is affected:

"checkout.spec.ts is affected because it imports CartPage.ts → PriceCalc.ts → the file you changed."

`get_coverage_gaps`

Finds source files that are not reachable from any test through the import graph — completely untested code, found statically in milliseconds, no coverage run needed.

`get_test_summary`

Project-wide health overview in one call: coverage rate, the 10 most-imported source files (highest blast radius if changed), and tests with the deepest import chains.

`refresh_project`

Clears the cached AST and dependency graphs for a project root. Call it after switching branches or pulling changes.

`get_dependency_graph` with `format: "mermaid"`

A visual flowchart of any file's import neighborhood — ready for GitHub, Notion, or any Mermaid renderer.

🕵️‍♂️ Real-World Scenario: The Targeted Refactor

You're refactoring DateHelper.ts. You want to run only the affected tests locally before pushing — not the full suite.

You ask your AI:

"I'm about to change src/utils/DateHelper.ts. Which tests should I run?"

The AI calls get_affected_tests:

"4 tests are affected: calendar.spec.ts, booking.spec.ts, history.spec.ts, and profile.spec.ts. Everything else is safe to skip."

You run those 4 tests in 2 minutes. CI confirms green 40 minutes later. That's the 20x feedback loop improvement — not from running tests faster, but from running fewer of them.

🔍 Real-World Scenario: The Unknown Risk

You're reviewing a PR that touches src/api/client.ts. You want to know the blast radius before merging.

You ask:

"How many tests depend on src/api/client.ts? Show me the dependency graph."

The AI calls get_test_summary, then get_dependency_graph:

"api/client.ts is imported by 11 other files and is the most-imported source file in the project. Changing it affects 23 test files — roughly 40% of your suite. I'd recommend reviewing this PR carefully."

That's information you couldn't get from a code diff alone.

📊 Example Output

Given this project structure:

src/
  fixtures/base-fixture.ts   ← imports home-page and results-page
  pages/google-home-page.ts
  pages/google-results-page.ts
tests/
  google-pom.spec.ts         ← imports base-fixture

get_affected_tests after changing google-home-page.ts:

{
  "changed_files": ["/my-project/src/pages/google-home-page.ts"],
  "affected_tests": ["/my-project/tests/google-pom.spec.ts"],
  "total_affected": 1
}

explain_impact — the exact import chain:

{
  "found": true,
  "import_chain": [
    "tests/google-pom.spec.ts",
    "src/fixtures/base-fixture.ts",
    "src/pages/google-home-page.ts"
  ]
}

🚀 The Complete AI-QA Pipeline

This is the third tool in a series designed to give AI agents full visibility into a Playwright test suite:

Trace Decoder — how did a test fail? Full network, DOM, and console analysis from the trace file.
Flakiness Knowledge Graph — is this test reliable? Historical failure rates, trends, browser-specific patterns.
AST Impact Mapper — which tests need to run? Precise impact analysis from the dependency graph.

Together, they cover the full lifecycle: knowing what to run, understanding if it's reliable, and diagnosing failures when they happen — all without opening a trace file or running the full suite.

⚡️ Setup

Install:

npm install -g ast-impact-mapper-mcp

Claude Code:

claude mcp add ast-impact-mapper ast-impact-mapper-mcp

Cursor / VS Code (.cursor/mcp.json):

{
  "mcpServers": {
    "ast-impact-mapper": {
      "command": "ast-impact-mapper-mcp"
    }
  }
}

Ask your AI:

My project is at /my-project. I just pushed a PR.

1. get_affected_tests_by_branch — which tests are affected vs main?
2. explain_impact for the top result — why is that test affected?
3. get_coverage_gaps — what source files have zero test coverage?
4. get_test_summary — what's the overall health of the suite?

Stop running everything. Start running what matters. 🧠🕸️🐸

DEV Community: Albert Alov

How react-render-profile-mcp works under the hood - and what it found in a real project

Act 1 — What it found on slash-admin

Diagnostics

Auto-remediation and the edge case

Act 2 — How it actually works inside

Layer 1: decoding the profiler format

Layer 2: the Invalidation Index

Layer 3: the AST remediation engine

Why no React runtime dependency

Setup

react-render-profile-mcp v0.3.1 - 4 new diagnostic tools for React Compiler, hydration, Zustand, and state cascades

What was already there (v0.1)

What's new in v0.3.1

1. analyze_compiler_efficacy

2. diagnose_hydration_and_suspense

3. evaluate_external_store_performance

4. trace_state_cascade_footprint

Updated: find_spurious_renders trigger classification

Recommended agent workflow (updated)

Setup (unchanged)

Your AI agent just read your .env file. You have no idea what it did next.

🙈 The three ways secrets leak

1. Hardcoded in source files

2. .env not in .gitignore

3. console.log that never got removed

🔧 How the scanner works

scan_for_secrets

check_gitignore_coverage

scan_for_log_leaks

🐸 The most ironic moment of this build

✅ Does it actually work?

⚡ Setup

🐸 The pattern

📦 Links

Your AI agent reads tsconfig.json. It has absolutely no idea what it means

🙈 What the agent actually sees

🔧 What the TypeScript compiler API actually knows

🛠️ Three tools

get_effective_compiler_options

resolve_module_alias

analyze_project_references

⚡ Setup

🐸 The pattern

📦 Links

Your CI Is Always Broken. Your AI Agent Has No Idea What to Do About It.

🧠 The three signals that actually matter

🛠️ The 4 tools

aggregate_suite_failures

cross_reference_flakiness

correlate_code_changes

generate_release_recommendation

🔗 It's a meta-orchestrator

⚡ Setup

📦 Links

Your AI Agent Just Broke Your React Performance. It Has No Idea

🤔 What the profiler actually exports

🛠️ The 5 tools

get_render_summary

find_spurious_renders

get_hottest_components

trace_render_cascade

suggest_memoization

⚡ Setup

🚀 The workflow

📦 Links

Your AI Agent Hallucinates Tailwind Classes. Here's the Fix

The Epistemic Blindness

The Fix: Give the Agent Your Actual Config

How It Works

Setup

Tailwind v3 Only

Links

Your Node.js App Is Slow. Your AI Agent Can't Help - Until Now

Why AI Agents Are Blind to CPU Profiles

Introducing v8-cpu-profile-decoder-mcp

Tool 1: extract_hottest_functions

Tool 2: analyze_call_tree_path

Tool 3: correlate_source_code

How the Algorithm Works

1. `analyze_compiler_efficacy`

2. `diagnose_hydration_and_suspense`

3. `evaluate_external_store_performance`

4. `trace_state_cascade_footprint`

Updated: `find_spurious_renders` trigger classification

2. `.env` not in `.gitignore`

3. `console.log` that never got removed

`scan_for_secrets`

`check_gitignore_coverage`

`scan_for_log_leaks`

`get_effective_compiler_options`

`resolve_module_alias`

`analyze_project_references`

`aggregate_suite_failures`

`cross_reference_flakiness`

`correlate_code_changes`

`generate_release_recommendation`

`get_render_summary`

`find_spurious_renders`

`get_hottest_components`

`trace_render_cascade`

`suggest_memoization`

Introducing `v8-cpu-profile-decoder-mcp`

Tool 1: `extract_hottest_functions`

Tool 2: `analyze_call_tree_path`

Tool 3: `correlate_source_code`

1. File Discovery (`read_schema_from_file`)

2. Deterministic Mocking (`generate_valid_mock`)

3. Deep Boundary Violations (`generate_boundary_violations`)

4. Test Scaffolding (`scaffold_api_contract_test`)

5. The Smart Fixer (`suggest_contract_fix`)

`get_affected_tests`

`get_affected_tests_by_branch`

`get_dependency_graph`

`explain_impact`

`get_coverage_gaps`

`get_test_summary`

`refresh_project`

`get_dependency_graph` with `format: "mermaid"`