Skip to main content
Glama
surfskyio

surfsky-mcp

Official
by surfskyio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Scrape a URL

surfsky_scrape
Read-onlyIdempotent

Fetch a single URL in a cloud browser and return clean markdown, HTML, links, or a screenshot with final URL and status. Read any page without managing a session.

Instructions

Fetch one URL in a throwaway cloud browser and return it as markdown (default), cleaned html, a list of links, and/or a viewport screenshot, with the final url, HTTP status and title. Use it whenever you only need to read a page: it starts no session, so there is nothing to stop, and it runs a real browser behind a residential proxy like the session tools. For a page that needs clicks, scrolling, a form or an interactive login, use surfsky_navigate, surfsky_act and surfsky_read; for a saved login pass profile_uuid here. A status of 200 with a short page may be a challenge page: read the content before trusting it. Text longer than max_chars is cut with a marker. Each call bills one short session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
osNoFingerprint operating system. Not allowed with profile_uuid.
urlYesURL to fetch; https:// is added when the scheme is missing.
cityNoProxy exit city, with country.
proxyNoOmit for the account default. 'premium': the residential pool (proxy_type 'mobile' for mobile IPs). 'shared': the free pool, tests only. Or your own proxy URL (user:pass@host:port); then country, region, city and proxy_type are not allowed.
regionNoProxy exit state or region, with country.
countryNoProxy exit country code, for example US.
formatsNoOne or more of markdown, html, links, screenshot (viewport JPEG). Default: markdown.
timeoutNoSeconds to wait for the navigation (default 30).
wait_forNoCSS selector to wait for before reading, for content that appears after the load event.
max_charsNoCut each text after this many characters (default 30000, at most 200000).
proxy_typeNoPool for Surfsky proxies: 'residential' (default) or 'mobile'.
wait_untilNoLoad state that ends the navigation: 'load' (default), 'domcontentloaded' (faster on heavy pages; then surfsky_wait for what you need), 'commit' (first response received), 'networkidle' (no requests for a while; busy pages never reach it and time out).load
profile_uuidNoSaved Surfsky profile to load: its cookies and logins come with it and are saved back on a normal stop. Only a uuid the user gave you. Not combinable with os, os_version or arch: the profile owns its fingerprint.
block_resourcesNoResource types the browser does not download: faster and less proxy traffic, but screenshots and layout lose them.
only_main_contentNoDrop navigation, headers, footers, asides and forms; keep the main or article content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark this as read-only and idempotent, and the description goes beyond them: it discloses the throwaway browser, that no session is started, that a residential proxy is used, that challenge pages may return 200, that long text is truncated with a marker, and that each call bills one short session. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and return formats, then adds targeted usage caveats and alternatives. Every sentence earns its place; the challenge-page warning, truncation behavior, and billing note are all decision-relevant rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter tool with no output schema, the description gives enough to invoke correctly: return formats, default behavior, URL normalization, challenge-page risk, truncation, billing, session semantics, and clear routing to sibling tools. Parameter details are fully covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema carries the parameter documentation. The description adds a few behavioral notes such as 'Text longer than max_chars is cut with a marker' and references profile_uuid for saved logins, but it does not substantially enrich parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Fetch one URL in a throwaway cloud browser and return it as markdown...'. It clearly distinguishes itself from interactive siblings by saying it is for when you 'only need to read a page' and names surfsky_navigate, surfsky_act, and surfsky_read as alternatives for interactive needs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('Use it whenever you only need to read a page'), when not to use it (clicks, scrolling, forms, interactive login), and names the alternative tools. It also adds practical guidance about challenge pages and saved-login profiles.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools