DEV Community: Stephen Phillips

Tool soup is the first real MCP problem. A dynamic proxy is one way out

Stephen Phillips — Fri, 03 Jul 2026 12:36:28 +0000

MCP is useful because it gives agents hands.

That is also where the trouble starts.

A toy agent with three tools is easy to reason about. Search the web, read a file, write a note. Fine. A business agent is different. The moment you connect email, CRM, documents, analytics, Stripe, WordPress, calendars, spreadsheets and customer records, you no longer have an "AI assistant". You have a small operating system with a language model at the centre.

The current MCP conversation has a pattern: everyone gets excited about how many tools agents can reach, then a few days later they start asking why the agent chose the wrong one.

That is tool soup.

What MCP actually gives you

The official MCP tools spec says servers can expose tools that language models invoke. Those tools can query databases, call APIs or perform computations. Each tool has a name and schema so the client can discover it and call it in a structured way.

That is a big improvement over bespoke glue code. You do not want every agent framework to invent its own way to talk to Gmail, Postgres, Shopify or WordPress.

But discovery is not judgment. The fact that a model can see a tool does not mean it should see that tool for every task.

For a small business, this distinction matters. The owner does not care that the agent has 80 integrations. They care that the invoice went to the right customer, the refund was not issued twice, and the marketing email did not mention the wrong product.

The failure mode

Tool soup usually shows up in boring ways:

The agent spends too long deciding what to call.
It picks a broad tool when a narrow one would do.
It retrieves irrelevant context and pollutes the conversation.
It can technically update live systems, so every mistake feels expensive.
Debugging gets weird because the prompt, the tool schema and the external system all affect the outcome.

This is not a reason to avoid MCP. It is a reason to treat tool exposure as product design.

The official spec also says applications should make clear which tools are exposed, show when tools are invoked, and keep a human in the loop for operations. That is the right instinct. If an agent can change business state, the user needs a veto.

The wrong answer: give the agent everything

The lazy version of MCP is to connect every server at startup and hope the model figures it out.

That feels powerful in a demo. It is rough in a real workflow.

Tool schemas cost context. Similar tools compete with each other. A CRM search tool, a database query tool, a spreadsheet reader and a general browser tool may all look plausible for the same task. The model has to reason about the work and about the tool menu at the same time.

That is like asking a plumber to carry the entire workshop into every bathroom. More tools does not mean more focus.

A better mental model: a rotating tool belt

The better pattern is not "one agent sees every tool".

It is closer to a rotating tool belt.

The agent starts with a small set of proxy tools. It tells the proxy what it is working on: the tech stack, the project context, the task. The proxy activates the few MCP servers that match the job. When the task changes, the belt changes.

That is the idea behind Dynamic MCP Proxy, a HappyMonkeyAI project we have been using as a practical answer to tool soup.

The proxy keeps the initial surface small. The README describes a proxy_handshake({ tech_stack, task_description }) flow: the agent gives context, the matcher scores catalogue entries, the top servers are activated lazily, and a tool budget is enforced with LRU eviction.

In plain English: the agent does not carry the whole toolbox. It asks for the tools needed for the current job.

Why a proxy layer helps

A dynamic proxy does a few useful things at once.

First, it keeps the active tool count under control. DynamicMCPProxy is designed around a tool budget, with the README calling out a 50-tool limit for Google Antigravity-style environments. The exact number matters less than the principle: the model should not be staring at a giant menu when the task needs five tools.

Second, it makes tool loading contextual. A WordPress content task and a Docker deployment task should not expose the same tools. A support workflow should not need infrastructure tools. A finance workflow should not need image-generation tools.

Third, it lets private tools live in a catalogue. Public MCP servers can sit in catalogue.json; personal or company-specific servers can sit in a gitignored overlay. That is important for real businesses because their useful tools are often private: internal APIs, local scripts, CRM wrappers, document stores, reporting endpoints.

Fourth, it gives the agent a way to evolve its toolset during long jobs. If the task moves from planning to deployment, the proxy can activate different servers instead of forcing the first context window to carry every possible future tool.

A small business example

Imagine a local agency using agents for lead handling.

