Mert

As developers, we love automation tools and CLI wrappers. They save us time, abstract away complex configurations, and make our workflows smoother. But what happens when the tool designed to manage your configuration lies to you?

Recently, I encountered a fascinating edge case while managing API keys for my Claude Code environment using a third-party CLI helper (@z_ai/coding-helper).

This is a story about “split-brain” configurations, digging into node_modules to find the truth, and why you should never blindly trust a CLI’s success message.

The Ghostly “429 Plan Expired” Error

My setup involved using Claude Code powered by a specific API plan (GLM Coding Plan). After my initial API key expired, I renewed my subscription, got a new key, and ran the standard command provided by the CLI helper to reload my credentials:

chelper auth reload claude

I even ran the built-in health check (chelper doctor), and everything returned a perfect string of green checkmarks. Path? Valid. API Key & Network? Valid. Plan? Active.

However, the moment I tried to invoke a Model Context Protocol (MCP) tool—specifically, the web-reader tool—the agent instantly crashed with this error:

Error: MCP error -429: {"error":{"code":1309,"message":"Your GLM Coding Plan has expired, please renew to restore access."}}

Wait a minute. The health check passed, standard chats worked perfectly, but MCP tools were screaming that my account was expired.

The Investigation: Spot the Difference

Since the UI and the CLI tool were giving me conflicting information, I bypassed them and went straight to the underlying configuration files.

I checked the two places where credentials could theoretically be stored:

1. The CLI helper’s main config (~/.chelper/config.yaml): This contained my brand new, valid API key.
2. Claude Code’s MCP config (~/.claude.json): Looking at the mcpServers object, I checked the HTTP headers.

Boom. The Authorization: Bearer header for the MCP tools was still using the old, expired API key.

We had a “split-brain” scenario. The MCP tools were reading from a stale configuration file.

Root Cause Analysis: Diving into node_modules

Why didn’t chelper auth reload update the MCP config? To find out, I opened up the CLI’s source code located in node_modules/@z_ai/coding-helper/dist/lib/claude-code-manager.js.

I tracked down the exact function responsible for reloading the configuration:

loadGLMConfig(plan, apiKey) {
    // 1. Ensure onboarding is completed
    this.ensureOnboardingCompleted();

    // 2. Clean up shell environment variables
    this.cleanupShellEnvVars();

    // 3. Update ANTHROPIC_AUTH_TOKEN in settings.json
    this.saveSettings(glmConfig);
}

The flaw in the architecture was immediately obvious.

Claude Code actually splits its configuration into two distinct files:

• ~/.claude/settings.json (Used for standard Claude API calls)
• ~/.claude.json (Used to register MCP servers and their auth headers)

The developer of the CLI tool only programmed this.saveSettings() to update the standard API token. The tool completely ignored the MCP server configurations. As a result, any HTTP-based MCP tools registered previously were left stranded with expired credentials.

The Fix

If you are dealing with a similar misbehaving CLI wrapper, you can’t rely on its reload command. You have a few options:

Option 1: The Nuclear Option (Recommended)
Run the initialization command again from scratch. This usually forces the tool to overwrite all files completely.

npx @z_ai/coding-helper init

Option 2: The Python Automation Fix
If you have heavily customized your mcpServers and don’t want to reset everything, I wrote a quick Python script to automatically hunt down HTTP-based MCP tools in your config and update their headers securely:

import json
import os

config_path = os.path.expanduser('~/.claude.json')
new_key = "YOUR_NEW_VALID_API_KEY"

try:
    with open(config_path, 'r') as f:
        config = json.load(f)

    # Iterate through all configured MCP servers
    for mcp_name, mcp_config in config.get('mcpServers', {}).items():
        # Update only those that use HTTP headers for authentication
        if 'headers' in config.get('mcpServers', {}).get(mcp_name, {}):
            config['mcpServers'][mcp_name]['headers']['Authorization'] = f'Bearer {new_key}'
            print(f"Updated auth token for MCP tool: {mcp_name}")

    with open(config_path, 'w') as f:
        json.dump(config, f, indent=2)
    print("All MCP keys updated successfully!")

except FileNotFoundError:
    print("Error: ~/.claude.json configuration file not found.")

The SDET Takeaway

