svipall
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| solve_turnstileA | Solve a Turnstile challenge from its |
| web_watchA | Watch a page, or one |
| web_logA | Report what this installation has done per domain: which tier answered, which wall appeared, how long it took. |
| web_screenshotA | Save a PNG of a page rendered in a real browser, anti-bot handled like web_fetch, and return its path, by default with the image inline. Use when the question is visual: layout, a chart, an image, how a page looks to a person. To read or act on a page use web_snapshot instead: cheaper, and it gives refs, whereas a screenshot cannot be clicked. |
| web_diffA | Compare a page with the copy svipall cached last time and return what changed: |
| web_fetch_manyA | Fetch several URLs in parallel with the same escalation, |
| solve_and_continueA | Solve the captcha on a blocked page in place and return the page behind it. The right choice whenever the goal is the content: solve_turnstile, solve_recaptcha_v2 and solve_hcaptcha return a bare token bound to the session and address that produced it, which rarely works elsewhere. Use after web_fetch returns |
| web_profileA | Move a logged-in browser profile between machines: |
| web_crawlA | Crawl one site from a start URL and return every page as markdown, deduplicated, robots.txt obeyed. Use when the pages are not known in advance; when they are, web_fetch_many is cheaper, and web_map lists a site's URLs for a few hundred tokens before deciding to crawl. |
| web_snapshotA | Read a page as its interactive structure: every button, link and field with its role, accessible name and a short |
| web_captureA | Record the JSON and XHR responses a page fetches while it loads and return them: the site's own API, smaller, typed and more stable than the HTML built from it. Use to find the real endpoint behind a listing or pagination; an endpoint that took page=1 takes page=2, which beats following links. Call once without |
| browser_openA | Open a persistent stealth browser session and return a |
| captcha_statusA | Check a captcha task by its |
| report_captchaA | Report whether a captcha answer worked ( |
| web_mapA | List a site's URLs without fetching its pages: robots.txt, sitemaps (nested indexes and .gz), RSS/Atom feeds and homepage links. Use before web_crawl to decide what is worth fetching, or to find the page for a topic: a few hundred tokens instead of the thousands a crawl costs. Returns |
| web_searchA | Search the web without an API key by reading public search engines' own result pages; the first engine with results answers, |
| solve_hcaptchaA | Solve an hCaptcha challenge from its |
| solve_image_captchaA | Read the characters in an image captcha given as base64 or a URL and return them as text. Use when a form shows a picture of distorted characters you will type yourself; for a challenge widget on a blocked page use solve_and_continue. Returns |
| browser_closeA | Close a session opened with browser_open and release its browser. Call it when the multi-step work is done; sessions left open keep a browser running. |
| solve_recaptcha_v2A | Solve a reCAPTCHA v2 challenge from its |
| web_fetchA | Fetch one URL and return its main content as markdown (PDF and office documents too), or as rows with |
| web_routeA | Send one domain (subdomains inherit) through a proxy from now on, or through a pool with |
| web_site_searchA | Search one site through its own search box and learn the URL pattern the form produces. Use for shops, job boards and docs whose content only appears when asked for: a crawl reaches only what is linked, and web_search covers the whole web, not one site. Returns |
| web_statusA | Show the current state: learned tiers, cooldowns, address budgets, proxy routes, profiles, open browser sessions, resumable crawls, solver stats and the dashboard URL. Use when something is blocked or slow to see why, and to reset it: |
| web_loginA | Open a visible browser window so a person can log in or pass a challenge by hand, then save the cookies to a profile. Use when a fetch returns |
| web_videoA | Read a video: captions and chapters as one |
| browser_doA | Navigate and act inside a session from browser_open: the same actions as web_act, |
| web_actA | Open a URL in a browser, run a list of actions and return the resulting page. One shot with no session: for several steps on one login or cart use browser_open + browser_do. Take a web_snapshot first and name elements by |
| web_notesA | Remember a value across sessions: |
| browser_setupA | Manage the browser behind the browser, stealth, real and warm tiers. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 30 tools
Each tool has a clearly distinct purpose: fetching vs browsing vs crawling vs captcha solving vs session management. Even similar tools like web_fetch and web_fetch_many are clearly differentiated by known vs unknown URLs. The separate solve_* tools for different captcha types avoid ambiguity.
All tools follow a consistent lowercase snake_case pattern with domain prefixes (web_, browser_, solve_, captcha_, report_). The verb_noun or noun_verb structure is predictable, e.g., web_fetch, browser_open, solve_turnstile.
30 tools is on the high end, but the broad scope of web automation (fetching, browsing, captcha solving, monitoring, state) justifies the count. Each tool serves a specific function, and the organization into clear categories prevents the set from feeling bloated.
The toolkit covers the full lifecycle of web interaction: fetching, browsing, crawling, searching, captcha solving, session persistence, monitoring, and diagnostics. There are no obvious dead ends—every operation has a corresponding tool, and helpers like web_status and web_log provide transparency.