DEV Community: Stephen Phillips

The night four MCP servers started acting like one system

Stephen Phillips — Sun, 19 Jul 2026 16:17:48 +0000

Last weekend I watched an agent workflow do something I had been waiting to see outside a demo.

Hermes needed to hand a detailed review to another coding agent, start a fairly heavy Codex job, avoid overloading the local server, and leave enough evidence for me to check what happened afterwards.

It did not call one giant "run the swarm" function. It used four small MCP services in sequence.

That was the interesting part.

The run

The project was an evidence-first book-writing system. Hermes had reviewed its claim and citation engine and found a list of engineering problems that needed a coding pass.

The trace looked roughly like this:

find the development agent
send the review to its durable mailbox
confirm that the message arrived
create a durable implementation task
request capacity for the Codex workload
start Codex after the lease is admitted
append working and completion events
verify the resulting code and tests

The resource request declared an estimated 2.2 GB of memory and CPU weight 45. Resource Sentinel admitted it under a time-limited lease. Hermes then launched Codex and recorded the process against the same durable task.

The task history later contained submitted, working and completed events, plus artifact references and verification notes. One completion event recorded 18 passing tests, clean lint modes, compile checks and an independent review.

The workflow was imperfect. More edge cases appeared later and reopened the work. That is a feature, not an embarrassment: durable state made it possible to preserve the real history instead of flattening everything into a cheerful "done" message.

Four MCP servers, four jobs

1. Agent Communication MCP

Agent Communication MCP owns agent identities, cards, durable messages, task records, lifecycle events and artifact references.

Hermes used it to find the development agent, deliver the review, verify the mailbox, create the implementation task and record progress.

The review therefore survived beyond one Slack message or model context window. Another agent could retrieve the same instructions later.

2. Resource Sentinel MCP

Resource Sentinel MCP handles local telemetry and admission control.

A workload supplies an estimated memory requirement, CPU priority and lease duration. The server admits it or queues it according to deterministic host policy. Expiring leases prevent abandoned jobs from holding capacity forever.

Resource Sentinel does not run arbitrary shell commands. It decides whether work may start. Hermes and the coding CLI still own execution.

That boundary matters. A resource monitor should not quietly become a remote command runner.

3. Agent Coordination MCP

Agent Coordination MCP is a narrow control plane for discovering installed CLI agents, inspecting file-based project boards and recording assignments.

The project files remain the source of truth. Codex and other CLIs keep their own sandbox and approval behaviour. The MCP layer records intent and ownership rather than pretending every coding agent has an identical lifecycle.

4. Launcher Project Registry

Launcher Project Registry maps project slugs to local paths, ports, URLs, technology stacks, MCP commands and project context.

Its role was smaller in this run, but still useful. It also exposed a real gap: the book project did not yet have a registry slug, so the task fell back to an absolute local path.

That is exactly the kind of weakness an operational trace should reveal.

Why separate servers worked better

The stack worked because no server tried to own the whole workflow.

Each one returned structured state that Hermes could use in the next decision:

agent = communication.find_agent("dev-agent")
message = communication.send_review(agent, findings)

slot = resources.request_execution_slot(
    workload="codex-review-fixes",
    estimated_memory_mb=2200,
    cpu_weight=45,
)

if slot.status == "admitted":
    task = communication.submit_task(agent, instructions)
    process = launch_codex(task)
    communication.append_event(task, "working", process.reference)

That snippet is illustrative rather than a copy of the actual implementation, but the contract shape is the point.

The orchestrator did not need hidden knowledge of every service. It read tool descriptions, called one bounded operation, inspected the result and chose the next tool.

This was not "agent swarm intelligence"

It is tempting to describe any multi-agent trace as spontaneous collaboration. I do not think that helps.

MCP did not make the coding output correct. The agents did not vote their way to truth. The reliable parts were ordinary engineering controls:

durable task and message IDs;
explicit state transitions;
expiring resource leases;
project-owned artifacts;
deterministic tests and lint gates;
independent review that could reopen the work.

The coding agent still needed supervision. A later review found flaws in backup retention and API validation in a related repository. Those findings were fixed, tested and pushed instead of being waved away because an earlier agent had declared success.

Design rules I would reuse

Keep each MCP server narrow

A mailbox server should not edit repositories. A resource server should not execute caller-supplied commands. A registry should resolve project context without becoming a secrets store.

Smaller contracts make failures easier to locate and permissions easier to reason about.

Make state durable before adding more agents

Adding a second model is easy. Preserving task ownership, evidence, artifacts and failure history is harder and more useful.

If a handoff only exists in chat history, it is not much of a handoff.

Treat host capacity as policy

Local agents share memory, CPU, databases and inference services. Starting every available CLI at once can make all of them slower or take down the services they need.

Admission control belongs in the orchestration path, before process launch.

Verification must be able to reverse "done"

A completion event is a claim. Tests, source checks and independent review decide whether that claim holds up.

The system should preserve a clean way to move from completed back to working when new evidence appears.

What comes next

The immediate work is practical:

register projects that still fall back to absolute paths;
make lease renewal and release visible beside task history;
improve recovery for interrupted processes and stale tasks;
put agent, task and resource state in one control-centre view;
keep tightening the policy around what an agent may call complete.

This stack is still early, and the coordination server is explicitly experimental. But it has now handled useful work on a real project with a trace that survived the agents involved.

That is a better milestone than another polished swarm demo.

The original case study, including sanitized screenshots, is on HappyMonkey.ai.

The four projects are open source:

GOSafe: location-based disaster risk intelligence for real places and dates

Stephen Phillips — Sat, 18 Jul 2026 12:13:40 +0000