This is why Software Development Engineers in Test (SDETs) don’t just rely on UI green lights or standard CLI outputs.

When an automation tool tells you “Success!” but the system behaves as if it failed, there is almost always a state synchronization issue underneath. The abstraction layers designed to help us can quickly become blindspots.

The Golden Rule of Debugging Toolchains: When system behavior contradicts configuration state, stop trusting the management tools and start reading the raw .json and .yaml files.

Introduction: Python’s Popularity and the Need for Critical Evaluation

Python’s meteoric rise as the go-to language for data science, machine learning, and web development is undeniable. Its interpreted nature and dynamic typing make it accessible to beginners, as evidenced by my own journey from the syntactic hurdles of C++ and Java to Python’s intuitive design. However, this very accessibility masks mechanical trade-offs that become critical in performance-sensitive environments. Python’s interpreter executes code line-by-line, introducing overhead that compiled languages like C++ avoid by translating code directly into machine instructions. This overhead is negligible for small scripts but accumulates in CPU-bound tasks, where every cycle counts.

The language’s Global Interpreter Lock (GIL) further complicates its performance profile. The GIL is a mutex that prevents multiple native threads from executing Python bytecode simultaneously, even on multi-core systems. While it simplifies memory management by preventing race conditions, it serializes CPU-bound tasks, effectively neutralizing the benefits of parallel processing. This limitation becomes a breaking point in domains like financial modeling, where real-time calculations hinge on efficient core utilization.

Python’s dynamic typing, a boon for rapid prototyping, introduces runtime risks in large-scale projects. Without compile-time type checks, errors like mismatched data types or null references propagate undetected until execution. These errors are not merely inconveniences—they deform the reliability of systems, forcing developers to rely on extensive testing or third-party tools like mypy to mitigate risks. This trade-off between flexibility and safety is a causal chain that impacts Python’s suitability for mission-critical applications.

Despite these criticisms, Python’s ecosystem thrives through complementary tools that address its limitations. Cython and PyPy bridge the performance gap by compiling Python to C or using a just-in-time (JIT) compiler, respectively. Asynchronous programming frameworks like asyncio sidestep the GIL by enabling I/O-bound tasks to run concurrently. However, these solutions are not silver bullets. Cython requires rewriting Python code with static types, while PyPy’s compatibility issues limit its adoption. The optimal strategy depends on the use case: if performance is critical and the codebase is stable, use Cython; if compatibility is non-negotiable, stick to CPython with asyncio.

Python’s role in emerging fields like machine learning illustrates its evolving dichotomy. Libraries like TensorFlow and PyTorch prioritize developer productivity over raw performance, leveraging Python’s simplicity to abstract complex mathematical operations. Here, the language’s limitations are outweighed by its ability to accelerate innovation. Yet, in high-performance computing (HPC), where low-level control is paramount, Python’s abstractions break down, forcing integration with languages like Fortran or C++ for computationally intensive kernels.

In conclusion, Python’s popularity is both its strength and its Achilles’ heel. Its criticisms are not flaws but mechanical consequences of design choices that prioritize accessibility and productivity. To balance these trade-offs, developers must adopt a polyglot approach, leveraging Python for rapid development while offloading performance-critical tasks to more specialized languages. If scalability and performance are non-negotiable, avoid Python as the sole language; if prototyping speed is key, embrace it but plan for eventual integration with lower-level tools.

Common Criticisms of Python: A Developer’s Perspective

As someone who’s danced through the syntax of C++, wrestled with Java’s verbosity, and finally found solace in Python’s simplicity, I’ve often wondered why a language so beginner-friendly faces such sharp criticism from seasoned developers. Let’s dissect the six most common grievances against Python, grounding each in technical mechanisms and real-world implications.

1. Performance Limitations: The Interpreted Overhead

Python’s interpreted nature is both its strength and its Achilles’ heel. Unlike compiled languages like C++ or Java, Python code is executed line-by-line by the interpreter. This introduces a mechanical overhead: each line must be parsed, compiled to bytecode, and then executed. In CPU-bound tasks—think financial modeling or scientific simulations—this overhead accumulates, leading to performance bottlenecks. For instance, a nested loop in Python can run 10-100x slower than its C++ counterpart due to the repeated interpretation and dynamic type checking.

