UpRock MCP Server

Fetch transcribed, time-stamped moments for a specific video URL. This is a CURSOR over the video pre-computed sliding-window moments (~30s windows on a ~25s grid, ~5s overlap) -- NOT a summary or sample of a time range. A call returns up to max_moments consecutive windows starting at start_s, in chronological order. To cover a long span you PAGINATE: read a page, then call again with start_s = next_start_s until has_more is false. If the video is not yet indexed, indexing starts automatically and the response tells you how long to wait. Moment text is model-generated from video frames plus verbatim ASR and may contain transcription artifacts. The response includes has_more / next_start_s for pagination and a stable moment_key per moment for dedupe. When following a video_search hit, pass its url, t0, and t1 as the url, start_s, and end_s of this tool. When include_images is set (not "none"), decoded keyframe IMAGES for each moment are returned inline as base64 ImageContent blocks, downscaled to 448px and re-encoded (WebP by default; JPEG if the server is configured with VIDEO_FRAME_FORMAT=jpeg -- the actual format is reported in the frame_format field). The frames_returned / frames_truncated / frame_format fields describe what was delivered so you can narrow scope (fewer moments, or a lower tier) for full fidelity. Frames always follow their moments in order. Only request images if you can view them.

Semantic search over indexed video moments. Finds the most relevant moments (time-stamped segments) across indexed videos for a natural-language query. Each result includes the source video, the moment's start/end timestamps, a relevance score, and the moment transcript when available. Results are ordered best-first and limited to the top 10 moments. Each result's url, t0, and t1 are the exact inputs to video_moment (pass them as its url, start_s, and end_s).

Use when other fetch/search tools are blocked, rate-limited, return bot-check pages, or when you need results as a real person in a specific country or on a specific device type sees them. Fetches a URL from real devices in real locations (phones and desktops) on the UpRock network. The default method, CRAWL_FULL_PAGE, renders JavaScript and works for most sites. Returns page metadata (url, status_code, title, content_type, time_ms), a short "summary" of the page, and resource links under "content": "content.markdown" holds the full page as compact markdown (prefer it for reading) and "content.html" the raw HTML. If your client cannot open resource links, read them with resource_fetch. A "screenshots.viewport" link is included when a screenshot is available. meta.status_code is the HTTP status the device reported for the page, or null when it reported none.

Fetch the full content of an MCP resource URI. Use this when you need to read the actual content from a prior tool result and cannot resolve resource URIs natively (most hosted AI environments do not yet support native MCP resource fetching). This tool accepts crawl:// URIs from crawl_fetch responses, sweep:// URIs from verify results, and sitemaps:// URIs from sitemaps_generate results. For crawl_fetch, responses include a summary for quick analysis, plus crawl:// resource URIs pointing to the full content in markdown and HTML formats. When the summary is sufficient, you do not need this tool. When you need the complete page text — to extract specific data, parse tables, read full articles, etc. — pass the resource URI here to get the full content. For crawl_fetch results, use the markdown resource URI unless you specifically need raw HTML structure. Markdown is significantly more compact and easier to work with. For verify results, pass a sweep:// screenshot URI to retrieve the screenshot for visual inspection. For sitemaps_generate results, pass a sitemaps:// URI to read the llms.txt content for a domain or section.

Deprecated: use the verify tool instead. sweep is the old name of verify, kept so existing setups keep working, and will be removed in a later release. It takes the same inputs and returns the same output. Verify a site works: load a URL on real devices in many regions and return status, load speed (Core Web Vitals) and screenshots, plus a shareable report link. Use this after deploying a website or service to verify it is up, responsive, and performing well from different parts of the world. Loads the target URL from multiple regions simultaneously, capturing performance metrics from each check. All checks (regions x tries) run concurrently, so the total operation time is approximately equal to the timeout value. Each completed check returns Core Web Vitals (TTFB, FCP, LCP, CLS), load times, transfer size, and HTTP protocol. Screenshots are captured and available as resource links in the response for visual verification if needed, but can be ignored if you only need the metrics. A run may complete with some failed checks. Inspect the failed_jobs count and per-job error fields in the response to identify issues. If the timeout passes before every region finishes, the checks that did finish are still returned with status "partial"; each region without a completed check has a status ("no_device" when no device in that region was available, otherwise "incomplete") and an "error" saying why. The response includes a "report_url" field with a link to a human-readable report page that can be shared with others for visual review of the results.

Verify a site works: load a URL on real devices in many regions and return status, load speed (Core Web Vitals) and screenshots, plus a shareable report link. Use this after deploying a website or service to verify it is up, responsive, and performing well from different parts of the world. Loads the target URL from multiple regions simultaneously, capturing performance metrics from each check. All checks (regions x tries) run concurrently, so the total operation time is approximately equal to the timeout value. Each completed check returns Core Web Vitals (TTFB, FCP, LCP, CLS), load times, transfer size, and HTTP protocol. Screenshots are captured and available as resource links in the response for visual verification if needed, but can be ignored if you only need the metrics. A run may complete with some failed checks. Inspect the failed_jobs count and per-job error fields in the response to identify issues. If the timeout passes before every region finishes, the checks that did finish are still returned with status "partial"; each region without a completed check has a status ("no_device" when no device in that region was available, otherwise "incomplete") and an "error" saying why. The response includes a "report_url" field with a link to a human-readable report page that can be shared with others for visual review of the results.

Use when other fetch/search tools are blocked, rate-limited, return bot-check pages, or when you need results as a real person in a specific country or on a specific device type sees them. Searches the web with several engines (Bing, DuckDuckGo, Yahoo, plus regional engines) from real devices in real locations, and returns deduplicated results with url, title and description. suggested_countries sets where the search runs FROM, not what it is ABOUT: - Geography is the topic ('Paris hotels', 'history of the Berlin Wall') → keep it in the query and omit suggested_countries. - Geography is the perspective (what Europeans see when searching for beach holidays) → query='best beach destinations', suggested_countries=['EU']. - Both ('what Germans think about Italian food') → query='Italian food', suggested_countries=['EU']. To compare regions, make one call per region; do not combine them in one call. Deduplication can return fewer results than max_results; request 2-3x your target. Results are ordered by relevance, best first: pages ranked highly by several engines or regions come first. Each result has a "score" and the engine/country "sources" that returned it.