Tell Alcy where to look. Let it build the tools.

Let the agent build the integration

Researchers call this tool-making: one model builds reusable functions that a model can call later. Recent work places maintained tool libraries within the broader idea of self-evolving agents. We apply that approach to retail websites.

The builder receives a website and a brief describing the capabilities we want. Pi, the harness we use for this work, explores the site, decides which operations are useful, writes their code and tries them. It saves the implementation, tool descriptions and checks in a versioned catalog.

MCP, the Model Context Protocol, gives another agent a standard interface for calling those tools. A grocery search can return structured product records, with evidence, while the saved code handles reading the site.

For ShopRite, Pi generated six reading tools: store lookup, aisle navigation, grocery search, category browsing, product details and shopping guidance. The integration reads public pages through a browser layer. It has no official ShopRite API or hosted public endpoint.

Groceries as a challenge

Alcy's core focus is fashion shopping across stores. After building working tools for apparel retailer SSENSE, we chose ShopRite to test how well the same approach transfers to another kind of shopping.

ShopRite gave us a large catalog of closely related products. Search results can differ by brand, flavor and package size, and produce may be sold by weight. The challenge was to match every item on a full grocery list, interpret the quantities and produce a consistent total. We compared the generated tools with ordinary browser use on that task.

A working tool needs a way to check itself

Every tool version carries checks that can be run against fresh site evidence. Our framework calls the real MCP tool, then looks for its declared field values in evidence captured through a separate path.

That path reads source HTML or a rendered browser without calling the generated extractor. Each checkpoint records what it found, which tool version it checked and whether the check passed, failed or remained inconclusive.

Give it a failure it can investigate

When a check fails or cannot establish that the tool works, Pi resumes with the saved catalog, available workspace and failure evidence. It investigates the site, repairs the implementation when warranted and checks the replacement. Each version keeps its evidence and history.

We tested the repair loop by injecting a code fault. A healthy tool failed its check, Pi repaired it, and the next checkpoint passed. That verifies the repair mechanism under a controlled failure. We are extending validation to real site drift and recurring checks; some broader ShopRite health checks remain unresolved.

The grocery-list results

We gave both methods the same 31 grocery lines and quantity notes. One used the saved ShopRite MCP; the other used normal browser tools. Both ran through Pi with GPT-6.1 Sol at medium reasoning, in fresh anonymous Hoboken pickup sessions. Historical product IDs and prices stayed hidden until evaluation. We ran four pairs.

Every run found the same 31 products, with matching advertised prices and quantity extensions, for an estimated $162.23. That estimate excludes taxes, fees, checkout adjustments and final weight differences. It does not establish current shelf stock.

Across these four pairs, the MCP used 85% fewer tokens and cost 61% less on average. It was faster in three pairs; the browser was faster in one. These are observations from this grocery list, rather than a prediction for every site.

Where the work overlapped

Independent MCP calls overlapped: we recorded eight or nine running at once. Across all four pairs, MCP research made 29 model requests, compared with 249 for browser research.

The browser could batch work too. In pair 2, its JavaScript grouped site requests into six batches and it finished sooner. The timeline shows each recorded pair on the same time scale.

Keep the evidence with the result

All eight runs completed the shopping task and saved their results. There were no model interruptions or errors during cleanup, and token and cost records were complete. The agents recovered from 17 tool errors along the way, including invalid product paths, failed source requests, browser wait timeouts and JavaScript syntax errors.

Our stricter measure required both agents in a pair to finish without any tool errors. All four pairs completed; none met that error-free measure. An earlier diagnostic run exposed harness issues that we fixed before this benchmark. It remains in the audit and is excluded from these results.

The browser used DOM and JavaScript observations and took no screenshots. Costs use recorded usage and configured rates. Elapsed time includes setup, research, settlement and cleanup; one-time tool generation and list preparation are excluded.

Build once. Keep checking.

We use generated MCPs to carry useful work forward. An agent investigates how a store works and saves that capability so later shopping research can use the tools. Independent checks give the next repair run fresh site evidence.

We are expanding website coverage, strengthening validation and adding recurring monitoring. Each site's supported operations remain explicit. Sign-in and payment require a trusted user handoff and explicit authority. The ShopRite work described here covers catalog research; cart and checkout remain unverified.

We want Alcy to find the right item wherever it is sold. Having agents build, check and repair website MCPs is part of how we make that search more useful.