Without a proxy, the agent might start with access to:

Email
CRM
WordPress
Google Sheets
Analytics
Search
Calendar
Stripe
Filesystem
Internal notes
Social scheduling
Project management

That sounds impressive until the agent has to decide what to do with a single enquiry.

With a dynamic proxy, the first handshake might activate only:

Inbox reader
CRM lookup
Service notes
Draft reply writer
Follow-up task creator

That is enough. The agent can read the lead, identify the likely service, draft a reply, update the CRM with a summary, and wait for approval.

If the user then says, "turn this into a blog post too", the proxy can rotate the belt: WordPress drafts, keyword research, brand notes, image brief. The support tools can disappear.

That is a cleaner operating model.

Routing beats dumping

The production pattern is routing, not dumping.

A coordinator receives the user request. It decides which small capability set is relevant. Then the worker agent gets only those tools.

For example:

Content request: WordPress drafts, keyword research, image brief, internal brand docs.
Finance request: invoices, payment records, customer ledger, draft-only email.
Support request: inbox, orders, refund policy, draft response.
Reporting request: analytics, CRM exports, spreadsheet writer.

Each worker is simpler. Each approval boundary is clearer. The logs make more sense.

This also helps cost and latency. If you inject every available tool into every conversation, you burn context before the model has even understood the job.

Observability is not optional

The interesting trend is not just MCP itself. It is MCP plus routing, logging and observability.

Pydantic Logfire now has MCP server docs, which points in the right direction: agents should be able to inspect traces and failures instead of guessing. DynamicMCPProxy also exposes proxy health, active servers, usage counts and metrics. That kind of surface matters because dynamic tool loading should not be invisible magic.

You want to know:

Which servers were active?
Why were they selected?
Which tool did the agent call?
What arguments did it pass?
What came back?
Did the user approve the action?
What changed afterwards?

If you cannot answer those questions, you do not have automation. You have vibes with API keys.

The small business version

A small business does not need a giant autonomous agent. It needs a few dull workflows that save staff time without creating new mess.

Good first workflows:

Turn contact-form submissions into drafted replies.
Summarise sales calls and update CRM notes.
Pull weekly analytics and explain what changed.
Draft WordPress posts from approved research notes.
Check overdue invoices and draft polite reminders.

Bad first workflows:

Let the agent send emails without review.
Let it issue refunds before the policy is encoded.
Give it unrestricted filesystem and database access.
Connect every SaaS account because the demo looked good.

Start narrow. Keep approval visible. Log everything.

A practical checklist

Before adding an MCP tool or server to a business agent, ask:

Is this tool read-only or can it change state?
If it changes state, who approves the call?
Is there a narrower version of the tool?
Does the agent need this tool for this workflow, or is it just convenient?
Should this be always-on, or loaded only after a task handshake?
Can we replay the trace when something goes wrong?
Can we disable the tool quickly?
Does the user understand what the tool can touch?

Most agent failures are not dramatic. They are small mismatches between intent and tool access.

MCP makes business automation easier to build. It does not remove the need for boundaries. If anything, it makes boundaries more important, because the agent can finally do real work.

That is why the proxy pattern feels right to me. Not a giant agent with every tool under the sun, but a small coordinator with a rotating tool belt.

The agent should not carry the whole workshop. It should carry what the job needs.

Source notes used while drafting:

Dynamic MCP Proxy: https://github.com/HappyMonkeyAI/DynamicMCPProxy
MCP tools specification: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
Ollama API introduction: https://docs.ollama.com/api/introduction
n8n MCP server docs: https://docs.n8n.io/connect/connect-to-n8n-mcp-server
n8n MCP tools reference: https://docs.n8n.io/connect/connect-to-n8n-mcp-server/mcp-server-tools-reference
Pydantic Logfire MCP server guide: https://pydantic.dev/docs/logfire/guides/mcp-server/
X trend scans run 2026-07-03 for: MCP agents small business automation, local AI agents Ollama MCP, AI agent tool soup MCP workflow automation.

12 Simple Python AI Starter Projects for Beginners