GOSafe (live at gosafe.happymonkey.ai) is our prototype for location-based disaster risk intelligence. It combines current events, official forecasts, and carefully bounded AI interpretation to answer a practical question: what should I watch around this place during these dates?

Product boundary: the current UI is a prototype with illustrative signals. It is not a live warning service and must not replace official emergency guidance.

The wedge

People plan trips, events, and moves with weather tabs, news tabs, and half-remembered map apps. GOSafe’s first slice is a location/date risk checker covering severe weather, flooding, wildfire/smoke awareness, and seismic/tsunami context — framed as situational awareness, not prediction theatre.

What “bounded AI” means here

Prefer official forecasts and structured feeds where they exist
Use models to interpret and summarise evidence, not invent certainty
Refuse unreliable claims such as precise earthquake prediction
Keep the product honest about prototype vs operational warning systems

How it is built

GOSafe sits in the disaster-intelligence stack as a modern Next.js app with a clear documentation spine (CONTEXT, ADRs, plans, research). Infrastructure pieces include nginx vhosts for the public hostname and process management for the live prototype.

Why we are building in public

Disaster-adjacent products attract hype and liability. Publishing the prototype boundary early is part of the product: show the architecture, show the limits, and iterate with source-backed signals rather than fear marketing.

Live prototype: gosafe.happymonkey.ai

Theme: evidence-first risk awareness for travel and everyday planning.

Originally published on HappyMonkey.ai.

OpenUKPublicDataMCP: one MCP endpoint for useful UK public data

Stephen Phillips — Sat, 18 Jul 2026 12:13:03 +0000

Agents are only as good as the facts they can reach. OpenUKPublicDataMCP is a no-key-first Model Context Protocol server that gives Claude, Hermes, Cursor, and other MCP clients one reliable place to ask common UK public-data questions — with sources attached.

Why public data needs an MCP layer

UK public APIs are powerful and fragmented: postcodes, GOV.UK search, flood monitoring, ONS statistics, carbon intensity, planning applications, Parliament lookups, and more. Each has its own quirks, pagination, and auth story. Agents should not re-learn that glue in every chat session.

Design principles

No-key-first — core tools work without signup
Source-cited — every tool returns upstream source metadata and retrieval time
Official-first — prefer official UK public-sector APIs; label community sources explicitly
Thin adapters — normalise useful fields, keep upstream payloads available
Optional enrichments — Companies House, OS Places, Met Office, TfL only when keys exist
Read-only by default — no public-sector write operations

What shipped in the MVP

23+ MCP tools, a FastAPI explorer API, and a React map UI under web/. Example capabilities:

Postcode lookup, bank holidays, National Grid carbon intensity
GOV.UK search and data.gov.uk dataset search
Environment Agency flood warnings and areas
ONS datasets/observations and CPIH headline inflation
Planning applications, police street crime near a point
MP / constituency lookups via Parliament APIs
Optional: Met Office forecast, Companies House profile, OS Places, TfL line status

How we use it

Register the stdio MCP server with Hermes (or any MCP client). Agents can plan research, pull a cited answer, and save notes without inventing numbers. A public explorer host also exists for human browsing when the stack is deployed.

Sister project

The same pattern is expanding to the US via OpenUSPublicDataMCP — federal-first, no-key-first access to high-value public sources.

Repo: github.com/HappyMonkeyAI/OpenUKPublicDataMCP

Originally published on HappyMonkey.ai.

miso-tts-docker: local Miso TTS 8B on Windows, Docker Desktop, and RTX 50-series

Stephen Phillips — Sat, 18 Jul 2026 12:12:21 +0000

High-quality local speech is finally useful for agents and demos — if you can get the GPU stack to boot. miso-tts-docker is our unofficial Docker Compose pack for running Miso TTS 8B on NVIDIA GPUs, with a special focus on Windows, Docker Desktop, and RTX 50-series (Blackwell) cards.

Not affiliated with Miso Labs — we wrap upstream inference with GPU-ready containers, Hugging Face caching, and Windows-friendly launchers.

Why we packaged it

Raw research repos rarely survive first contact with Docker Desktop on Windows or brand-new GPU arch flags. Builders hit tokenizer gatekeeping, torchcodec gaps, cache churn, and “works on my Linux box” launch scripts. We wanted a clone-and-run path that still respects the upstream model.

What you get

Docker Compose with NVIDIA GPU passthrough
PyTorch 2.11 + CUDA 12.8 oriented at RTX 5090 / Blackwell (sm_120)
Full bfloat16 Miso path by default (~24 GB VRAM recommended)
Persistent Hugging Face cache volumes
Preflight checks for gated Llama 3.2 tokenizer access
soundfile audio I/O patch so PyTorch 2.11 does not depend on torchcodec
Windows .cmd launchers (no PowerShell execution-policy drama)
Web voice demo: Whisper STT, optional LLM replies, dual TTS backends
Fast mode via Pocket TTS on CPU for low-latency replies
HTTPS via Caddy for mic access from phones/tablets on the LAN

Two speeds of voice

Quality mode runs Miso 8B on GPU for the high-end voice. Fast mode runs Pocket TTS on CPU so demos stay snappy without monopolising VRAM. You can also run both and A/B engines in the web UI.

Honest requirements

≥24 GB VRAM recommended for quality mode
~40 GB disk for first-run downloads
Hugging Face token + accepted Llama 3.2-1B license for the gated tokenizer path

Why it fits HappyMonkey

Voice is becoming a first-class agent interface. Packaging local TTS well is the difference between a LinkedIn demo and something staff can actually use on a desk GPU without a research internship.

