What the connector adds
One remote MCP endpoint, authenticated with an API key. The tools fall into three groups, and the split matters because they carry different risk.
Reading, always available
fetch_page, fetch_batch and get_page_links take a
URL and return clean markdown - or JSON, text, or HTML. No live browser is involved and
nothing is stateful. This is the majority of what an agent actually needs: articles,
listings, documentation, feeds, and PDFs read as text. What the extraction does to a page,
and how the thresholds behind it were set, is on its own page.
Driving a live page
open_page, observe_page, act, see_page,
extract_page and fill_form operate a real browser: click a
cookie banner, page through results, sign in, submit a form. The agent observes structure
rather than guessing at pixels, and each action is checked against a permission model
before it happens. The rules around acting on a site you are signed in to - where the
password lives, what the agent may do, what you can review afterwards - are in
the logged-in pages guide.
Memory and permissions
remember, recall and forget hold short notes about
task state that survive between sessions - a scratchpad for what the agent is doing, never
a place for secrets. list_permissions, list_credentials and
connect_site let the agent find out what it may do and hand you a link when
it needs something it does not have.
Failures that tell an agent what to do
An HTTP status is a poor instruction. A 403 might mean "you are blocked", "this needs a login", or "this is not available in your country", and an agent that cannot tell them apart retries the ones it should abandon and abandons the ones it should retry.
So every failure comes back as a code that is an instruction:
needs-credential (the page wants a signed-in session - fill a stored login),
blocked (the site refused and escalating will not help - try another source),
transient (the server faulted - retry shortly),
http-error (the path is wrong or gone - check the URL),
payment-required (the site quoted a price, which is a decision rather than an
error), and legally-restricted (withheld for legal reasons, usually by
jurisdiction).
Why a hosted connector rather than a local one
A browser on your laptop has your laptop's IP, your laptop's uptime, and your laptop's fingerprint. Sites that refuse automation refuse it there too, and a scheduled task cannot run when the lid is shut. Unfenced runs the browser on infrastructure built for it, keeps the logged-in session where the next run can find it, and answers from a real address.
A note on stale tool lists
MCP clients cache the tool list when a connector is added, and the transport is stateless, so nothing can tell a client that a tool changed. Every reply carries the surface version this build ships, and the dashboard shows you when a connector is running against an old one - so "it worked yesterday" has an answer rather than a shrug.