Stephen Phillips — Fri, 03 Jul 2026 10:38:28 +0000

Starting your AI coding journey does not mean jumping straight into deep learning. Here is a curated list of approachable Python projects, ordered from easiest to slightly more involved. All use Python as the base, with libraries like scikit-learn, pandas, numpy, and optionally Streamlit for easy web UIs or OpenAI/Hugging Face APIs for modern LLM touches.

Most can start from free public datasets such as Kaggle datasets or scikit-learn built-ins.

Ultra-Beginner Projects

1. Iris Flower Classification

Classify flowers into three species based on measurements.

Why it is great: The classic “hello world” of machine learning. Small dataset, no cleaning needed.
Learn: Basic classification, train/test split, accuracy metrics.
Tech: scikit-learn, Decision Tree or KNN.
Next step: Try another small dataset such as handwritten digits.

2. Spam Email Classifier

Detect spam vs. real emails from text.

Why it is great: Practical, text-based, and easy to understand.
Learn: Text preprocessing, bag-of-words or TF-IDF, simple NLP.
Tech: scikit-learn plus CountVectorizer, optionally NLTK.
Extension: Test on your own email samples.

3. House Price Prediction

Predict prices from features like size, location, and number of rooms.

Why it is great: Intuitive real-world numbers.
Learn: Linear regression, tabular data, basic evaluation such as MSE.
Tech: pandas and scikit-learn.
Tip: Start with one or two features before adding more.

4. Sentiment Analysis on Movie Reviews

Classify reviews as positive, negative, or neutral.

Learn: Text vectorization and simple models on real text.
Tech: scikit-learn, or VADER as a rule-based starting point.

Easy Everyday AI-Enhanced Apps

5. AI-Powered To-Do List / Task Prioritizer

Build a basic to-do app, then let AI suggest priorities or due dates from task descriptions.

Why it is great: Starts from a familiar CRUD app and adds AI lightly.
Learn: Simple rules or LLM prompting for categorization and prioritization.
Tech: Python lists/dicts, Streamlit UI, optional OpenAI API.

6. Expense Tracker with AI Categorization

Log expenses and have AI guess categories such as food, transport, or subscriptions from descriptions.

Learn: Text classification, keyword matching, and gradual model upgrades.
Tech: pandas plus a basic classifier or LLM.

7. Basic Movie or Book Recommender

Suggest items based on simple user ratings or genres using content-based filtering.

Learn: Similarity measures and recommendation basics.
Tech: pandas and scikit-learn.

Next Steps Up

8. Student Performance Predictor

Predict final grades from inputs like study hours, attendance, and homework completion.

Learn: Feature importance and data visualization.
Tech: pandas, scikit-learn, matplotlib or seaborn.

9. Fake News or Clickbait Title Detector

Classify headlines or article snippets as real/fake or clickbait/not clickbait.

Learn: More NLP practice and model evaluation on imbalanced data.

10. Simple Chatbot: Rule-Based to LLM

Start with a rule-based FAQ bot, then connect it to a free or paid LLM API.

Learn: Prompt engineering basics and conversation flow.

11. Weather or Stock Trend Analyzer

Fetch data through an API and predict an up/down trend or simple forecast.

Learn: API usage and introductory time-series thinking.

12. Personal Text Summarizer or Email Responder Helper

Paste in text or an email and generate a short summary or suggested reply.

Learn: Working with generative AI, API integration, and prompt tuning.

Getting Started Tips

Environment: Use Google Colab for a no-install path, or local Jupyter Notebook with Anaconda.
Datasets: Search Kaggle for “beginner” or use built-ins like sklearn.datasets.load_iris.
Workflow: Load data → explore/clean → split train/test → train a simple model → evaluate → add a Streamlit UI → iterate.
Progression: Do one to three classic ML projects first, then add UIs and LLM features for fun.
Resources: FreeCodeCamp ML course, Kaggle Learn, and Microsoft’s AI curriculum are good structured starting points.

These projects stay simple, motivating, and portfolio-buildable while keeping you in the AI coding world. You will see results quickly without getting stuck on heavy computer vision, deep learning infrastructure, or massive datasets right away.