Repo: github.com/HappyMonkeyAI/miso-tts-docker

Originally published on HappyMonkey.ai.

Resource Sentinel MCP: stop local AI agents from melting the host

Stephen Phillips — Sat, 18 Jul 2026 12:12:17 +0000

When you run many coding agents, tests, and models on one machine, the failure mode is boring and expensive: OOM kills, thrashing disks, and mysterious hangs. Resource Sentinel MCP is our answer — telemetry plus lease-based admission control that agents can request before heavy work.

The agent host problem

LLM agents are great at starting work and terrible at knowing when the box is already full. Parallel pytest runs, Docker builds, and subagents stacked on a shared laptop or lab server will happily oversubscribe memory and CPU until everything is slow.

We wanted a control plane that is deterministic, not another model guessing mood from vibes.

What Resource Sentinel does

Observes the Linux host (psutil-based telemetry)
Lets workloads request an execution slot with estimated memory and CPU weight
Issues expiring leases (and queues when the host is full)
Persists tickets/leases in SQLite WAL
Exposes FastMCP tools for agents and a read-only HTTP projection for dashboards
Feeds Glitch-compatible telemetry so the “cyber pet” reacts to real host state

How agents use it

Typical pattern for a heavy local job:

Call request_execution_slot with a workload id, estimated MB, and CPU weight
If granted, heartbeating/extend the lease while work runs
Always release on completion so others can proceed

Hermes registers it as MCP server name resource_sentinel (same name under DynamicMCPProxy).

MCP:  http://127.0.0.1:8800/mcp
Health: http://127.0.0.1:8800/healthz
Glitch: http://127.0.0.1:8800/api/resource-state

Boundaries that keep it honest

Policy is pure and fail-closed on invalid requests
It does not execute caller-supplied shell commands
MVP does not enforce cgroups — admission is cooperative via leases
Dashboards consume factual telemetry rather than caller-selected “moods”

Why this is a product story, not just ops glue

Local multi-agent stacks only become practical when the host has a traffic light. Resource Sentinel is that traffic light — small, testable, and agent-native via MCP.

Repo: github.com/HappyMonkeyAI/Resource-Sentinel-MCP

Originally published on HappyMonkey.ai.

PromptOS: an AI-first Linux installer that never builds the same machine twice

Stephen Phillips — Sat, 18 Jul 2026 12:11:29 +0000

Most installers ship a fixed menu of packages. PromptOS is different: a minimal live bootstrap that asks high-level questions, talks to your LLM provider, and generates a hardware-aware installation blueprint on the fly.

The problem with static install media

Traditional distro ISOs are frozen in time. Drivers lag, desktop profiles age, and “recommended packages” become a one-size-fits-none compromise. Maintaining a full custom distro is worse: you inherit package churn, security patches, and endless edge cases.

PromptOS keeps the maintenance burden where it belongs — upstream package managers and the models that already track modern stacks — while the installer itself stays small and focused.

What we built

TUI wizard in Go + Bubble Tea for a static binary on a tiny live environment
Pluggable LLM client for OpenAI, Anthropic, Gemini, or local Ollama
Structured JSON blueprints validated before execution
Executor path for partitioning, chroot bootstrap (archinstall / debootstrap / pacstrap), and config drops
Closed-action install triage, bounded auto-heal, boot-time rescue, and explicit disk-wipe confirmation
CI that matters: GitHub Actions builds the real image and boots it in QEMU through GRUB into OpenRC

How the flow feels

Boot the minimal live image
Pick a provider and enter your key
Answer preference questions in a conversational wizard
The model scans hardware context and drafts a blueprint
The executor applies the plan; if boot fails, AI triage has a rescue path

What it is not

PromptOS is not a full distro, custom kernel, or package repository. It is an intelligent orchestrator. Optional “AI desktop profile” ideas stay later-phase design work; the present focus is a trustworthy installer spine and guest readiness verification.

Why it matters for builders

If you care about local-first AI desktops, self-healing recovery, and reproducible-but-personal machines, the interesting product is not another ISO flavour. It is a bootstrap that can reason about your hardware and intent without trapping you in forever-forked packages.

Repo: github.com/HappyMonkeyAI/prompt-os

Want more build-in-public notes? Follow the series on happymonkey.ai and the org at HappyMonkeyAI.

Originally published on HappyMonkey.ai.

You've Never Sent a Single Word to an AI. Here's What Actually Happens.

Stephen Phillips — Wed, 08 Jul 2026 11:39:39 +0000

You've never sent a single word to an AI.

Every time you hit send on ChatGPT, Claude, or Gemini, your words get shredded before the model ever sees them. The process is called tokenization. Once you understand it, you'll never think about AI the same way again.

What is a token?

A token is the actual unit your AI reads — not a word, not a sentence. Sometimes it's a whole word. Sometimes just a fragment.

"ChatGPT" is 2 tokens.
"Unbelievable" is 3 ("un", "believ", "able").
A single emoji can cost 3 tokens.

Rough rule: 1 token ≈ 4 characters ≈ 0.75 words.

This is what your message actually looks like to an AI. Not words. Colored chunks of subwords.

Why does this matter?

The model never sees language. It sees numbers. Every token gets converted into a vector — a list of hundreds of values that places it in mathematical space.

"King" and "Queen" sit close together in that space. "King" and "pizza" are far apart. The model understands meaning the same way a map understands geography — through distances, not definitions.

This is how AI understands the word "Queen". Not by reading it. By knowing where it sits relative to everything else.

The Strawberry Problem

Ask any LLM how many R's are in "strawberry." Most get it wrong.

Not because it's stupid — because it never sees the full word. It sees "straw" and "berry" as two separate tokens and tries to count letters inside chunks it can't see into.

This is the gap between what AI feels like and what it actually is.

"Straw" + "berry". Two tokens. This is why it can't count the R's.

What changed in 2026?

Tokens aren't just text anymore.

Every major model (GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro…) now handles a million tokens in a single conversation. Images cost tokens. Audio costs tokens. Video costs tokens. Your entire prompt — text, files, screenshots — becomes one long river of numbers the model processes simultaneously.

The one thing to remember

Your prompt is not a command. It's a statistical context — a sequence of numbers that nudges the model toward the most probable next output.

Better context = better predictions. That's the whole game.

How does the AI actually build its token vocabulary?

This is the part nobody explains and everyone should know.

The algorithm behind almost every major AI model (GPT, Claude, Llama, Mistral) is called Byte Pair Encoding, or BPE. It was originally invented in 1994 as a data compression algorithm. OpenAI repurposed it for AI in 2019.

Nobody designed it for language. It just happened to work extraordinarily well.

Here's how BPE actually works (in plain English):

Start with every single character in the alphabet. "h", "e", "l", "l", "o" — each is its own token.
Now scan through billions of words and find the two characters that appear next to each other most frequently. Merge them into a single token.
Repeat. Over and over. Thousands of times.

The result is a vocabulary of subword units — chunks that are bigger than single characters but smaller than full words — that perfectly balances handling rare words and common ones simultaneously.

By the end, your vocabulary might look like:

"ing" is one token (because it appears everywhere)
"un" is one token (prefix of thousands of words)
"2026" is one token (appears enough to earn its own slot)
"xylophone" gets split (rare enough that it never earned a merge)

The final vocabulary of most modern LLMs sits between 32,000 and 128,000 tokens. GPT-4o uses around 100,000.

Every prompt you send gets mapped into this fixed vocabulary and nothing outside it can exist.

This is how AI builds its vocabulary. Not by learning words. By learning which letter combinations appear together most often and merging them.

The hidden bias nobody talks about

Here's something that will make you genuinely uncomfortable.

The training data for most LLMs is heavily skewed toward English. Llama 2, for example, was trained on 89.7% English content.

This means the tokenizer learned English patterns extremely well and everything else poorly.

The result is a hidden inequality baked into every AI interaction:

Processing the same sentence in German or Italian costs about 50% more tokens than in English.
In languages like Burmese or Tibetan, the same text can cost up to 15 times more tokens than the equivalent in English.

Why does this matter?

Because tokens = cost. Tokens = speed. Tokens = how much of your context window gets used up.

If you're using AI in Hindi, Tamil, Arabic, or any non-English language, you are paying more, getting slower responses, and fitting less into each conversation.

Not because the AI is worse. Because the tokenizer was never built with your language in mind.

A developer described this perfectly: "My agent works great in French or English. But if a user asks in Darija, it crashes in quality and becomes unusable."

That's not a bug. That's tokenization.

This is one of the most underreported fairness issues in all of AI right now.

Tokens are no longer just text

This is where 2026 changes everything.

Tokens aren't just words anymore. Every major frontier model now processes images, audio, and video as tokens too.

An image tile costs tokens.
A second of audio costs tokens.
A video frame costs tokens.

What this means in practice:

When you send Claude a screenshot, it doesn't "see" it the way you do. It converts the image into a grid of tiles, encodes each tile into numerical vectors, and feeds those vectors into the same token stream as your text.

Your image. Your voice note. Your PDF. Your video. All of it — one long river of numbers. Processed the same way.

The model has no concept of "this is a picture" versus "this is a sentence." It's all just tokens in a sequence.

This is what people mean when they say AI is becoming truly multimodal. It's not that the model learned to see. It's that vision got tokenized.

Text. Image. Audio. Video. It all becomes the same thing before the model sees it.

Tokens.

What this means for how you use AI (starting today)

Understanding tokenization isn't just academic. It directly changes how you should prompt.

Front-load your important information

The model processes tokens left to right. The beginning of your prompt carries the most weight. Put your most critical instructions first — not buried in paragraph three.
Be concise — you're paying per token

Every word you type is tokens. Every word the model generates is tokens. Verbose prompts with filler phrases waste your context window and cost more on paid APIs. Trim everything that doesn't add meaning.
If you're coding, name things clearly

Code files often exceed the token limit of a single embedding and they have to be chunked. Variable names and function names become individual tokens. Clear, common naming patterns tokenize more efficiently than cryptic abbreviations. "getUserData" tokenizes better than "gtUsrDt."
Switch to English for complex reasoning tasks

This is uncomfortable but true. For tasks requiring deep multi-step reasoning, especially on smaller models, English prompts will outperform non-English prompts because the tokenizer was trained primarily on English. On frontier models this gap is shrinking. On smaller local models, it's still significant.
Don't trust AI with character-level tasks

Spelling backwards. Counting specific letters. Rhyming on a specific syllable. Anagrams. These all require character-level processing that tokenization makes structurally difficult. Use AI for meaning-level tasks. Use code for character-level tasks.

The future of tokenization

Tokenization is not a solved problem. It's actively being reinvented right now.

Researchers are exploring byte-level transformer models that process raw bytes instead of subword tokens entirely. This would mean no vocabulary, no BPE merges, no tokenization bias against non-English languages. Every byte is treated equally.

The tradeoff is sequence length. Bytes are much smaller than subwords, so the same text becomes a much longer sequence, which is expensive computationally.

Other researchers are working on multilingual tokenizers with "language plasticity" — the ability to adapt post-training to new languages without retraining the entire model from scratch.