Mechanism: The interpreter’s step-by-step execution heats up the CPU with redundant context switching, while dynamic typing forces runtime checks that compiled languages resolve at compile time.

2. The Global Interpreter Lock (GIL): A Parallelism Killer

Python’s Global Interpreter Lock (GIL) is a mutex that serializes thread execution, preventing multiple native threads from running concurrently in CPU-bound tasks. This design choice simplifies memory management but neutralizes the benefits of multi-core processors. In a quad-core CPU, for example, Python threads will still execute sequentially, leaving 75% of the hardware idle. This makes Python ill-suited for tasks like real-time game physics or parallel data processing.

Mechanism: The GIL acts as a bottleneck, forcing threads to wait in line for CPU access, akin to a single-lane bridge in a four-lane highway.

3. Dynamic Typing: Flexibility at the Cost of Reliability

Python’s dynamic typing allows variables to change types on the fly, which is great for rapid prototyping but disastrous for large-scale projects. Type-related errors propagate undetected until runtime, where they manifest as crashes or incorrect results. For instance, a function expecting an integer might receive a string, causing a traceback deep in the call stack. This lack of compile-time checks increases the risk of bugs in complex systems.

Mechanism: Without static type enforcement, the interpreter cannot preemptively flag type mismatches, leaving the codebase vulnerable to runtime failures.

4. Dependency Management: A Double-Edged Sword

Python’s package ecosystem is vast but fragmented. While libraries like NumPy and Pandas are game-changers, managing dependencies across projects can be chaotic. Tools like pip and virtual environments help, but version conflicts remain a common pain point. For example, a project requiring TensorFlow 1.x and another needing 2.x can lead to dependency hell, where resolving incompatibilities becomes a full-time job.

Mechanism: The lack of a centralized dependency resolution system forces developers to manually reconcile conflicting library versions, often leading to broken builds.

5. Mobile and Game Development: Niche Limitations

Python’s interpreted nature and GIL make it a poor fit for mobile and game development, where low latency and high performance are non-negotiable. Mobile apps require efficient memory usage and fast execution, while games demand real-time rendering and physics calculations. Python’s abstractions, while developer-friendly, introduce latency that’s unacceptable in these domains. For instance, a Python-based game would struggle to maintain 60 FPS in a complex 3D environment.

Mechanism: The interpreter’s overhead and GIL’s serialization delay critical operations, causing frame drops and unresponsive UIs.

6. Advanced Features: A Steep Learning Curve

While Python is beginner-friendly, its advanced features—decorators, generators, metaclasses—have a steep learning curve. Misusing these can lead to unreadable or inefficient code. For example, overusing decorators can obscure control flow, while misconfigured metaclasses can break object inheritance. This duality makes Python accessible to novices but challenging to master.

Mechanism: Advanced features require a deep understanding of Python’s internals, and their misuse can introduce subtle bugs or performance penalties.

Mitigation Strategies: Balancing Trade-offs

• Performance-Critical Tasks: Use Cython to compile Python to C, improving performance by 10-100x. However, this requires static type annotations and is only effective for stable codebases.
• Concurrency: Leverage asyncio for I/O-bound tasks or offload CPU-bound tasks to multiprocessing, bypassing the GIL. However, multiprocessing increases memory overhead.
• Type Safety: Adopt mypy for static type checking, reducing runtime errors. But this adds development overhead and is optional, not enforced.

Professional Judgment: When to Use Python (and When Not To)

Python shines in rapid prototyping, data science, and web development, where developer productivity outweighs performance concerns. However, for performance-critical, real-time, or resource-constrained applications, consider a polyglot approach: use Python for high-level logic and offload bottlenecks to C++, Rust, or specialized libraries.

Rule of Thumb: If X (performance, scalability, or strict type safety) is critical, use Y (compiled languages or Python with mitigations). Otherwise, Python’s simplicity and ecosystem make it a strong contender.

In the end, Python’s criticisms are not flaws but design trade-offs. Understanding these trade-offs allows developers to wield Python effectively, avoiding its pitfalls while harnessing its strengths.

Comparative Analysis: Python vs. Other Languages

