Three Fatal Flaws of AI Script Writing — and How MCP Services Fix Them

Why Does AI-Assisted Script Writing Always Disappoint?

Using AI to help write automation scripts is something almost every developer has tried. But when it comes to real-world implementation, you quickly discover three critical pain points: amnesia (no memory of previous work), blindness (inability to get accurate node/element information), and repeat mistakes (making the same errors over and over). These three fundamental flaws transform AI from an "efficiency tool" into a "source of endless rework."

Recently, a Bilibili creator shared a solution built on MCP (Model Context Protocol) services — a series of tool nodes written in Rust that address all three shortcomings in one go. This article breaks down the design philosophy and real-world results of that approach based on a complete hands-on walkthrough.

What is MCP? MCP (Model Context Protocol) is an open protocol standard released by Anthropic in late 2024, designed to standardize how large language models connect to external tools and data sources. Before MCP, every AI application required custom integration code for each tool, making maintenance extremely costly. MCP uses a unified client-server architecture that lets models call local or remote tools in a standardized way, dramatically reducing the complexity of integrating AI with external systems. Major AI products including Claude and Cursor already support MCP, and it is rapidly becoming a foundational infrastructure standard in the AI tooling ecosystem.

Why Rust? The author's choice of Rust for building MCP service tool nodes is deliberate. Rust is renowned for its memory safety and near-C execution performance, making it especially well-suited for background services and toolchains that need to run stably over long periods. In the AI Agent ecosystem, tool nodes frequently handle system-level operations such as file I/O, network requests, and process management. In these scenarios, Rust avoids Python's GIL lock and garbage collection pauses while offering finer-grained memory control than Go — making it an increasingly important technology choice at the AI infrastructure layer.

Flaw #1: Amnesia — History Nodes Give AI Long-Term Memory

A large model's context window is finite. Once a conversation grows long or spans multiple sessions, the AI "forgets" — losing track of prior development progress, problems encountered, and solutions that worked. This is especially crippling in long-cycle script development.

To understand the root cause: a model's context window refers to the maximum number of tokens it can process in a single inference pass. Even the most advanced models today — such as Claude 3.5 Sonnet (200K tokens) or GPT-4o (128K tokens) — still face context overflow challenges in extended development scenarios. More critically, cross-session state persistence cannot be solved simply by expanding the context window: every new conversation starts as a blank slate with complete amnesia. This fundamental architectural constraint is the core reason external memory storage mechanisms exist.

One of the MCP service's key capabilities is AI conversation history logging. In the demo, the author simply typed "check history" in the chat, and the AI automatically called the history query tool to review previous conversations. From the log output, you can see the AI invoke multiple tools to search through past records, successfully identifying and summarizing what was accomplished in previous sessions.

The core value here is extending AI memory from "single session" to "cross-session, project-level" continuity. Developers no longer need to re-explain context from scratch every time — the AI can pick up exactly where it left off, creating genuine development continuity.

Flaw #2: Blindness — Node Preprocessing and Analysis Tools Fill the Gap

The second pain point is that AI "can't see clearly." In automation script development, the AI needs to read UI element (node) information to write precise operation code. But raw node data is often enormous — and when faced with massive text, large models either skip over it lazily or blow out the context window entirely.

It's worth explaining what UI node data actually is: in mobile or desktop automation script development, UI nodes (also called the UI tree or Accessibility Tree) are XML/JSON data describing the hierarchical structure of interface elements. A typical app screen's node file can contain thousands or even tens of thousands of lines, packed with redundant fields like coordinates, dimensions, and resource IDs. Feeding raw node data directly to a large model not only rapidly consumes context budget, but also causes the model to misidentify element attributes due to excessive information noise. Common industry strategies include node pruning, summary extraction, and critical-path filtering.

To address this, the MCP service incorporates a node preprocessing mechanism. In the demo, the author asked the AI to "grab the nodes," and the AI proactively called the node capture tool, executed the capture via the QE program with parameters derived from the current project name, and stored the resulting node information in a cache directory.

Notably, when the author asked for a "detailed node analysis," the AI detected that the file was too large and proactively called the node analysis tool to extract key information via summarization. This dual mechanism of "preprocessing + summarization" ensures the AI gets accurate node data while preventing irrelevant information from flooding the context.