The goal is simple: an AI that processes every language on earth with equal efficiency, equal cost, and equal quality.

We're not there yet. But tokenization is exactly where that battle is being fought.

Takeaway

Every time you type a message to an AI, a silent, high-speed assembly line starts moving.

Your words get shredded.

Assigned numbers.

Converted into vectors.

Fed into a model that has never read a single word in its life.

And somehow on the other side it answers like it understood everything.

That gap between what's actually happening and what it feels like is the most fascinating thing in technology right now.

Source: Adapted from the excellent thread by Shiny (@Oishaaniii) on X. Original post contains additional visuals and examples.

Stop letting AI agents click the expensive buttons

Stephen Phillips — Sun, 05 Jul 2026 11:04:58 +0000

A small business does not usually need a fully autonomous AI employee.

It needs something less glamorous and much more useful: an agent that can prepare the work, explain its reasoning, show the exact action it wants to take, and then stop before it does anything expensive, public, or hard to undo.

That sounds conservative until you watch an agent connected to real tools. Reading a calendar is harmless. Drafting a reply is useful. Sending that reply to a customer is different. Looking up an invoice is helpful. Issuing a refund, changing a price, publishing a blog post, deleting a record, or promising a delivery date is where the risk changes shape.

This is the line small teams should design around.

The current agent conversation is finally moving past "can it call tools?" and toward "which tools should it be allowed to call without a person?" MCP gives us a common way to expose tools and resources to AI clients. n8n and similar workflow tools give us the plumbing to pause, route, approve, and log decisions. The missing piece is a simple operating model a business owner can understand.

I use this one: let the agent drive the forklift, but keep a human hand on the keys to the warehouse door.

The approval gate is not a failure mode

Developers sometimes treat human approval as a sign that the automation is incomplete. For small businesses, it is often the feature that makes automation deployable.

An approval gate says:

the agent can do the boring research;
the agent can draft the action;
the agent can collect supporting evidence;
the agent can recommend a next step;
but the final irreversible step needs a human yes.

That is safer, and it is easier to sell internally: owners can trust the agent to prepare three clean options without handing it final authority on day one.

This is why n8n's human-in-the-loop tool-call pattern matters. Its docs describe an AI Agent that pauses when it wants to use a tool with human review enabled, then sends an approval request through a configured channel such as Slack, Telegram, or n8n Chat. That is the right mental model: the approval gate lives around specific tools, not around the whole workflow.

The agent should not need permission to summarize a support ticket. It probably should need permission to close it with a refund.

Sort tools by blast radius

Before connecting an agent to business systems, write down the tools it can call and sort them into four buckets.

1. Read-only tools

These fetch information but do not change anything.

Examples:

search the knowledge base;
read product inventory;
fetch appointment availability;
inspect order status;
retrieve recent invoices;
check website analytics.

These are usually safe to run automatically, assuming access control is correct and private data is handled properly. The main risk is information exposure, not operational damage.

2. Drafting tools

These create something that still needs another step before it affects the outside world.

Examples:

draft a customer email;
create an unpublished CMS post;
prepare an invoice but do not send it;
generate a quote;
fill a CRM note;
suggest a schedule change.

These can often run automatically too, because the output is parked somewhere for review. Drafting is where small businesses get a lot of value quickly. A human still owns the final action, but the blank page disappears.

3. Reversible write tools

These change state, but the change is low value, easy to undo, or visible only internally.

Examples:

tag a lead;
update a task status;
add an internal note;
move a ticket between queues;
create a calendar hold;
enrich a record with public data.

These deserve more thought. Some can be automatic after testing. Others should start with approval until the team sees a few weeks of behaviour. The important part is to know why a tool is allowed to write, what the rollback path is, and who gets notified when it does.

4. Expensive buttons

These are actions that spend money, make promises, expose content publicly, affect legal or financial records, or annoy customers if wrong.

Examples:

send an email or SMS to a customer;
publish a website or social post;
issue a refund;
change a live product price;
delete a customer record;
approve payroll;
submit a tax or compliance document;
place an order with a supplier.

These are the expensive buttons. Put approval gates here first.

MCP needs business permissions, not just technical auth

MCP authorization is important because MCP servers can expose sensitive resources and operations. The official docs focus on securing access to restricted servers and protected resources. That is necessary, but business safety needs one more layer.

A valid user token answers: "is this client allowed to access the server?"

A useful small-business policy also asks:

Is this tool read-only or write-capable?
Can this action be undone?
Is there a money limit?
Is there a customer-visible side effect?
Does this action require a manager, owner, or domain expert?
Should the same person who requested the action be allowed to approve it?

That policy does not have to be complicated. A simple YAML file or database table is enough for many teams:

tools:
  read_order:
    risk: read_only
    approval: never
  draft_refund_email:
    risk: draft
    approval: never
  issue_refund:
    risk: expensive_button
    approval: required
    max_without_owner: 25
  publish_wordpress_post:
    risk: public_action
    approval: required
    approvers: [owner, marketing]

The point is not the format. The point is that your agent runtime, MCP gateway, or workflow orchestrator should know the difference between "look this up" and "do this now."

What an approval request should include

A bad approval request says:

The AI wants to use issue_refund. Approve?

A good approval request gives the human enough context to make the decision in ten seconds:

requested action;
customer or record affected;
amount or business impact;
agent's reason;
evidence it used;
exact payload it will send;
rollback path;
timeout behaviour.

For example:

Refund £18.50 to Order #1842 because the courier marked the item lost and the customer has waited 9 days. Evidence: tracking link, customer message, policy section 4.2. If approved, the refund is sent via Stripe and a confirmation email is drafted. If rejected, the ticket stays open.