Python’s criticisms often stem from its design trade-offs, which become more pronounced in specific environments. To understand whether these issues are unique to Python, let’s compare them with other languages like C++, Java, and Rust, using the lens of its interpreted nature, dynamic typing, Global Interpreter Lock (GIL), and high-level abstractions.

1. Performance: Interpreted vs. Compiled Languages

Python’s interpreted nature introduces mechanical overhead: each line is parsed, compiled to bytecode, and executed sequentially. This process creates redundant context switching and runtime type checks, causing CPU-bound tasks to run 10-100x slower than compiled languages like C++. For example, nested loops in Python suffer from accumulated overhead, while C++ compiles directly to machine code, eliminating this bottleneck.

Comparative Insight: Java, though also interpreted at the JVM level, uses Just-In-Time (JIT) compilation, which optimizes frequently executed code, reducing overhead. Rust, a compiled language, offers zero-cost abstractions, making it comparable to C++ in performance. Python’s performance gap is thus a trade-off for its accessibility, not a universal flaw.

2. Dynamic Typing: Flexibility vs. Reliability

Python’s dynamic typing allows variables to change types at runtime, introducing type errors that go undetected until execution. In large-scale projects, this increases the risk of runtime crashes or incorrect results. For instance, a function expecting an integer might receive a string, causing a failure deep in the execution flow.

Comparative Insight: Java’s static typing catches type mismatches at compile time, reducing runtime risks. Rust goes further with its ownership model, enforcing memory safety and type correctness at compile time. Python’s flexibility is a strength for rapid prototyping but a weakness in reliability-critical domains. Tools like mypy mitigate this, but they add development overhead.

3. Global Interpreter Lock (GIL): Parallelism Killer

Python’s GIL is a mutex that serializes thread execution, preventing true parallel processing of CPU-bound tasks. This limits multi-core utilization—a quad-core CPU might have 75% idle cores during CPU-bound operations. The GIL exists to simplify memory management but neutralizes parallel processing benefits.

Comparative Insight: Java and C++ allow true multi-threading, leveraging all CPU cores. Rust’s fearless concurrency model avoids data races at compile time, enabling efficient parallelism. Python’s GIL is a unique limitation, making it unsuitable for CPU-bound, multi-threaded applications. Mitigation strategies like multiprocessing (spawning separate processes) bypass the GIL but increase memory overhead.

4. Ecosystem Fragmentation: Dependency Hell

Python’s vast but fragmented package ecosystem lacks centralized dependency resolution. Version conflicts (e.g., TensorFlow 1.x vs. 2.x) lead to dependency hell, where manual reconciliation is required to avoid broken builds. This fragmentation increases the risk of incompatible libraries coexisting in the same project.

Comparative Insight: Java’s Maven and Rust’s Cargo provide centralized dependency management, reducing version conflicts. Python’s pip and conda offer solutions but require careful management. This issue is not unique to Python but is exacerbated by its rapid ecosystem growth.

Professional Judgment: When to Use Python (and When Not To)

• Use Python for: Rapid prototyping, data science, web development (where productivity > performance).
• Avoid Python for: Performance-critical, real-time, or resource-constrained applications.
• Polyglot Approach: Use Python for high-level logic and offload bottlenecks to C++, Rust, or specialized libraries.

Rule for Choosing a Solution: If X (performance-critical, CPU-bound task) → use Y (C++, Rust, or Python with Cython/multiprocessing). If X (rapid prototyping, data analysis) → use Y (Python with its extensive libraries).

Key Insight: Python’s criticisms are not flaws but design trade-offs. Understanding these trade-offs enables effective use, balancing strengths and pitfalls.

Conclusion: Weighing the Pros and Cons of Python

Python’s meteoric rise in fields like data science, web development, and machine learning is undeniable, but its criticisms are equally grounded in technical realities. To make informed decisions, developers must dissect these critiques through the lens of system mechanisms, environmental constraints, and practical trade-offs.

Core Criticisms: Mechanisms and Implications

Python’s interpreted nature introduces mechanical overhead—each line is parsed, compiled to bytecode, and executed sequentially. This process, while enabling accessibility, creates a performance bottleneck in CPU-bound tasks. For instance, nested loops in financial modeling can run 10-100x slower than C++ due to redundant context switching and runtime type checks. Impact: Delayed calculations in real-time systems. Rule: For CPU-bound tasks, use Cython (static type annotations) or offload to C++.

