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 |
|---|---|
| browser_doA | Navigate and act inside a session from browser_open: the same actions as web_act, |
| web_diffA | Compare a page with the copy svipall cached last time and return what changed: |
| 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_profileA | Move a logged-in browser profile between machines: |
| 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_logA | Report what this installation has done per domain: which tier answered, which wall appeared, how long it took. |
| 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_notesA | Remember a value across sessions: |
| 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: |
| report_captchaA | Report whether a captcha answer worked ( |
| solve_turnstileA | Solve a Turnstile challenge from its |
| web_searchA | Search the web without an API key by reading public search engines' own result pages; the first engine with results answers, |
| web_snapshotA | Read a page as its interactive structure: every button, link and field with its role, accessible name and a short |
| browser_setupA | Manage the browser behind the browser, stealth, real and warm tiers. |
| 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 |
| solve_recaptcha_v2A | Solve a reCAPTCHA v2 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_openA | Open a persistent stealth browser session and return a |
| web_fetchA | Fetch one URL and return its main content as markdown (PDF and office documents too), or as rows with |
| 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_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 |
| web_watchA | Watch a page, or one |
| 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. |
| web_routeA | Send one domain (subdomains inherit) through a proxy from now on, or through a pool with |
| web_fetch_manyA | Fetch several URLs in parallel with the same escalation, |
| 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. |
| solve_hcaptchaA | Solve an hCaptcha challenge from its |
| captcha_statusA | Check a captcha task by its |
| 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. |
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 29 tools
Most tools have clearly distinct roles: web_fetch is for single pages, web_fetch_many for known batches, web_crawl for discovery, web_map for URL listing, web_snapshot for interactive structure, web_act for one-shot actions, and browser_open/browser_do for persistent sessions. The captcha-solving tools overlap in style but each targets a different challenge type, and descriptions explain when to use solve_and_continue versus the token solvers. Minor confusion is possible across the many browser/session and captcha variants, but overall boundaries are clear.
All names use consistent lower snake_case with predictable domain prefixes: web_*, browser_*, solve_*, captcha_*, report_*. The convention is not strictly verb_noun throughout (e.g., web_snapshot, web_capture, solve_and_continue), but the prefix-based grouping is systematic and readable. No camelCase or chaotic mixed styles.
29 tools is above the recommended range for a well-scoped MCP server and sits in the 'too many' band under the rubric. While many capabilities are genuinely distinct, several could be consolidated (e.g., captcha solvers, browser session tools, fetch variants), making the surface heavier than necessary.
The surface covers the full web-automation lifecycle: discovery (web_search, web_site_search, web_map, web_crawl), reading (web_fetch, web_fetch_many, web_snapshot, web_screenshot, web_capture), interaction (web_act, browser_open/do/close, web_login), captcha handling, proxy routing, status/logging, profiles, watching, diffs, notes, and setup. No obvious major operation for the stated domain is missing.