That is reviewable. The owner can approve, reject, or edit. The agent has still saved the time: it found the order, checked the policy, wrote the rationale, and assembled the payload.

Start with three gates

If you are adding agents to an existing business workflow, do not start with a giant governance programme. Start with three gates.

Public communication gate — anything that sends or publishes outside the company.
Money gate — refunds, invoices, discounts, purchases, payroll, subscriptions.
Record destruction gate — deletes, merges, irreversible CRM/accounting changes.

Everything else can be evaluated tool by tool.

This works especially well with n8n-style workflows. The agent can run the first 80% of the process, then pause at a human-in-the-loop node or approval-enabled tool. The approval can happen in the channel the business already uses. After approval, the workflow resumes and logs the result.

The practical architecture

A small-business agent stack does not need to be exotic:

MCP servers expose business tools: CRM, CMS, calendar, accounting, documents, email.
A gateway or policy layer tags tools by risk and enforces approval rules.
A workflow engine such as n8n handles routing, waiting, reminders, and notifications.
The agent prepares the action and evidence.
A human approves expensive buttons.
Every decision is logged.

You can make this more advanced later with dynamic tool routing, observability traces, local models, and audit dashboards. But the core pattern is simple: agents prepare; humans approve; workflows execute; logs remember.

Why this is good for adoption

Small businesses are not short of AI demos. They are short of trustworthy systems that fit into messy daily operations.

Approval gates make agents less magical and more usable. They give owners a way to start small without handing over the keys. They also produce training data: every approval, rejection, and edit teaches the team where the agent is reliable and where the policy needs tightening.

That is how automation becomes operational instead of performative.

Do not ask, "Can the agent do the whole job?"

Ask, "Which parts can it do safely, and where should it stop?"

That question is much easier to answer. It is also the question that turns AI agents from a risky experiment into something a small business can actually use.

Source notes

n8n docs: human-in-the-loop tool calls can pause an AI Agent before review-enabled tools and request approval through Slack, Telegram, or n8n Chat.
MCP docs: authorization protects access to sensitive resources and operations exposed by MCP servers.
X trend scan, July 2026: current small-business automation discussion is clustering around agents, MCP, workflow automation, and human oversight for high-stakes actions.

Sources:

Your AI agent needs receipts, not vibes: tracing MCP workflows for small businesses

Stephen Phillips — Sat, 04 Jul 2026 13:32:20 +0000

A small-business AI agent is easy to demo and surprisingly hard to trust.

The demo looks clean: connect the agent to email, invoices, a CRM, maybe a few n8n workflows, then ask it to chase unpaid invoices or triage customer messages. It calls the right tools. It writes a neat summary. Everyone nods.

Then Monday happens.

A customer asks why they got the wrong follow-up. The owner wants to know whether the agent actually checked the CRM before it emailed them. The developer opens a log file and finds a pile of model prompts, HTTP requests, half-useful timestamps, and no obvious story.

That is the line between an AI automation toy and an AI automation system: can you reconstruct what happened after the agent did something real?

For HappyMonkey-style small-business automation, this is becoming the next practical problem after "can the agent call tools?" MCP gives agents a standard way to connect to external systems. n8n and similar workflow tools give teams a place to run repeatable business processes. OpenTelemetry and agent observability patterns give you the missing receipts.

MCP gives the agent hands

The Model Context Protocol describes itself as an open standard for connecting AI applications to external systems: local files, databases, tools, search engines, workflows, prompts, and more. The docs use the USB-C metaphor, which is fair enough. The useful part is not the metaphor. It is the separation.

Instead of hardcoding every integration directly into an agent, you expose capabilities through MCP servers. The agent can discover a tool, call it with structured inputs, and get structured results back.

That matters for small businesses because their software stack is usually messy. The accountant lives in one system. Leads come from a website form. Bookings land in a calendar. The owner still forwards important emails manually. If every integration needs bespoke agent code, the project dies under maintenance.

MCP helps by making tool access more regular. But it does not magically make the work safe. Once an agent can touch real systems, you need to know what it touched, why it touched it, how long it took, what it cost, and what it returned.

Tool access without observability is just a more confident black box.

One practical pattern here is a dynamic MCP gateway rather than a static pile of MCP servers. We use DynamicMCPProxy locally for this: the IDE connects to one proxy, sends project/task context, and the proxy lazily activates the relevant MCP servers while keeping the active tool count under control. That solves the "tool soup" problem, but it also creates a useful control point for receipts: every server activation, tool call, latency, and outcome can pass through one place before it reaches the agent.

Workflows give the agent rails

This is where tools like n8n fit. n8n's own 2026 guide frames AI workflow automation as different from traditional app-to-app automation: the AI layer can interpret, decide, generate, and adapt as it runs, while the workflow layer still provides structure.

That split is useful. Let the agent decide which business action is needed, but put the actual action behind a workflow that has retries, validation, credentials, and predictable side effects.

For example:

lookup_customer_balance
send_payment_reminder_for_invoice
create_follow_up_task
summarize_new_leads_from_website
draft_wordpress_post_from_source_notes

Each of those can be an MCP-exposed tool or a workflow behind an MCP server. The agent chooses. The workflow executes.

But again, the question after a failure is not "did we use MCP?" It is "what exactly happened?"

If an invoice reminder went to the wrong person, you need a trace that answers boring questions quickly:

Which user request started this run?
Which model answered?
Which tools did it call?
What arguments did it pass?
Which workflow ran?
Did the workflow retry?
What did the external API return?
Did a human approve the final action?

The boring questions are the business-critical ones.

Traces are better than giant logs