The Global Interpreter Lock (GIL) acts as a mutex, serializing thread execution. This neutralizes multi-core benefits in parallel processing, leaving up to 75% of CPU cores idle in quad-core systems. Impact: Scalability issues in large web applications. Mitigation: Use multiprocessing (increased memory overhead) or asyncio for I/O-bound tasks. Rule: Avoid Python for real-time or parallel CPU-bound tasks.

Dynamic typing trades flexibility for reliability. Type errors propagate undetected until runtime, increasing crash risks in large-scale projects. Impact: Unreliable codebases. Mitigation: Adopt mypy for static type checking. Rule: Use Python for rapid prototyping; enforce type safety in critical systems.

Polyglot Approach: Balancing Strengths and Weaknesses

Python excels in productivity-focused domains like data science and web development, but its limitations necessitate a polyglot strategy. For performance-critical tasks, integrate Python with C++ or Rust. For example, in HPC, Python’s abstractions are paired with Fortran for computationally intensive tasks. Key Insight: Python’s criticisms are design trade-offs, not flaws. Understanding these enables strategic use.

Professional Judgment: When to Use (and Avoid) Python

• Use Python for: Rapid prototyping, data analysis, web development (where productivity > performance).
• Avoid Python for: Performance-critical, real-time, or resource-constrained applications.
• Rule: If X (performance-critical/CPU-bound), use Y (C++, Rust, or Python with Cython/multiprocessing).

Python’s criticisms are not dealbreakers but signals for informed decision-making. By understanding its mechanisms and trade-offs, developers can harness its strengths while mitigating weaknesses, ensuring its effective use in the right contexts.

Most portfolio templates come with React, Next.js, or at least a build step. I wanted something different: a template that designers can actually understand and modify without touching a terminal (beyond the initial setup).

So I built one from scratch. 300KB. Zero dependencies. Vanilla everything.

Why vanilla?

I’m a product designer who codes. My own portfolio (diyor.design) runs on plain HTML, CSS, and JavaScript. When I decided to turn it into a template, I had a choice: rewrite it in a framework, or keep it simple.

I kept it simple. Here’s why:

• Designers can read it. No JSX, no components, no state management. Just HTML files you can open in a browser.
• No build step. Edit a file, refresh the browser. Done.
• It’ll work in 10 years. No deprecated packages, no breaking updates, no npm audit warnings.
• 300KB total. The entire template. Not the JavaScript bundle — the whole thing.

What’s inside

• Bilingual support — Russian and English with a language switcher. Easy to adapt for any two languages.
• Dark mode — toggle button + automatic system preference, saved in localStorage.
• Case study template — numbered sections, stats grid, image lightbox with zoom, previous/next navigation.
• Terminal easter egg — press ~ for a secret terminal with design quotes.
• Design system overlay — press Shift+G to see the 12-column grid.
• One-command setup — ./setup.sh asks your name, generates a favicon, replaces all placeholders.
• SEO ready — Open Graph, JSON-LD, sitemap, canonical tags, hreflang.
• Accessible — ARIA, keyboard nav, focus-visible, reduced motion.

The setup experience

git clone https://github.com/diyoriko/portfolio-template.git my-portfolio
cd my-portfolio
./setup.sh

The script asks for your name, domain, email, socials. Then it:

• Replaces “Jane Smith” everywhere
• Generates an SVG favicon with your initial
• Updates CNAME, sitemap, config.json
• Done. Push to GitHub Pages.

What I’d do differently

The dark mode architecture. I started with just prefers-color-scheme but quickly realized users want a manual toggle. I ended up with a dual system: @media (prefers-color-scheme: dark) { :root:not(.light) { ... } } for auto mode, plus html.dark { ... } for manual. It works, but the CSS is duplicated. Next time I’d use CSS layers or a single class-based approach from the start.

Hardcoded colors. My first pass had rgba(0, 0, 0, 0.08) scattered everywhere for borders and shadows. In dark mode, they were invisible. I had to go back and replace them all with CSS custom properties. Lesson: use variables from day one, even for “obvious” values.

Try it

