# Choosing Between MCP Agents and Scripted Automation with LLM Assistance

DevFeed: [Choosing Between MCP Agents and Scripted Automation with LLM Assistance](<https://devfeed.tech/articles/to-mcp-or-not-to-mcp-21738.md>)

Original publisher: [Read original article](<http://blog.pamelafox.org/2025/07/to-mcp-or-not-to-mcp.html>)

Author: Pamela Fox (noreply@blogger.com)

Published: 2025-07-21T14:43:00Z

Content type: opinion

Language: en

Sources: [Pamela Fox](<https://devfeed.tech/sources/pamela-fox.md>)

Topics: [Model Context Protocol](<https://devfeed.tech/topics/model-context-protocol.md>), [Large Language Model](<https://devfeed.tech/topics/llm.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [SDKs](<https://devfeed.tech/topics/sdks.md>), [Framework](<https://devfeed.tech/topics/framework.md>)

Tags: [apis](<https://devfeed.tech/tags/apis.md>), [automation](<https://devfeed.tech/tags/automation.md>), [automation-tools](<https://devfeed.tech/tags/automation-tools.md>), [cost](<https://devfeed.tech/tags/cost.md>), [energy](<https://devfeed.tech/tags/energy.md>), [frameworks](<https://devfeed.tech/tags/frameworks.md>), [llms](<https://devfeed.tech/tags/llms.md>), [mcp](<https://devfeed.tech/tags/mcp.md>), [sdks](<https://devfeed.tech/tags/sdks.md>)

## AI overview

The author compares MCP-based agents with scripted automation that uses APIs and SDKs alongside LLMs for selected decisions. They favor the scripted approach because it offers more control and potentially better accuracy, while requiring fewer tokens, lower cost, and less energy than MCP-powered workflows.

## Source excerpt

When we're building automation tools in 2025, I see two main approaches: Agent + MCP: Point an LLM-powered Agent at MCP servers, give the Agent a detailed description of the task, and let the Agent decide which tools to use to complete the task. For this approach, we can use an existing Agent from agentic frameworks like PydanticAI, OpenAI-Agents, Semantic Kernel, etc., and we can either use an existing MCP server or build a custom MCP server depending on what tools are necessary to complete the range of tasks. Old school with LLM sprinkles: This is the way we would build it before LLMs: directly script the actions that are needed to complete the task, using APIs and SDKs, and then bring in an LLM for fuzzy decision/analysis points, where we might previously use regular expressions or loving handcrafted if statements. There's a big obvious benefit to approach #1: we can theoretically give the agent any task that is possible with the tools at its disposal, and the agent can complete that task. So why do I keep writing my tools using approach #2?? Control: I am a bit of a control freak. I like knowing exactly what's going on in a system, figuring out where a bug is happening, and fixing it so that bug never happens again. The more that my tools rely on LLMs for control flow, the less control I have, and that gives me the heebie jeebies. What if the agent only succeeds in the task 90% of the time, as it goes down the wrong path 10% of the time? What if I can't get the agent to execute the task exactly the way I envisioned it? What if it makes a horrible mistake, and I am blamed for its incompetence? Accuracy: Very related to the last point -- the more LLM calls are added to a system, the harder it is to guarantee accuracy. The impossibility of high accuracy from multi-LLM workflows is discussed in detail in this blog post from an agent developer. Cost: The MCP-powered approach requires far more tokens, and thus more cost and more energy consumption, all things that I'd