A normal application log says, "this thing happened at this time." That is useful, but agent runs are nested. A single request might include planning, retrieval, model calls, tool calls, workflow calls, retries, and a final response.

A trace gives you the tree.

OpenTelemetry is already the common language for tracing normal distributed systems. Its GenAI semantic conventions now include concepts for model requests, token usage, and related AI operations. The OpenTelemetry docs list Gen AI semantic conventions alongside other standard instrumentation areas, and the ecosystem is moving toward treating model calls and agent steps as first-class spans rather than random log lines.

The CNCF has also been talking about Jaeger evolving for AI-agent traces with OpenTelemetry. That is a strong signal: agent observability is not just an LLM tooling niche. It is getting pulled into the same operational world as services, queues, databases, and APIs.

For small-business automation, you probably do not need a huge observability platform on day one. You do need the shape of the data to be right.

A practical trace might look like this:

customer_email_triage run
  model.plan
  mcp.tool.search_customer_by_email
  mcp.tool.get_recent_orders
  workflow.n8n.create_support_ticket
  model.draft_reply
  human.approval.requested
  email.send

Each span should carry just enough metadata:

span name: mcp.tool.get_recent_orders
customer_id: cust_123
workflow_run_id: n8n_456
latency_ms: 820
status: ok
records_returned: 3

Do not log private customer content by default. Log IDs, counts, status, latency, cost, tool names, model names, and approval state. Keep the sensitive payload somewhere controlled, if you need to keep it at all.

That one design choice matters. Small businesses often want local AI or self-hosted workflows because they care about privacy, cost, or control. Observability should not undo that by spraying customer emails into a third-party logging account.

The minimum viable agent receipt

If you are building this stack for a client, start smaller than you think.

For every agent run, save a receipt with:

Trigger: user message, cron job, webhook, or incoming email.
Decision: the short reason the agent chose a tool or workflow.
Tool calls: tool name, arguments with sensitive fields redacted, status, duration.
Workflow calls: workflow ID, run ID, status, retry count.
Model usage: model name, latency, token count or local runtime estimate.
Human gate: whether a human approved, edited, or blocked the action.
Outcome: what changed in the real world.

That receipt can be a JSON file at first. It can become OpenTelemetry spans when the system grows. The important thing is to design as if someone will ask, "why did the agent do that?" because someone will.

Here is a simple JSON shape:

{
  "run_id": "run_2026_07_04_001",
  "trigger": "inbound_customer_email",
  "agent": "support_triage_agent",
  "model": "local-llm-via-ollama",
  "tool_calls": [
    {
      "name": "mcp.tool.search_customer_by_email",
      "status": "ok",
      "duration_ms": 210,
      "redacted_args": { "email_hash": "..." }
    }
  ],
  "workflow_calls": [
    {
      "name": "n8n.create_support_ticket",
      "run_id": "n8n_456",
      "status": "ok"
    }
  ],
  "human_approval": "required_before_send",
  "outcome": "drafted_reply_and_created_ticket"
}

This is not glamorous. It is the stuff that keeps the owner from losing confidence the first time a workflow behaves oddly.

A concrete gateway example

In our own stack, this is the direction we have taken with DynamicMCPProxy. It started as a way to stop MCP "tool soup": connect the IDE to one proxy, let the proxy choose the right MCP servers for the current project, and keep the active tool list within a sensible budget.

The same gateway is also the right place to add receipts. The latest version records JSONL receipt events for handshakes, server activation, lazy materialisation, and child MCP tool calls. Those records include a run_id, span_id, event type, caller identity, status, latency, server name, runtime, and argument keys.

The important security detail is what it does not record. HMAC-authenticated sidecar calls are logged as a caller such as service:hmac, but the HMAC key itself is never written. Tool arguments are summarized as keys, types, lengths, and hashes rather than raw customer content. Optional OpenTelemetry export can mirror the trace shape later, but the local JSONL receipt still works without shipping sensitive payloads to an observability vendor.

That is the pattern I would use for most small-business agent systems: local receipts first, OpenTelemetry when the workflow has enough traffic or enough risk to justify distributed tracing.

What I would instrument first

If you are working with a small business, do not start by instrumenting every prompt token and edge case. Start with the places that create support pain or financial risk.

For an invoice workflow, trace customer lookup, invoice lookup, payment status, reminder generation, approval, and send.

For a lead workflow, trace source, deduplication, enrichment, CRM write, notification, and follow-up task creation.

For a WordPress/content workflow, trace source URLs, summarization, draft creation, image generation, human review, and publish state. Especially publish state. Nobody wants an agent accidentally publishing a draft because a boolean default was wrong.

For a local AI setup with Ollama, trace runtime and fallback behavior. If a local model fails and the system falls back to a cloud model, that should be visible. If a workflow silently switches models, your privacy story has a hole in it.

The sales angle is reliability, not magic

A lot of small-business AI pitches still sound like magic: "we will automate your operations with agents." Owners have heard enough of that.

A better pitch is more concrete:

"We will automate one repetitive workflow. You will be able to see every tool the agent used, every workflow it triggered, whether a human approved it, and what changed. If something goes wrong, we can replay the receipt."

That is less flashy, but it is more believable.

MCP makes the integrations less brittle. Workflow tools make the actions repeatable. Observability makes the whole thing accountable.

That combination is the difference between a clever prototype and a service you can charge for every month.

Source notes