• Live demo — my actual portfolio, built with the same code
• GitHub repo — fork it, clone it, use the template button
• One-click deploy — GitHub template, ready to go

MIT licensed. If you build something with it, I’d love to see it.

I’m Diyor, a product and brand designer. I write about design systems, automation, and building things from scratch. diyor.design

📌 Core Idea

LFU (Least Frequently Used) means:

• Remove the least frequently used key
• If multiple keys have same frequency → remove least recently used (LRU)

📦 Data Structures Used

We maintain:

• key → node (for O(1) access)
• freq → doubly linked list (group nodes by frequency)
• minFreq (track minimum frequency in cache)

🧱 Structure Visualization

Freq = 1 → [ most recent …. least recent ]

Freq = 2 → [ most recent …. least recent ]

Freq = 3 → [ most recent …. least recent ]

Each frequency has its own LRU list

🚀 Example Walkthrough

Capacity = 2

Step 1: put(1,10)

Freq 1: [1]

minFreq = 1

Step 2: put(2,20)

Freq 1: 2, 1

minFreq = 1

Step 3: get(1)

• Access key 1
• Increase its frequency: 1 → 2

Freq 1: [2]

Freq 2: [1]

minFreq = 1

👉 We removed 1 from freq 1 and added to freq 2

Step 4: put(3,30)

Cache is FULL → eviction needed

• minFreq = 1
• Look at Freq 1 → [2]

👉 Remove 2

After insertion:

Freq 1: [3]

Freq 2: [1]

minFreq = 1

Step 5: get(3)

• Move 3 from freq 1 → freq 2

Freq 1: []

Freq 2: [3, 1]

minFreq = 2 (freq 1 is empty now)

Step 6: put(4,40)

Cache full → eviction

• minFreq = 2
• Freq 2 → [3, 1]

👉 Remove LRU → 1

After insertion:

Freq 1: [4]

Freq 2: [3]

minFreq = 1

🔥 Key Observations

1. Why multiple lists?

• Different frequencies → cannot maintain in single list
• Each frequency maintains its own LRU order

2. Why minFreq?

• Helps directly find which list to evict from in O(1)

3. Why doubly linked list?

• O(1) removal
• Maintain LRU order inside same frequency

🧠 Mental Model

Think of LFU like books:

• Shelf 1 → least used books
• Shelf 2 → moderately used
• Shelf 3 → most used

When removing:

1. Pick least used shelf
2. Remove oldest book from that shelf

🧩 Mapping to Code

🚨 Common Mistake

When a frequency list becomes empty:

if(freq == minFreq && list is empty)
    minFreq++;

❗ If you don’t update minFreq, eviction will break

Code

class LFUCache {
public:
    class Node {
    public:
        int key, val, freq;
        Node* prev;
        Node* next;

        Node(int k, int v) {
            key = k;
            val = v;
            freq = 1;
        }
    };

    class List {
    public:
        Node* head;
        Node* tail;
        int size;

        List() {
            head = new Node(-1, -1);
            tail = new Node(-1, -1);
            head->next = tail;
            tail->prev = head;
            size = 0;
        }

        void addFront(Node* node) {
            Node* temp = head->next;
            node->next = temp;
            node->prev = head;
            head->next = node;
            temp->prev = node;
            size++;
        }

        void removeNode(Node* node) {
            Node* prevv = node->prev;
            Node* nextt = node->next;
            prevv->next = nextt;
            nextt->prev = prevv;
            size--;
        }
    };

    int cap;
    int minFreq;

    unordered_map<int, Node*> keyNode;        // key -> node
    unordered_map<int, List*> freqList;       // freq -> DLL

    LFUCache(int capacity) {
        cap = capacity;
        minFreq = 0;
    }

    void updateFreq(Node* node) {
        int freq = node->freq;
        freqList[freq]->removeNode(node);

        if (freq == minFreq && freqList[freq]->size == 0) {
            minFreq++;
        }

        node->freq++;

        if (freqList.find(node->freq) == freqList.end()) {
            freqList[node->freq] = new List();
        }

        freqList[node->freq]->addFront(node);
    }

    int get(int key) {
        if (keyNode.find(key) == keyNode.end()) return -1;

        Node* node = keyNode[key];
        updateFreq(node);
        return node->val;
    }