The author also acknowledged that this demo used the free MIMO model, which is slower and less capable than paid models — yet even so, the node tools enabled the AI to reliably complete capture and analysis. This demonstrates that well-designed toolchains can, to a meaningful degree, compensate for gaps in the model's own capabilities.

Flaw #3: Repeat Mistakes — An Error Library Lets AI Learn from Failure

The third — and most maddening — problem: AI keeps making the same mistakes. This showed up clearly during the code-writing portion of the demo.

The author gave the AI a simple requirement and asked it to output code. The first version predictably failed due to incorrect node information. The subsequent correction process was telling:

• The AI initially used the ID attribute, but the author knew that APPID attributes are unreliable in certain contexts and flagged it;
• The AI switched to the DS attribute, but the approach didn't conform to the official API specification;
• After another reminder, the AI consulted the knowledge base and output the correct official DS function;
• But then the AI overlooked the "attribute content is not fixed" issue — for example, like counts change with each piece of content;
• After yet another reminder, the AI finally produced correct regex-based node query code.

This process exposed a common AI weakness: not understanding the dynamic nature of real business logic. Large models learn static knowledge patterns during training, but in real-world scenarios, UI element attribute values often change dynamically with user data. This kind of "runtime uncertainty" is a blind spot that models cannot perceive through static reasoning alone.

The solution is the MCP service's error library feature. During development, the author had the AI log its learnings — storing errors and their solutions in the error library. The next time a similar issue arises, a quick query of the error database and history logs is enough to resolve it quickly, fundamentally breaking the cycle of repeated mistakes. In essence, this builds a "project-specific memory" for the AI, converting each debugging failure into a reusable, structured knowledge asset.

Full Walkthrough: From Color Picking to Like-Verification in a Complete Loop

Beyond the three core capabilities, the author also demonstrated a color picker tool as a complementary feature.

The workflow went like this: the author requested a screen capture, and after taking a screenshot, the AI asked whether to open the color picker tool. Once confirmed, the AI called the MCP-provided color picker tool, opened the image, and explained how to use it — left-click to pick a color, click copy, close the window, and the AI would then read the log to retrieve the result.

After picking the color, the AI moved on to writing color-detection code. The classic problem of "AI hallucinating API calls" appeared again here, but after several tool invocations, the AI eventually produced working code. During testing, there was also an incident where the AI forgot to request screenshot permissions — after a reminder and a knowledge base lookup, the AI corrected the code on its own.

Ultimately, the AI successfully located the color value and executed the click operation. The author then refined the execution logic: the correct flow should be "verify not yet liked → execute click → use color detection to confirm success." After the fix, the AI implemented a complete like-success verification feature — when an already-liked state is detected, the script automatically skips and avoids clicking again.

The log output showed "already liked, skipping," confirming that the script logic was entirely correct. The entire process formed a complete development loop: capture → analyze → code → test → verify → log experience.

Conclusion: An Engineered Toolchain Is the Real Competitive Edge in AI Programming

The value of this Rust-based MCP service suite lies not in any single impressive feature, but in the way it systematically repairs the structural deficiencies of AI-assisted script development:

• History nodes: Solve the amnesia problem, giving AI persistent cross-session memory;
• Node preprocessing and analysis tools: Solve the blindness problem, using summarization to balance information precision with context usage;
• Error library: Solve the repeat-mistake problem, letting AI accumulate reusable knowledge from every failure.

This solution is worth understanding in a broader industry context. Traditional RPA (Robotic Process Automation) relies on pre-recorded, fixed scripts that are brittle and lack adaptability — one interface change and the script breaks. Introducing AI Agents brings reasoning and decision-making capabilities, enabling dynamic generation of action strategies based on current interface states. The MCP toolchain described here is a prime example of these two paradigms converging: AI handles understanding and decision-making, while the engineered toolchain fills in memory, perception, and experience-accumulation capabilities — forming a hybrid "AI brain + RPA execution layer" architecture that represents the next stage of automation development.

Of course, the demo also exposed current AI limitations — understanding dynamic business logic still requires repeated human guidance, and free models have obvious capability ceilings. But through careful toolchain design, these shortcomings are effectively mitigated.

For engineers working on automation scripts, RPA, or AI Agent development, this approach of "using engineering discipline to compensate for model limitations" offers real practical value. The future competition in AI programming may not just be about which model is better — it may increasingly come down to context management and tool orchestration capabilities.