Octocrawl
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 |
|---|---|
| scrapeA | Read one URL as Markdown with its Evidence Record (final URL, fetch time, HTTP status, robots.txt decision, hashes), over HTTP first and in the browser when the page needs it. Not for: many URLs or a whole site section. Compact by default; debug adds the full audit. warnings name what the content cannot vouch for (client_rendered_suspected, robots_overridden), and agentHints the next step. metadata.scrapeId names the call's record for get_scrape. |
| mapA | List a site's URLs without reading each page: the start page's links (read over HTTP alone) and the entries of the sitemaps the site declares, within one deadline. URLs stay in scope (the start host and its www twin, the start path's subtree, assets left out, similar URLs folded) and robots.txt applies unless ignoreRobotsTxt is set; what was left out is counted. No page title is fetched. At the deadline the answer is what was found (partial, stoppedBy timeout). Compact by default; debug adds each link's evidence and the sources read. Not for: reading pages, as one page body is read at most. |
| get_scrapeA | Read one scrape call's record by its scrapeId (metadata.scrapeId on the response). It holds the request (header values replaced by their names), who made it, the verdict, the lanes tried, metadata, usage, warnings and hints; no page body. Records are kept without a time limit. |
| crawlA | Start crawling a section of one site: from url, follow links in the start path's subtree on its host and www twin, up to maxPages pages and maxDepth links deep. Returns { taskId } at once (with maxPages when the default of 100 applied); wait_crawl waits for it, then get_crawl_pages reads the pages. How long the server keeps them is not stated. Each page takes scrape's page options (formats, onlyMainContent, includeTags, waitFor, timeout, verify and the rest; their descriptions are on scrape). Similar URLs fold into one page, and every collapsed or refused link is counted in get_crawl's discovery. |
| get_crawlA | Read a crawl's report by its taskId: its status, page counts and the discovery counters of the links it collapsed or refused. |
| wait_crawlA | Wait up to timeoutMs (default 30000, at most 120000) for a crawl to finish and return its report; at the timeout it returns the report so far, so wait again or read get_crawl_pages. |
| get_crawl_pagesA | Read a paginated list of crawl page results by task id (the latest attempt's unless attemptId is given). Pages omit the routing audit and trace unless debug is true, and leave out pages whose content repeated an earlier page's (status duplicate) unless includeDuplicates is true. With maxResults the tool follows cursors itself, up to that many pages, and answers { items, nextCursor, hasMore, stoppedBy }. |
| get_crawl_errorsC | Read a paginated list of crawl errors by task id. |
| cancel_crawlB | Cancel a crawl task. Completed pages remain queryable. |
| resume_crawlA | Restart a paused or failed crawl with the options it was started with. Returns { taskId }; poll get_crawl. |
| list_active_crawlsA | List the crawls the API process is running (those it started and those it resumed at startup; never a batch): each with its id, start URL, status, pages so far and the options it was started with. Empty when nothing runs. |
| batch_scrapeA | Run 1-1000 known URLs as one persistent job. Returns { taskId } at once (with ignoreInvalidURLs also invalidURLs, the entries skipped); wait_batch waits for it, get_batch_items pages the results and get_batch_errors lists the failures and robots refusals. Each URL takes scrape's page options (formats, onlyMainContent, includeTags, waitFor, timeout, verify, actions and the rest; their descriptions are on scrape). appendToId adds the urls to an existing batch; idempotencyKey makes a retry safe. How long the server keeps the results is not stated. |
| get_batchB | Read a batch's status by its taskId: its state, item counts and the items waiting for the person (waitingForPerson). |
| get_batch_itemsA | Page through a batch's results by its taskId (cursor, limit up to 50); with maxResults the tool follows the cursors itself and answers { items, nextCursor, hasMore, stoppedBy }. |
| wait_batchA | Wait up to timeoutMs (default 30000, at most 120000) for a batch to finish and return its status; at the timeout it returns the status so far, so wait again or read get_batch_items. |
| cancel_batchB | Cancel a batch by its taskId; the items already read stay readable. |
| get_batch_errorsA | List a batch's items that did not succeed, across every attempt. errors [{ id, timestamp, url, status, code, error, httpStatus }] come in pages of up to 1000 (cursor, limit); robotsBlocked lists every URL robots.txt refused (a governance or SSRF refusal stays in errors). |
| hand_off_batchA | Hand a finished batch's items that a check stopped to the person in their own Chrome, one tab at a time; waits for the person, up to 10 minutes a page by default. A check is a captcha, a challenge or a login wall (get_batch's waitingForPerson); once the person is through, Octocrawl reads the page and replaces the stopped result. Octocrawl passes no check itself. Local server only; Chrome needs remote debugging on and the person clicks Allow once. Tell them first: it waits up to waitMs per page (default 600000) and reads a page only after they click or type in its tab. Returns { id, handedOff, through, notThrough, items }. |
| scrape_productB | Get evidence-backed JSON for one anonymous Amazon.sg /dp/{ASIN} product. No schema or model setup needed. |
| batch_productsA | Queue 1-1000 distinct Amazon.sg product URLs with the reviewed JSON schema. Returns taskId; wait_batch waits for it and get_batch_items pages the results. |
| import_loginA | Save the person's login to a site (a domain or a page URL on it) from the Chrome they use, so mode authed reads its pages signed in as them; waits for the person, up to 2 minutes by default. Local server only. They must be signed in there in Chrome's default profile, with remote debugging on; Chrome asks them to allow it (approveTimeoutMs, default 120000). Ask the person first and name the site: a site a page led you to is not theirs to save. It replaces a login already saved for that domain. Returns { domain, savedAt, cookieCount, localStorage, sessionSha256, ... }, never a cookie or a stored value. |
| list_loginsA | The person's saved logins (import_login, octocrawl login import): { logins: [{ domain, savedAt, cookieCount, localStorage, sessionSha256 }] }, never a cookie or a stored value. |
| remove_loginA | Forget the person's saved login to a site (a domain or a page URL on it). |
| preview_monitorC | Capture a nonpersistent sample and assess identity, fields, evidence, and missing reasons. Start with preset firecrawl-introduction. |
| create_monitorB | Create a public-document Monitor. Defaults to paused so a delivery destination can be configured first. Use preset firecrawl-introduction for first use. |
| list_monitorsB | List current Monitor state and freshness. |
| get_monitorB | Check a Monitor baseline, latest run, latest event, and next schedule. |
| run_monitorB | Queue a durable manual run. Returns runId immediately; disconnection does not cancel execution. |
| get_monitor_runB | Inspect a run and field assessment with evidence and failure reasons. |
| pause_monitorB | Pause scheduling and cancel active Monitor execution. |
| resume_monitorC | Resume Monitor scheduling; first run becomes due immediately. |
| cancel_monitor_runB | Explicitly cancel a queued or running Monitor run. |
| create_delivery_destinationA | Register an HTTPS webhook for a Monitor. The secretEnv names an operator environment variable; never send the secret value. |
| list_delivery_destinationsA | List webhook destinations, optionally for one Monitor (monitorId) or one crawl or batch (jobId, the taskId); custom header names are listed, never their values. |
| pause_delivery_destinationA | Stop new deliveries to a webhook destination; pending ones wait until it resumes. |
| resume_delivery_destinationB | Send deliveries to a paused webhook destination again, pending ones included. |
| list_deliveriesA | Page through delivery state and failures, for a Monitor (monitorId) or a crawl or batch (jobId, the taskId). Defaults to 20 compact results. |
| get_deliveryB | Inspect one delivery and its retry attempts. |
| retry_dead_letterC | Explicitly retry a dead-letter delivery with the same eventId. |
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 39 tools
The families (scrape/crawl/batch/monitor/delivery/login) are clearly separated and descriptions explicitly add 'Not for:' clauses and cross-references, which resolves most confusion. The main friction points are near-neighbours like scrape vs batch_scrape vs scrape_product, batch_products vs batch_scrape, and preview_monitor vs get_monitor_run, which require reading the full text to separate.
Nearly everything follows a verb_noun pattern (get_scrape, cancel_crawl, list_monitors, pause_delivery_destination), and the crawl_/batch_/monitor_/delivery_ families are predictable. Deviations are modest: bare verbs (scrape, map) and the noun_verb ordering of batch_scrape/batch_products break the pattern for two prominent tools.
39 tools is heavy, but the server genuinely spans several subdomains (scrape, map, crawl, batch, product extraction, monitors, webhook deliveries, saved logins), so much of the count is earned. Still, the surface feels over-granular in places, e.g. mirrored pause/resume pairs for both monitors and delivery destinations plus separate get/list/errors variants per job type.
Lifecycle coverage is strong: read (scrape/get_scrape), discover (map), bulk (batch_*), crawl (start/wait/get/errors/cancel/resume), monitors (create/run/pause/resume/get_run), deliveries (create/pause/resume/list/retry) and saved logins (import/list/remove). Gaps are minor: no update/delete for monitors, no delete/update for delivery destinations, and no explicit way to purge retained results.