    void put(int key, int value) {
        if (cap == 0) return;

        if (keyNode.find(key) != keyNode.end()) {
            Node* node = keyNode[key];
            node->val = value;
            updateFreq(node);
            return;
        }

        if (keyNode.size() == cap) {
            List* list = freqList[minFreq];
            Node* nodeToRemove = list->tail->prev;

            keyNode.erase(nodeToRemove->key);
            list->removeNode(nodeToRemove);
        }

        Node* newNode = new Node(key, value);
        minFreq = 1;

        if (freqList.find(1) == freqList.end()) {
            freqList[1] = new List();
        }

        freqList[1]->addFront(newNode);
        keyNode[key] = newNode;
    }
};

MCP (Model Context Protocol) is everywhere. Cursor, Claude Desktop, Windsurf, GitHub Copilot — they all use MCP servers to give AI agents access to tools.

But nobody is scanning these servers for vulnerabilities.

I pointed my scanner at 15 public MCP servers. Every single one failed at least 6 out of 10 OWASP checks. Most failed all 10.

What’s exposed

MCP servers expose tools — functions that AI agents can call. Think run_command, query_database, read_file, fetch_url. Most servers have:

• No authentication — any caller can invoke any tool
• No input validation — command injection, SQL injection, path traversal all work
• No message signing — requests can be replayed or tampered
• No rate limiting — flood the server, nobody notices
• Dangerous tools exposed — exec, shell, admin_panel sitting in the open

This isn’t theoretical. The OWASP MCP Security Cheat Sheet documents these risks. There’s an IETF draft proposing per-message signing to address them.

The OWASP MCP Top 10

I mapped the most common MCP vulnerabilities to the OWASP Top 10 2025:

Try it yourself

Cybersecify is a security scanner that runs these checks. Install it as an MCP server in Cursor or Claude Desktop:

{
  "mcpServers": {
    "security": {
      "command": "npx",
      "args": ["cybersecify"]
    }
  }
}

Then ask your AI:

• “Scan the MCP server at dvmcp.co.uk for vulnerabilities”
• “Is it safe to pip install litellm?”
• “Check if langchain-ai/langchain repo is safe”

Or scan our deliberately vulnerable MCP server at dvmcp.co.uk — it fails 10/10 checks on purpose. It’s a training lab.

What a scan looks like

Results: 0 passed, 10 failed (3 critical, 4 high)

[FAIL] MCP-01 Authentication Bypass (HIGH)
       No authentication required. Any caller can invoke tools.
[FAIL] MCP-04 Command Injection (CRITICAL)
       Shell command executed via tool arguments.
[FAIL] MCP-05 SSRF (HIGH)
       Internal/metadata URL accessible via MCP.
[FAIL] MCP-09 Tool Poisoning (HIGH)
       Prompt injection patterns in tool descriptions.
...

Community vs Pro

The Community Edition is free — 9 tools, OWASP MCP Top 10 scan, supply chain checks, threat intelligence.

Pro adds deeper scanning:

• OWASP Top 10 2025 active rules (6 checks with multiple test vectors)
• OWASP Top 10 2025 passive rules (4 checks)
• CIS MCP Benchmark (22 controls)
• EU AI Act compliance scan
• DAST mode with SARIF output for CI/CD
• Multi-target scanning and PDF/JSON/JUnit reports

More at cybersecify.co.uk.

The gap is real

97 million MCP SDK downloads. 13,000+ MCP servers. Zero security standard. The tools are being installed faster than anyone can audit them.

If you’re running MCP servers in production — or even in development — scan them. You’ll be surprised what’s exposed.

Raza Sharif, CyberSecAI Ltd

Modern security teams are not short on alerts. They are drowning in them.

Between vulnerability scanners, WAF logs, API gateways, and threat intel feeds, the problem is no longer visibility—it is prioritization. Everything looks like a risk. Everything demands attention. And as a result, nothing gets handled with the depth it actually requires.

This is especially true in API security, where the surface area is large, dynamic, and tightly coupled to business logic.

The core issue is simple:

Security teams are optimizing for coverage, not impact.

The Laundry List Problem

Most security workflows start with enumeration:

• Known CVEs
• Misconfigurations
• Suspicious traffic patterns
• Policy violations

