← Back to webSlinger

What an agent sees when it loads webSlinger over MCP

The short version: connect the webSlinger MCP server to an agent and it does not get a navigate tool, a click tool, or a "here's a page, figure it out" tool. It gets a catalog of named functions - one per task a human already recorded and proved against the live site - each with a typed input shape and a structured output shape. The agent picks a function, fills in its arguments, and gets back clean JSON. No selectors in its context, no DOM to re-parse, no vision tokens spent locating a price. This post shows exactly what that catalog looks like from the agent's side of the wire, using real output, and why the shape of it is the whole pitch for anyone building agents against the web.

Everything below is real. It was captured by pointing an actual MCP client - a Claude-based agent with the webSlinger server loaded - at a live script library and letting it make the two read-only discovery calls any agent makes before it runs anything: list_scripts (what tools exist) and describe_script (the exact contract of one tool). Nothing is mocked or hand-written.

What the agent sees first: list_scripts

An agent's first move against a new tool server is to ask what's available. Over MCP, webSlinger answers that with list_scripts, and the response is a catalog of recorded automations - nineteen of them in the library used here - each already shaped like a typed function: a name, a description, the run-time inputs it accepts, and the structured output it returns.

The catalog splits cleanly into three kinds of tool. Most are extraction tools that read the web and hand back structured JSON:

A smaller set are action tools that write to the web in the user's real, logged-in session - CreatePostOnReddit(startUrl, postTitle, postBody), PostReplyOnX(startUrl, postText), and the like.

And one is a credential-gated tool that logs in, does a job, and logs out: DownloadBankingTransactionsForRange. That one is worth its own section below, because it is the whole thesis in a single row.

The thing to notice is what is not in any of these entries: no selector code, no scraping logic, no per-site glue that the agent has to hold in its context or maintain. The recording is the tool. The expensive part - working out where the Amazon price lives, which rows are products and which are sponsored cards - was done once, by a human, at record time. The agent just sees a function called GetAmazonSearchResults that returns prices.

Reading the contract: describe_script

Before it calls a tool, an agent asks for the exact input shape. describe_script returns an input_template - literally the JSON object to fill in and hand to run_script - along with real example values. Here is the real response for the Amazon search tool, verbatim:

{
  "success": true,
  "display_name": "GetAmazonSearchResults",
  "description": "Search Amazon for searchTerm and extract the search results array from the first results page. Return the first 10 results with non-null productTitle that does not include the words 'Shop now' and where sponsoredTag doesn't read 'Sponsored'.",
  "inputs": [
    { "name": "searchTerm", "description": "the item to search for", "example": "floor lamp" }
  ],
  "input_template": { "searchTerm": "floor lamp" },
  "target_website": "https://www.amazon.com"
}

The agent fills input_template, calls run_script, and gets back a clean searchResults array of typed rows - no HTML, no selector guessing, ad and sponsored rows already filtered out at record time. That filtering is not a best-effort string match bolted on afterward: array membership is decided structurally, by finding the page's genuinely repeating structure, which is why you do not get half-populated rows or sponsored noise leaking into the results. The description even encodes the human's intent - "first 10 results, non-null title, no 'Shop now', no 'Sponsored'" - so the agent knows what it is getting before it spends anything to get it.

This is what makes a recording usable as a tool by a model: the schema is explicit and the examples are real. There is no "the model has to infer the argument format" step, and no round of trial-and-error to discover that a date wanted 3/1/2026 and not 2026-03-01.

The tool that proves the whole thesis: a bank login with no password in its schema

The strongest single row in the catalog is the credential-gated one. Here is the real describe_script response for it:

{
  "success": true,
  "display_name": "DownloadBankingTransactionsForRange",
  "description": "Login to bank (MFA) go to checking account, in export widget enter startDate, endDate, and format, then submit. Don't forget to log out at the end before terminating.",
  "inputs": [
    { "name": "userName",  "description": "account number", "example": "6230486" },
    { "name": "startDate", "description": "Start date for transaction export", "example": "3/1/2026" },
    { "name": "endDate",   "description": "End date for transaction export", "example": "4/30/2026" },
    { "name": "format",    "description": "Export file format (e.g., CSV, OFX)", "example": "OFX File (.OFX)" }
  ],
  "input_template": {
    "userName": "6230486", "startDate": "3/1/2026", "endDate": "4/30/2026", "format": "OFX File (.OFX)"
  },
  "target_website": "https://americafirst.com"
}

This tool logs into a bank through multi-factor authentication, exports a date range of transactions, and logs out. Now look at its input schema: there is no password field and no MFA field. There is nowhere in this tool's contract for a secret to go, and the agent that calls it never sees one.

That is by construction, not by promise. The credential is released locally by the browser extension at the moment the login form is reached, inside the user's own Chrome. It is never sent to webSlinger's servers, never enters the agent's context, and never appears in any transcript. Zero-knowledge here means exactly that the secret is never transmitted to webSlinger - the extension injects it locally, at the page, and the MFA step is handled the same way the human handled it when they recorded the task. An agent builder can hand their LLM a "download my bank statements" tool without handing it their banking password. The tool's schema above is the proof: the field simply is not there to fill in.

Three ways this changes the economics

Read the catalog back and three distinct advantages fall out, each sharper than the last for someone paying an agent to work the web.

1. Deterministic, cheap-after-learning execution. When the agent called for Amazon results, it did not re-derive a selector, re-parse a DOM, or spend vision tokens finding the price. It called a named function with a typed argument. The expensive discovery happened once, at record time; every run after that is a cheap, deterministic replay. That is the unit-economics wedge against the browser-agent category - the tools that pay, in tokens and latency and a non-zero failure rate, to re-figure-out the same page on every single run.

2. Credential-safe by construction. The banking tool authenticates through bank MFA, yet its schema holds no secret. Secrets live in a local vault and are injected in-browser; they never reach the model's context or webSlinger's servers. Giving an autonomous agent access to a real, logged-in action no longer means giving it your password.

3. Access to anything you can reach, as if you fetched it yourself. The nineteen tools span a bank, a major retailer, half a dozen social platforms, a weather service, and an obscure registry. Each runs in the user's real, logged-in browser session - which is precisely the content generic scrapers get blocked from. A recording turns "a page a human can reach" into "a structured endpoint an agent can call."

What it actually takes to build one

Two honest points, because the shape of the offer matters more than a slogan.

First, recording a task is a matter of minutes, but there is a real per-site learning curve. Each site is different and takes some figuring-out to approach well, especially the first few times. The honest framing is "about an hour to plan the task, then a few minutes to record it," not a flat "minutes." The payoff is that the cost is paid once: after recording, the script is a fixed asset that runs the thousandth time as cheaply and deterministically as the first, with no model call anywhere in its execution path.

Second, these tools run against your own machine. The webSlinger extension and local components have to be running for run_script to launch your Chrome and do the work. That is not a limitation so much as the reason the credential and real-session guarantees hold - the automation happens in your browser, on your side, not on a server somewhere. The MCP server is a real, installable component; it is not a hosted service that reaches into the web on its own.

How to try it

The fastest way to see the tool-use loop is to run it, not to take this post's word for it. The on-ramp is a 7-day trial with no email and no credit card - it exists specifically so you can wire up the MCP server and watch an agent call list_scripts and run_script against a real site, end to end, before deciding whether the pattern is worth paying for. Add the server to your MCP client, call list_scripts to see the catalog, describe_script to read a contract, and run_script to get structured JSON back from a real page. Everything this post showed - the catalog, the typed contracts, the bank tool with no password in its schema - is exactly what your own agent will see on the other side of the wire.

Further reading