Before MCP, the loop was fixed and lossy. You filtered in someone’s UI, exported a CSV, uploaded it somewhere, and wrote a prompt over whichever columns you happened to include. Every step threw away context, and the model never got to ask a second question. It could summarise your export beautifully and had no idea what was outside it.
With a Model Context Protocol server, the model holds the tools. It asks, reads the answer, and asks a better question. That iterative narrowing is exactly what a good analyst does and precisely what a spreadsheet cannot do. The shift is not that AI got smarter; it is that the data stopped being a snapshot and became something the model can interrogate.
The tool surface, and why its shape matters
A complete prospecting surface needs about six tools: count matching stores, search them, fetch one store in full, fetch its catalog, fetch its trend history, and check remaining quota. That is it. Small tool surfaces are a feature, not a compromise — models choose badly when presented with forty overlapping options, and every extra tool is another chance to call the wrong one on step nine of a long chain.
The quota tool is the underrated one. Give the agent an explicit budget in its brief — you have two hundred calls this session, check remaining quota before entering any loop, stop and report if you drop below twenty — and it starts behaving like an employee with a company card rather than one with your bank details. Agents do not naturally economise. They will happily paginate through everything you allow.
Because these tools sit on the same REST surface as everything else, whatever the agent discovers is portable. A conversation produces a filter, the filter becomes a saved query, the saved query becomes a scheduled workflow. That path from exploration to production is the whole point, and it breaks the moment your agent and your pipeline read different data.
Wiring it up takes about four minutes
In a terminal-based coding agent, it is one command adding an HTTP MCP server with your API key as a header. In a desktop client or an editor, it is a few lines of JSON in the config file naming the server URL and the same header. In a workflow engine, it is an MCP Client node pointed at the same address. In all of them the tool list is discovered automatically, so you never hardcode a tool name and nothing breaks when tools are added.
Test with a question whose answer you already know. Ask how many WooCommerce stores are in the database. If it comes back with 58,549 you have a working connection. If it hedges, rounds, or produces a plausible number with no tool call visible, your key or your transport is wrong and everything downstream is fiction. Verify against a known number before you trust an unknown one — this takes ten seconds and saves entire afternoons.
Give the agent somewhere to write things down
A chat session is not a system. Close the window and the agent forgets which segments it explored, which counts it found, which domains it already surfaced. Two days later it re-discovers the same two hundred Shopify stores and presents them to you with the same enthusiasm. Memory is not a nice-to-have here; it is the difference between an assistant and a demo.
The minimum viable memory is two files or two tables. A segments log: the filter expressed in fields, the count it returned, the date, and your verdict on whether it was worth pursuing. A contacted log: domain, date, campaign, outcome. The first stops rediscovery. The second stops you writing to the same merchant twice. Both can live behind another MCP server — a database, a notes tool, a filesystem — or simply in a project file the agent reads at the start of every session and appends to at the end.
Write the reading and appending into the brief as a hard step, not a suggestion. Agents skip housekeeping when it is optional, because nothing in their objective rewards it. Make it step one and step last, phrased as an instruction rather than a preference.
The five-field agent brief
Every agent worth keeping can be described in five short fields. Mission: one sentence on what it is responsible for. Inputs: what it receives and from whom. Outputs: what it produces, in what format, and where it puts it. Guardrails: what it must never do without asking. Sources of truth: which tools and fields it is allowed to treat as fact. One paragraph each, and if you cannot fill a field the agent is not well defined enough to build yet.
For a research agent that becomes: mission, produce a scored shortlist of stores matching a brief. Inputs, a segment description in plain language plus a call budget. Outputs, a table of domains with a score, three evidence lines each naming its field, and a segment label from a closed list. Guardrails, never contact anyone, never exceed the budget, stop and ask if the count is zero or above a ceiling. Sources of truth, the store record, the catalog, the trend and the Google block.
The field everyone skips is sources of truth, and it is the one that decides whether the output is usable. Name what the agent may treat as fact and state plainly what does not exist in your stack. In our case that explicitly includes advertising data of any kind — there is none, anywhere in the system. An agent told what it does not have will say so. An agent left to fill the gap will write a fluent paragraph about a store’s ad strategy that is entirely invented, and you will not notice until a prospect does.
Three guardrails that carry most of the weight
Count before you search. Counting is cheap and searching is not, and a filter that matches eleven stores or four hundred thousand is a filter you want to fix before it consumes anything. Instruct the agent to report the count first, adjust exactly one criterion if it is out of range, and report what it changed. One criterion at a time is the same discipline that governs testing outreach copy: change two things and you learn nothing from the result.
Cite the field behind every claim. Every factual statement about a store must be followed by the name of the field it came from, and if the field is empty the statement is omitted rather than inferred. This makes hallucination structurally visible: a fabricated claim has no field to point at. It is the cheapest quality control in the entire stack and it takes one sentence in a system prompt.
Keep a human between draft and send. Not out of caution but out of self-interest: the person reading the queue is your fastest signal on whether the segment, the offer and the copy are right. An agent that sends autonomously removes the only feedback loop that was actually teaching you something.
A small team beats one large agent
One agent doing research, scoring, writing and quality control will do all four adequately and none of them well, because the instructions for each pull in different directions. Split it: an orchestrator that owns the objective and delegates, a researcher that only queries and shortlists, a writer that only turns one record into one draft, and a reviewer that only judges. Each gets its own five-field brief and its own narrow tool access.
The reviewer is the one almost nobody builds and everybody needs. Its only job is to read another agent’s output against the source record and answer three questions: is every claim traceable to a field, is any required element missing, does the tone match the brief. Its verdict is pass, revise or reject — with a reason. Crucially, it does not fix anything. A reviewer allowed to rewrite will flatten everything into the same average voice within a week.
Keep an inactive template brief that you clone whenever you add an agent. It sounds bureaucratic for a team of four, and it is the only thing that prevents the slow drift where each agent accumulates its own private conventions and nothing composes any more. Copy, edit the five fields, activate.
Where it still breaks
Long loops exhaust context and the failure is silent. An agent forty tool calls into a session will start summarising instead of reading, and you will not see the moment it stopped being precise. Counter it by asking for aggregates instead of rows wherever possible — distributions by platform, counts by country, medians by band — and by capping how many full records enter a single session.
Models are also optimistic about their own coverage. After one page of results an agent will happily announce it found all the stores matching your criteria. Force the honest version into the brief: report the total count, then the number of records actually reviewed, then the conclusion. Those three numbers side by side make overclaiming impossible, and you will be surprised how often the gap between the first two is enormous.
None of this makes the agent autonomous, and it should not. What it produces is a shortlist with evidence attached, assembled in minutes from data you could not have read manually, ready for a human to accept or throw out. That is not a smaller ambition than full automation. It is the version that survives a client asking where a claim came from.