This creates what can be described as a laundry list of possible threats.

The problem is not that these threats are invalid. The problem is that they are treated as equal.

They are not.

A vulnerability is only meaningful when placed in context:

• What system does it affect?
• What data does that system handle?
• What is the actual exploit path?
• What is the business impact if exploited?

Without this context, prioritization collapses.

Possible vs Probable vs Catastrophic

Not all risks belong in the same category. A useful distinction:

• Possible → Theoretical, low likelihood, limited impact
• Probable → Realistic exploitation path, moderate impact
• Catastrophic → High likelihood or high-impact business damage

Most organizations treat all three the same.

That leads directly to alert fatigue and wasted effort.

A Simple Example

• A vulnerability in a payment processing API
• A vulnerability in a breakroom refrigerator IoT device

Both are technically “security issues.”

Only one threatens revenue, compliance, and customer trust.

The other is operational noise.

Security that cannot distinguish between these two is not protecting the business—it is generating activity.

The Real Mission of Security

The goal of security is often misunderstood.

It is not:

• Blocking all malicious traffic
• Eliminating every vulnerability
• Achieving a “clean” environment

Those are impossible.

The real objective is:

Protect business-critical functions from meaningful disruption or compromise.

In API environments, this means focusing on:

• Authentication and authorization flows
• Data access boundaries
• Transaction integrity
• Abuse of core business logic

Everything else is secondary.

Response vs Remediation

Another failure mode is confusing response with resolution.

Response

• Blocking an IP
• Rate limiting a client
• Returning a 403

This is containment. It stops the immediate symptom.

Remediation

• Fixing the vulnerable endpoint
• Closing the logic flaw
• Updating authorization checks
• Redesigning unsafe workflows

This prevents recurrence.

If an attack reached the point where response is needed, the system has already failed at the design level.

Focusing only on response guarantees repetition.

Why API Security Makes This Worse

APIs amplify this problem because:

• They expose direct access to business logic
• They are designed for automation
• They often return structured, sensitive data
• They are reused across multiple services

Most importantly:

API attacks often use valid requests.

There is no malformed payload to block.

Examples:

• Enumerating user data through a search endpoint
• Pulling excessive records through pagination abuse
• Replaying tokens across endpoints

These are not attacks in a traditional sense. They are misuse of intended functionality.

Without context, they look normal.

The Fire Drill SOC

When context is missing, Security Operations Centers default to reactive mode:

• Alert comes in
• Analyst investigates
• Temporary mitigation applied
• Move to next alert

Repeat.

This creates a constant fire drill environment:

• No long-term fixes
• No prioritization
• No structural improvement

The system remains vulnerable while appearing active.

The Role of Contextual Visibility

To break this cycle, security teams need to attach context to every signal:

• Which API endpoint is involved?
• What business function does it serve?
• What data is exposed?
• Who is accessing it, and how?
• Is the behavior aligned with expected usage?

This turns raw alerts into actionable risk.

Without this layer, prioritization is guesswork.

Why Specialized SOC Models Work Better

General-purpose SOCs struggle because they operate horizontally across:

• Network traffic
• Endpoints
• Applications
• Identity systems

API security requires vertical depth.

Specialized models like MDR/XDR teams focused on specific protocol layers perform better because they:

• Understand API behavior patterns
• Recognize subtle abuse signals
• Correlate requests across sessions
• Focus on impact rather than volume

This reduces noise and increases accuracy.

Where WAF Fits (and Where It Doesn’t)

WAFs still play an important role:

• Blocking known attack patterns
• Filtering malformed requests
• Providing baseline protection

But they operate primarily at the syntax level.

They answer:

• Does this request look malicious?

They do not answer:

• Is this request being used to exploit business logic?

This strengthens request-level security.

However, the core limitation remains:

Context about business logic and usage patterns cannot be inferred from a single request alone.

Final Take

API security is not failing because of lack of tools. It is failing because of lack of prioritization.

The shift is clear:

• From counting vulnerabilities → to evaluating impact
• From reacting to alerts → to fixing root causes
• From blocking traffic → to protecting business logic

Context is what makes this shift possible.

Without it, every threat looks urgent.

With it, only the ones that matter get your attention.