Model Context Protocol documentation: MCP is an open-source standard for connecting AI applications to external systems such as data sources, tools, and workflows. https://modelcontextprotocol.io/docs/getting-started/intro
OpenTelemetry GenAI semantic conventions: OpenTelemetry maintains GenAI conventions alongside standard tracing conventions, including GenAI spans and MCP-related areas in the semantic convention registry. https://opentelemetry.io/docs/specs/semconv/gen-ai/
CNCF / Jaeger: Jaeger is evolving to trace AI agents with OpenTelemetry. https://www.cncf.io/blog/2026/05/26/how-jaeger-is-evolving-to-trace-ai-agents-with-opentelemetry/
n8n: AI workflow automation combines AI decision/generation with standardized workflows, with tools like n8n positioned for flexible automation. https://blog.n8n.io/best-ai-workflow-automation-tools/
DynamicMCPProxy: a dynamic MCP gateway that now includes security-first JSONL receipts and optional OpenTelemetry export. https://github.com/HappyMonkeyAI/DynamicMCPProxy
Social trend signal: X search on 2026-07-04 showed live discussion around MCP, n8n, Ollama, and tool routing for practical small-business automation.

Local AI agents for small businesses: where Ollama and MCP actually fit

Stephen Phillips — Fri, 03 Jul 2026 14:04:58 +0000

Local AI is having another moment because the use case finally makes sense.

A small business does not always need the smartest model in the world. It often needs a private assistant that can read the right files, draft the right response and avoid sending customer data to five different cloud services.

That is where Ollama plus MCP becomes interesting.

Ollama gives you a local model endpoint. The Ollama API docs show the default local base URL as http://localhost:11434/api, with endpoints such as /api/generate. MCP gives the agent a standard way to reach tools, resources and prompts around that model.

The combination is not magic. It is just a sensible architecture.

The basic shape

A local-first business agent stack looks like this:

Ollama runs the model.
MCP servers expose business tools.
A thin agent decides what to read or draft.
Human approval gates anything risky.
Logs record what happened.

For many businesses, that is enough.

You can run it on a spare machine, a Mac mini, a local server, or a small GPU box. The exact hardware depends on the model size and workload, but the point is control. Your customer emails, internal notes and messy spreadsheets can stay on your network.

What should stay local

Not every AI task needs to be local. Some jobs are harmless enough to send to a hosted model. But local is worth considering when the data is sensitive, repetitive or close to day-to-day operations.

Good local candidates:

Customer support triage.
Internal knowledge-base search.
First drafts of replies and proposals.
Summaries of call transcripts.
Invoice and receipt categorisation.
Staff process documentation.
Website content drafts from approved notes.

The model does not need to be perfect. It needs to be useful inside a bounded workflow.

A local model that drafts a reply for review can save time today. A local model that autonomously emails customers needs much more work.

Why MCP matters here

A local model by itself is just text in, text out.

MCP changes the shape of the problem. The official MCP tools spec describes tools that a model can discover and invoke, backed by schemas. Those tools can query databases, call APIs or run computations.

That means your local model can become part of a workflow without every integration becoming custom glue.

For example, a local support agent could have:

A read-only inbox search tool.
A customer lookup tool.
A policy document resource.
A draft reply writer.
A ticket note updater.

That is already useful. The agent reads the customer message, checks the policy, drafts a reply and records a summary. A person still approves the final email.

The privacy advantage is real, but not automatic

Running the model locally helps, but it does not make the whole system private by default.

If your MCP tools call cloud APIs, data still leaves the machine. If your logs capture full customer records and sync to a third-party observability service, data still leaves. If the agent can call a web search tool with private context in the query, data still leaks.

Local-first architecture needs boring rules:

Separate local tools from cloud tools.
Mark tools as read-only or write-capable.
Redact sensitive fields in logs.
Keep customer data out of prompts when it is not needed.
Use draft actions before send actions.
Keep approval on anything external-facing.

The model location is only one part of the privacy story.

A first workflow: local proposal assistant

Imagine a small web agency.

Every new lead asks roughly the same questions: price, timeline, whether WordPress is okay, whether SEO is included, whether the agency can migrate old content.

A local proposal assistant could:

Read the contact-form submission.
Search internal service notes.
Pull a few approved case-study snippets.
Draft a reply.
Draft a proposal outline.
Save both for review.

The agent does not need the ability to send the email. It does not need access to payroll. It does not need all files on disk.

It needs a small set of tools and a clear output.

That is the part people miss when they get excited about local agents. The win is not "my laptop has a CEO now". The win is that a boring admin task becomes 70 percent done before you touch it.

Where hosted models still fit

A local setup can also route harder tasks to hosted models.

For example:

Use Ollama for triage, classification and drafts with sensitive data.
Use a hosted model for public research where no private data is included.
Use a stronger hosted model for final editing after removing customer details.

This hybrid approach is often better than ideological purity. Keep sensitive context local. Use stronger cloud models when the input is safe and the quality gain matters.

The MVP stack

For a small business, I would start with this:

Ollama for a local model endpoint.
A filesystem or document MCP server limited to one folder.
An email or CRM MCP server in read-only mode where possible.
A draft writer tool that saves markdown, not sends messages.
A simple approval step.
A log file with tool calls and outcomes.

Then pick one workflow.

Do not start by connecting every system. Start with the task the business already hates doing every week.

The honest limitation

Local models still make mistakes. They may misunderstand instructions, miss details, or produce confident but wrong drafts. Smaller models can be especially brittle with long context or complex tool use.

That is why local agents work best when the workflow is narrow and the failure mode is cheap.

A bad draft is fine. A bad payment action is not.

Local AI plus MCP is not a replacement for business process design. It is a cheaper, more private way to automate the parts of the process that were already clear.

That is a good thing. Most businesses do not need science fiction. They need the inbox to be less awful on Monday morning.

Source notes used while drafting:

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.

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.