MeshArc
Server Details
Crawl and scrape websites to clean markdown, and track what changed between crawls.
- Status
- Healthy
- Uptime
- 99.4% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- mesharc-org/mesharc-python
- GitHub Stars
- 0
- Server Listing
- MeshArc
TDQS
Scored across 15 tools
Each tool has a distinct resource+action: crawl_site (one-off crawl), scrape_urls (known URLs), map_site (sitemap listing), search_web (web search), list_pages/get_changes (stored data), and the project CRUD set. Descriptions explicitly contrast near-neighbors (e.g. crawl_site vs start_run, list_pages vs search_web, get_job vs list_pages), leaving little room for misselection.
All 15 tools use snake_case verb_noun form (list_projects, create_project, delete_project, start_run, cancel_job, get_changes), with only natural noun variation (crawl_site, map_site, scrape_urls, search_web) that still follows the same pattern. No mixed conventions.
15 tools is well within the ideal range and each earns its place: 4 project CRUD tools, 3 run/job lifecycle tools, 4 fetch/discovery tools, and 4 read/query tools, with no redundant entry points for the same operation.
Project lifecycle is fully covered (create/get/list/update/delete) plus fetch, monitor, and change-diffing operations, so core workflows have no dead ends. Minor gaps remain: runs past the limit cannot be paged, there is no run-export, and cancel_job covers stop but there is no dedicated single-run detail view outside get_job.
Available Tools
15 toolscancel_jobCancel a running jobADestructiveIdempotentInspect
Stop a crawl, run or batch that is still going. Use it when the work should not finish: a crawl started too wide, a run blocking the next start_run (which answers 409 meanwhile), a batch of the wrong URLs. To check a job without stopping it use get_job. Inputs: kind and id come from the 'job' object, or a crawl_site crawl_id with kind='crawl'. A run also needs project_id; list_runs shows which run is still going. Effect: queued work is dropped and the page in hand finishes. Pages already read stay. A stop cannot be undone; run the work again to resume. A finished job is left alone, so asking twice is harmless. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job's id. | |
| kind | Yes | 'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs). | |
| project_id | No | A run's project id; required for a run, ignored otherwise. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The job's id. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| kind | No | crawl, run or batch. |
| note | No | What a stop keeps and drops. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | Only on a failure: the HTTP status code. |
| outcome | No | 'cancelled' (it had not started), 'cancelling' (it stops after the page in hand), or the status of a job that had already ended. |
| project_id | No | A run: its project. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it explains what actually happens (queued work dropped, in-flight page completes, already-read pages retained), that the stop is irreversible, that re-asking on a finished job is harmless, and that write access is required with a specific 'read_only' refusal code. The annotations declare destructive/idempotent, but the description supplies the operational detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded – purpose, usage, inputs, effect, permissions in that order – and each sentence carries distinct information. It is longer than typical, though the density is justified for a destructive, idempotent operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not cover return values, and it fills all remaining gaps: inputs sourcing, side effects, reversibility, idempotency behavior, and authorization requirements. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, yet the description adds sourcing meaning the schema lacks: kind and id come from the 'job' object, a crawl_site crawl_id maps to kind='crawl', and project_id is required only for runs, with list_runs pointed to as the way to find an active run.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource set ('Stop a crawl, run or batch that is still going'), naming the three job kinds it governs. It also explicitly distinguishes itself from the read-only alternative get_job, so an agent can separate the two without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering scenarios (crawl started too wide, run blocking a start_run that returns 409, wrong-URL batch) and an explicit exclusion with the alternative to use instead ('To check a job without stopping it use get_job'). When-to-use and when-not are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crawl_siteCrawl a whole site onceAIdempotentInspect
Crawl a site once from a start URL, following links and the sitemap, and return the pages read. No project is set up. Use it for a site or section whose page URLs you do not know; for known URLs use scrape_urls. To watch the site afterwards, pass the crawl_id to create_project. Inputs: include_paths=['/blog/*'] reads the blog index and everything under it; paths match the URL path, never the host. Excluded pages do not count toward limit. limit=200 with max_depth=3 suits one section. config takes the keys get_project lists when called with no project_id. Cost: 1 to 4 credits per page, by the engine that read it; refused pages are free. Timing: it waits for the crawl, minutes for a large limit. If it outlasts the connection's time limit, a job comes back for get_job, and calling again returns the same crawl. The crawl is kept for a day. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The absolute http(s) URL to start from, e.g. the home page. | |
| limit | No | The most pages to read, 1 to 5,000 (default 50); the plan's page cap also applies. | |
| config | No | Fetch settings to override, as {key: value}; omit for the defaults. | |
| max_depth | No | Link hops to follow from the start URL (0 = that page only; default 3). | |
| exclude_paths | No | Globs over the URL path to skip, e.g. ['/tag/*', '*.pdf']; an exclude wins over an include. | |
| include_paths | No | Globs over the URL path to keep; a bare '/blog/' matches that one page only. Omit for the whole site. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | While it is still going: {kind: 'crawl', id} for get_job and cancel_job. |
| url | No | The start URL. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| note | No | What was cut, and how to read a page in full. |
| stop | No | Why the crawl ended early, e.g. its page limit; empty otherwise. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| index | No | Every page read (up to 500) as {url, title, words, status}. |
| pages | No | Up to 50 pages, each {url, title, words, status, links (a count), markdown excerpt}. |
| counts | No | Pages by outcome, e.g. {ok, blocked, error}. |
| cursor | No | Present when more pages exist: pass it to get_job for the next window. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | 'done', 'cancelled' or 'error' once finished, 'running' with a `job` while it goes on. On an error, the HTTP status code. |
| crawl_id | No | This crawl's id: for get_job, cancel_job, and create_project(crawl_id=...) to keep it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: cost model (1-4 credits per page, refused pages free), timing (waits for the crawl, may hand back a job for get_job), crawl retention (kept for a day), and auth requirements (needs write access, read-only refused with 'read_only'). This is well past what readOnlyHint=false and idempotentHint=true convey. It stops short of a 5 only because the pagination/return-shape handling is left entirely to the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but deliberately organized into labeled sections (Inputs, Cost, Timing, access), with the highest-value scope statement front-loaded. Every sentence carries information, though the block is longer than strictly necessary for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-param, open-world, potentially long-running crawl, the description covers scope, alternatives, cost, timing/job fallback, retention, and auth failure mode. Since an output schema exists, it correctly omits return-value detail without leaving any pre-call decision unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds real semantics the schema lacks: paths match the URL path and never the host, an exclude wins over an include, and excluded pages do not count toward limit. It also gives concrete tuning advice (limit=200 with max_depth=3 for one section) and locates valid config keys via get_project.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Crawl a site once from a start URL'), plus the mechanism (following links and the sitemap) and the output ('return the pages read'). It distinguishes itself from scrape_urls and create_project by name, so an agent can pick it apart from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('a site or section whose page URLs you do not know'), explicit alternative ('for known URLs use scrape_urls'), and a follow-on path ('to watch the site afterwards, pass the crawl_id to create_project'). The routing logic is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_projectCreate a watched projectAInspect
Create a project: a site MeshArc re-crawls on a schedule, comparing each run with the last to record pages added, modified and removed. Use it when asked to monitor or track a site; for a one-off read use crawl_site. Check list_projects first so the site is not added twice. Inputs: seed starts a new project, e.g. 'example.com'. crawl_id instead keeps a crawl_site crawl from the last day as the first run, with no second fetch; it keeps that crawl's settings, so config goes only with seed. The usual config keys are include_paths (one section, e.g. ['/blog/*']), exclude_paths, max_pages and render_js; get_project with no project_id lists them all. Cost: creating reads robots.txt and the sitemaps but no pages, so it is free. Each run spends credits per page, and any schedule but 'manual' runs on its own. Refusals: an unknown config key, or a plan already at its project limit (code plan_limit). Values above the plan's caps are lowered to them. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A display name; omit for the site's host (or the crawl's own name). | |
| seed | No | The site to watch, as a URL or bare domain, e.g. 'https://example.com/blog/' or 'example.com'; its host is fixed for good. Give this or crawl_id. | |
| config | No | Settings as {key: value}, with a seed only; omit for the defaults. | |
| crawl_id | No | A crawl_site answer's crawl_id, to keep that crawl as the project. Give this or seed. | |
| schedule | No | How often it re-crawls on its own; 'manual' (default) runs only when start_run is called. | manual |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The project's 32-character hex id. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| host | No | The site it covers; fixed at creation. |
| name | No | Its display name. |
| note | No | No project_id only: how path globs work. |
| seed | No | Where its crawls start. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| config | No | Its settings as {key: value}; secrets such as chat_url come back masked. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| pagesN | No | Pages its last finished run read. |
| status | No | draft, crawling, healthy or failing. On an error, the HTTP status code. |
| coverage | No | Percent of the site the last run reached; under 90 means removals are withheld. |
| settings | No | No project_id only: every common setting as {key, meaning, default}. |
| webhooks | No | get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included. |
| lastRunAt | No | When the last run started (ISO 8601), or null. |
| nextRunAt | No | When the schedule runs it next, or null for manual. |
| retention | No | How long runs are kept, e.g. '90d'. |
| schedules | No | No project_id only: the valid schedules. |
| other_keys | No | No project_id only: further keys accepted but rarely needed. |
| scheduleKey | No | manual, hourly, daily or weekly. |
| webhookTest | No | update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved. |
| changeSummary | No | The last compared run in words, e.g. '3 new · 2 changed · 0 removed'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: creation costs nothing because it reads robots.txt/sitemaps but no pages, each run spends credits per page, any non-manual schedule runs autonomously, plan caps silently lower oversized values, and it requires write access (read-only connections refused with 'read_only', over-limit with 'plan_limit'). Annotations only supply the readOnly/destructive/idempotent profile; the cost, refusal, and autonomy behavior is unique to the text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded and cleanly chunked into Purpose/Inputs/Cost/Refusals, with no redundant restatement of the name or title. Some sentences are dense, but each carries distinct information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the gap left by the structured fields: an output schema exists so return values need no explanation, and annotations cover safety, while the description supplies cost model, authorization requirement, refusal codes, and cap-clamping behavior. Nothing needed to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real semantics the schema cannot express: seed vs crawl_id mutual exclusivity and the consequences of each (seed starts fresh and carries config; crawl_id reuses a crawl from the last day with no second fetch and keeps that crawl's settings). It also enumerates the accepted config keys (include_paths, exclude_paths, max_pages, render_js), which the schema leaves as an opaque additionalProperties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource and immediately defines what a project actually is (a site re-crawled on a schedule with diffing), which is non-obvious. It explicitly distinguishes itself from crawl_site (one-off read) and list_projects (dedupe check), so an agent can route correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('monitor or track a site'), when-not-to ('for a one-off read use crawl_site'), and a prerequisite ('Check list_projects first so the site is not added twice'). Alternatives and conditions are named rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_projectDelete a projectADestructiveIdempotentInspect
Delete a project for good, with everything its runs stored. Use it only when the person asks for the project to go, e.g. to free a slot after create_project is refused with plan_limit. To stop a run use cancel_job; to stop scheduled runs set schedule to 'manual' with update_project. Inputs: project_id from list_projects. confirm_name must repeat the project's name exactly as get_project shows it, or nothing is deleted. Effect: its runs, pages, change records and webhook history are removed for good, and a run in progress stops. Credits already spent stay spent. A second call answers 404. Needs an admin API key. A connected app (OAuth) never has one: it is refused with code admin_only and told where to delete instead.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project's 32-character hex id, from list_projects. | |
| confirm_name | Yes | The project's name, exactly as get_project shows it. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The deleted project's id. |
| code | No | Only on a failure: e.g. admin_only (the key is not an admin's), validation (confirm_name did not match) or not_found. |
| name | No | Its name, as confirmed. |
| note | No | What was removed with it. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | Only on a failure: the HTTP status code. |
| deleted | No | true once the project and its history are gone. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive and idempotent, but the description goes well beyond them: it enumerates what is destroyed (runs, pages, change records, webhook history), notes an in-progress run stops, that already-spent credits are not refunded, that a second call returns 404, and that an admin API key is required with OAuth apps refused via admin_only. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and constraint, then grouped into Inputs and Effect blocks that are easy to scan. Slightly long, but nearly every sentence carries a distinct fact (alternatives, guardrail, destruction set, auth requirement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, guarded mutation with rich annotations and an output schema, the description covers usage, inputs, side effects, auth, and error behavior. Nothing an agent needs to call this safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds the consequence-level meaning that confirm_name must match exactly 'or nothing is deleted' and that project_id comes from list_projects. That guardrail framing is real value over the schema's field-level text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delete a project for good, with everything its runs stored') and immediately scopes the blast radius. It is unmistakably distinct from siblings like cancel_job and update_project, which it names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use trigger ('only when the person asks for the project to go, e.g. to free a slot after create_project is refused with plan_limit') plus two named alternatives with the conditions that select them (cancel_job to stop a run, update_project with schedule='manual' to stop scheduled runs). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_changesGet what changed in a runARead-onlyIdempotentInspect
Report what changed in a project run against the run just before it, or against any run you name: pages added, modified and removed, field changes, and coverage. Use it to answer 'what changed on the site', or 'since last month' with against. list_pages shows every page whether or not it changed, and list_pages with url one page's text and versions. Inputs: project_id from list_projects. run_id from list_runs picks the run; empty means the latest finished run. against, another run's id from list_runs, compares the two directly instead of with the run just before. A run still going answers 409. Safeguards: removals are withheld when a run reached under 90% of the site, so a blocked crawl never reports pages as gone. A project's first run is a baseline with nothing to compare. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | A run's id, from list_runs; empty means the project's latest finished run. | |
| against | No | Another run's id, from list_runs, to compare with directly; omit to compare with the run just before. | |
| project_id | Yes | The project's 32-character hex id, from list_projects. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| runs | No | The finished runs a record exists for, newest first, for picking another run_id. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| change | No | {runId, prevRunId, baseline, rebaselined, coverage, degraded, counts {added, modified, removed}, summary, feed, fields, withheld}. feed: each changed page as {url, path, kind (added, modified or removed), added and removed (words, e.g. '+12'), wordsBefore, wordsAfter}. fields: head and extracted field changes as {url, field, before, after}. withheld: removals held back because coverage was under 90%. Each list holds up to 200. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | Only on a failure: the HTTP status code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: it discloses that an in-progress run returns 409, that removals are suppressed when a run covered under 90% of the site, and that a project's first run is a baseline with nothing to compare. These are exactly the edge cases that prevent a wrong interpretation of an empty diff.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose before labeled Inputs/Safeguards/Read-only sections, and every clause carries information. The trailing 'it reads stored data and never fetches' mildly duplicates the readOnlyHint annotation, keeping it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description still covers inputs, cross-tool sourcing (list_projects, list_runs), error behavior, and the safeguard semantics. Nothing an agent needs to call this correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions already explain run_id, against, and project_id, so the description largely restates them. It adds modest value by framing `against` as an alternative to the default previous-run comparison, but no format, syntax, or sourcing detail beyond what is already structured. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Report what changed in a project run') and enumerates the output categories: pages added, modified, removed, field changes, coverage. It explicitly differentiates itself from the sibling list_pages, which 'shows every page whether or not it changed', so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger phrases ('what changed on the site', 'since last month') and maps the latter to the `against` parameter. It names the alternative (list_pages, and list_pages with url) and states the condition under which each applies, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobFollow a long-running jobARead-onlyIdempotentInspect
Check on a crawl, run, batch or web search a tool handed back as a job, and return its result once finished. Call it when a tool answered with status 'running' and a job; repeating that tool is not needed. To stop a crawl, run or batch use cancel_job. For a project's stored pages use list_pages. Inputs: kind, id and project_id come from the 'job' object; a crawl_site crawl_id is a crawl's id. For a crawl, url reads one page in full, even mid-crawl, and cursor from the last answer reads the next window. Behaviour: it answers at once and never waits, so call it again every 10 to 30 seconds while the status is 'running'. A finished crawl answers as crawl_site does (up to 50 pages excerpted per window), a batch as scrape_urls, a search as search_web, a run with its record. A scraping search whose pages are still landing answers with its results and the job. A crawl expires a day after it started unless kept, then answers 404. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job's id. | |
| url | No | Crawls only: one page's URL from the crawl's index. | |
| kind | Yes | 'crawl' (crawl_site), 'run' (start_run), 'batch' (scrape_urls with several URLs) or 'search' (search_web). | |
| cursor | No | Crawls only: the cursor the previous answer returned. | |
| project_id | No | A run's project id; required for a run, ignored otherwise. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | A run or a search: its id. |
| job | No | While running: {kind, id, project_id} to call again with. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| note | No | What to do next. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| index | No | A finished crawl or batch: every page as {url, title, words, status}. |
| pages | No | A finished crawl or batch: pages with excerpts. |
| counts | No | Pages by outcome so far. |
| cursor | No | A crawl with more pages: pass it back for the next window. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | 'running' while it goes on; otherwise the finished job's status. On an error, the HTTP status code. |
| results | No | A search: the ranked results, as search_web returns them, with page excerpts when it scraped. |
| crawl_id | No | A crawl: its id. |
| markdown | No | With url: that page's markdown, capped at 12,000 characters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive, non-open-world), it discloses behavior the annotations cannot: it answers immediately and never waits, should be re-called every 10-30s while running, output shape mirrors the originating tool, partial search results are returned mid-flight, and crawls expire after a day returning 404. These are the details an agent actually needs to poll correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well front-loaded (purpose, then trigger, then Inputs/Behaviour/read-only labels), and every sentence carries information. It is on the longer side and the 'answers as X does' sentence is dense, but nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and the annotations cover the safety profile. The description nevertheless covers triggering, polling cadence, partial results, expiry and parameter sourcing, leaving no gap an agent would need to guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description still adds non-duplicative value: it explains that kind/id/project_id are read from the 'job' object, that crawl_site's crawl_id maps to `id`, and how url/cursor select a page and window. Minor edge cases (e.g. enum semantics) remain in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb (check on / return result) and resource (a job handed back by crawl, run, batch or web search), and immediately distinguishes itself from siblings by naming cancel_job and list_pages. An agent can tell what this does without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when a tool answered with status running and a job') and an explicit non-action ('repeating that tool is not needed'), then routes to alternatives by condition: cancel_job to stop, list_pages for stored pages. This is exactly when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_projectGet a project, or the settingsARead-onlyIdempotentInspect
Read one project in full, or with no project_id the settings any project can take. Read a project before update_project to see its current values. Read the settings before create_project, update_project or any config argument: keys are exact, and a guessed name is refused. list_projects is the lighter way to find a project. Inputs: project_id is the hex id from list_projects, not a name or URL. An unknown id answers 404. Webhooks: a project's answer includes its webhook URL, the events sent there, and the last 10 deliveries with their status and error, to see whether the endpoint is receiving them. update_project sets them and sends a test. Secrets: the webhook signing secret is never returned, and chat_url comes back masked. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | The project's 32-character hex id, from list_projects; omit for the settings reference. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The project's 32-character hex id. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| host | No | The site it covers; fixed at creation. |
| name | No | Its display name. |
| note | No | No project_id only: how path globs work. |
| seed | No | Where its crawls start. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| config | No | Its settings as {key: value}; secrets such as chat_url come back masked. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| pagesN | No | Pages its last finished run read. |
| status | No | draft, crawling, healthy or failing. On an error, the HTTP status code. |
| coverage | No | Percent of the site the last run reached; under 90 means removals are withheld. |
| settings | No | No project_id only: every common setting as {key, meaning, default}. |
| webhooks | No | get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included. |
| lastRunAt | No | When the last run started (ISO 8601), or null. |
| nextRunAt | No | When the schedule runs it next, or null for manual. |
| retention | No | How long runs are kept, e.g. '90d'. |
| schedules | No | No project_id only: the valid schedules. |
| other_keys | No | No project_id only: further keys accepted but rarely needed. |
| scheduleKey | No | manual, hourly, daily or weekly. |
| webhookTest | No | update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved. |
| changeSummary | No | The last compared run in words, e.g. '3 new · 2 changed · 0 removed'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds real behavioral context: exact keys with guessed names refused, 404 on unknown id, webhook return contents, and that the signing secret is never returned and chat_url comes back masked. It is slightly redundant in restating 'read-only and free' which annotations already imply, keeping it just below the top.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is dense and front-loaded, with clear labeled sections (Inputs, Webhooks, Secrets) that aid scanning. It is somewhat long and repeats the read-only nature already covered by annotations, but nearly every sentence carries actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be fully specified, yet the description still summarizes what a project's answer contains (webhook URL, events, last 10 deliveries with status and error). Combined with mode, input, and secret-handling coverage, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: project_id is the hex id from list_projects, explicitly not a name or URL, and an unknown id returns 404. This closes the practical failure modes an agent would otherwise hit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb and resource ('Read one project in full') and disambiguates its dual mode by explaining that omitting project_id returns the settings any project can take. It also positions itself against siblings, naming list_projects as the lighter way to find a project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing guidance is given: read before update_project to see current values, and read settings before create_project, update_project, or any config argument. It also names the alternative (list_projects) and the condition that selects it, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_pagesList, search or read a run's pagesARead-onlyIdempotentInspect
List the pages a project run stored; with q, find the pages whose text or markup matches; with url, read one page in full, with its versions across runs. Use it for what a project's runs stored: what a run covered, which pages say something, one page's text. search_web searches the live web instead, get_job reads a crawl_site crawl, scrape_urls fetches a live copy, and get_changes lists only what changed. Inputs: project_id from list_projects. q='free trial' needs both words, q='"free trial"' the phrase; mode='selector' takes CSS such as 'form#signup' and needs a run that kept html (the rawHtml format). url is an address, not a search term: scheme and trailing slash may differ, the rest must match, query string included. Give q or url, not both. run_id from list_runs picks the run. Limits: a listing has up to 500 rows, shallowest first, so use q to reach pages past them. A page read in full has each body capped at 12,000 characters, and a URL the runs did not store answers 404. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Text to find, 1 to 200 characters: words or a "quoted phrase", or with mode='selector' a CSS selector or an XPath starting with / or (. Omit to list every page. | |
| url | No | One page's full URL, as a listing shows it, to read that page in full; omit to list. | |
| mode | No | With q: 'content' (default) searches the markdown, 'selector' the stored html. | content |
| run_id | No | A run's id, from list_runs; empty means the latest finished run, or with url the newest copy across the project's last 50 runs. | |
| project_id | Yes | The project's 32-character hex id, from list_projects. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | With url: the page's URL as stored. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| head | No | With url: {title, description, canonical, h1, ...}. |
| hits | No | With q: up to 500 matches, each {url, count (matches on the page), snippet}. |
| html | No | With url: the raw html, when the run kept it. |
| text | No | With url: plain text, when kept. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| pages | No | Listing: up to 500 rows, shallowest first, each {url, path, status, depth, words, changed, title, crawledAt}. |
| runId | No | The run these pages are from (with url, the run this copy is from); null when the project has no finished run. |
| words | No | With url: words in its markdown. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| fields | No | With url: fields the project's json_schema extracted, or null. |
| noBody | No | With q: pages skipped because the body the mode needs was not kept (rawHtml for selector). |
| status | No | With url: the HTTP status the site answered. On an error, the API's status code. |
| scanned | No | With q: pages searched. |
| markdown | No | With url: its main content as markdown, capped at 12,000 characters. |
| versions | No | With url: every stored copy across runs, newest first, each {runId, crawledAt, contentHash, words, status}; a changed contentHash is a changed page. |
| cleanHtml | No | With url: simplified html, when kept. |
| crawledAt | No | With url: when this copy was read (ISO 8601). |
| linkGraph | No | Listing: the run's link-graph summary (orphans, unlisted pages, dead ends), or null. |
| truncated | No | With q: true when more pages matched than are listed. |
| pageStatus | No | With url: ok, blocked, captcha, missing (404/410), timeout, redirect, robots or skipped. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description adds genuinely new behavioral facts: 500-row listing limit with shallowest-first order, 12,000-character body cap per page, 404 for un-stored URLs, and the 50-run window for url reads. This is context annotations cannot provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then cleanly partitioned into 'Inputs' and 'Limits' groupings. Despite the density, every sentence carries operational information (syntax, defaults, limits) with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param tool with an output schema and rich annotations, nothing an agent needs to call it correctly is missing: routing against five siblings, query/URL syntax, run defaults, pagination limits, and body caps are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds meaning beyond it: boolean-vs-phrase query syntax ('free trial' vs '"free trial"'), selector CSS example, URL matching rules (scheme/trailing slash tolerance, query string must match), and run_id defaulting behavior for the two modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource and enumerates all three modes: list stored pages, search by q, read one page by url. It explicitly differentiates from siblings (search_web, get_job, scrape_urls, get_changes), so an agent can select it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names each alternative and the condition that selects it ('search_web searches the live web instead, get_job reads a crawl_site crawl...'). It also states an explicit exclusion ('Give q or url, not both') and when a run is needed for selector mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsList all projectsARead-onlyIdempotentInspect
List every project in the workspace, the sites it watches over time, each with its id, name, host, schedule, page count, coverage, last run and status; and the workspace's plan and the credits it has left. Call it first to find the project_id the other project tools take, to check a site is not already watched before create_project, or to see whether there are credits for a large crawl. get_project reads one project in full. Results: every project in one answer, oldest first, with no paging. A key limited to some projects sees only those. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | Only on a failure: the HTTP status code. |
| projects | No | Oldest first, each {id, name, seed, host, schedule, pages, coverage, lastRun, status}; status is draft, crawling, healthy or failing. |
| workspace | No | {plan, creditsLeft, creditsSpentThisMonth, oneTimeAllowance}: creditsLeft is what may still be spent, this month or, on a one-time allowance, ever; null means no limit. {note} instead when the balance could not be read. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, but the description adds substantive context beyond them: no paging, oldest-first ordering, key-scoped visibility ('a key limited to some projects sees only those'), and the fact that it never fetches remote data and costs nothing. These are non-obvious behaviors an agent would otherwise have to discover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and routing guidance before the enumerated return fields. The single long middle sentence enumerating project fields is dense but each clause maps to real output content, so it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still usefully previews returned fields plus workspace plan and credit balance, and adds scoping and ordering behavior the schema cannot convey. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty schema is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every project in the workspace') and immediately contrasts with the sibling that reads a single project ('get_project reads one project in full'). An agent can distinguish it from get_project without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three concrete when-to-use conditions: find the project_id other tools need, verify a site isn't already watched before create_project, and check available credits before a large crawl. It also names get_project as the alternative for single-project detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_runsList a project's runsARead-onlyIdempotentInspect
List a project's runs, newest first, with each run's id, status, trigger, pages read and pages changed. Use it to find a run_id for list_pages or get_changes, to check whether a run is still going before start_run, or to find the run to stop with cancel_job. get_project shows only the last run. Inputs: project_id from list_projects. limit=5 finds the latest few; runs past the limit cannot be paged. Errors: an unknown project answers 404. Read-only and free: it reads stored data and never fetches.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many runs to return, 1 to 100 (default 25). | |
| project_id | Yes | The project's 32-character hex id, from list_projects. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| runs | No | Each {id, status, trigger, scope, pagesN, changedN, counts, coverage, stop, startedAt, elapsed, baseline, rebaselined}; baseline is a first run with nothing to compare, rebaselined one whose settings changed how pages read, so it was recorded rather than compared. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | Only on a failure: the HTTP status code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint/openWorldHint, so the safety profile is covered. The description still adds real operational context beyond them: results are ordered newest-first, runs past the limit cannot be paged, an unknown project returns 404, and the read 'never fetches'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short labeled blocks (usage, Inputs, Errors, cost) keep it front-loaded, and every sentence contributes distinct information. Nothing is redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with full schema coverage, an output schema, and safety annotations, the description covers routing, ordering, limit behavior, and error semantics. Nothing an agent needs to select or call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so project_id and limit are already documented. The description adds provenance ('project_id from list_projects') and a concrete tuning hint ('limit=5 finds the latest few'), plus the non-paging consequence of limit that the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List a project's runs, newest first') and enumerates the fields returned (id, status, trigger, pages read/changed). It also distinguishes itself from the sibling get_project by noting that get_project shows only the last run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names three when-to-use cases and the corresponding alternatives: finding a run_id for list_pages/get_changes, checking an in-flight run before start_run, and locating the run to stop with cancel_job. No exclusion or alternative is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
map_siteMap a site's declared URLsAInspect
List the URLs a site declares in its sitemaps (found through robots.txt and the well-known paths, each index file walked to its children) without fetching any page. Use it first, to see how big a site is and what sections it has, before crawl_site or create_project. It cannot read content (scrape_urls and crawl_site do), and it misses pages a site links to but does not declare. Inputs: any page of the site works as url, since discovery starts at the root. search='/blog/' keeps the blog's URLs; it is a plain case-insensitive substring, not a glob, applied before limit. Cost: 1 credit per sitemap file read (usually 1 in total), never per URL. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Any URL on the site, usually its home page. | |
| limit | No | The most URLs to return, 1 to 5,000 (default 1,000); totals count them all. | |
| search | No | Keep only URLs containing this text; omit for all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | No | The site that was mapped. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| urls | No | The declared URLs, at most `limit`, filtered by `search`. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| method | No | How the sitemaps were found, e.g. through robots.txt. |
| status | No | Only on a failure: the HTTP status code. |
| totals | No | Counts over every declared URL and sitemap file, whatever `limit` returned. |
| sections | No | The section names the sitemaps group URLs under, e.g. 'blog'; empty when there are none. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare write-required (readOnlyHint=false) and open-world, but the description adds the concrete consequence: 'Needs write access; a read-only connection is refused with code read_only', plus the cost model (1 credit per sitemap file, never per URL) and the no-page-fetch guarantee. That is material context beyond the structured fields and consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then usage, limitations, parameter notes and cost in a tight sequence with no filler. It is dense and multi-clause, but every sentence carries information an agent needs; only the parenthetical discovery detail is slightly heavier than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no prose; the description covers purpose, ordering against siblings, input caveats, cost and the auth requirement. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), yet the description adds real semantics: 'any page of the site works as url, since discovery starts at the root' clarifies the url parameter beyond the schema, and 'search is a plain case-insensitive substring, not a glob, applied before limit' disambiguates matching semantics and ordering versus the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list the URLs a site declares in its sitemaps) and explains the discovery mechanism (robots.txt, well-known paths, index files walked to children). It explicitly distinguishes itself from crawl_site, scrape_urls and create_project, so an agent can pick it without opening sibling schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing ('use it first ... before crawl_site or create_project') plus when-not guidance ('cannot read content, scrape_urls and crawl_site do') and a known blind spot ('misses pages a site links to but does not declare'). Alternatives and selection criteria are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scrape_urlsScrape pages by URLAInspect
Fetch pages whose URLs you already have and return their content. No project is created. Use crawl_site when the URLs must be found by following links, and map_site to list a site's URLs without fetching. list_pages with url reads a page a project already stored, for free. Inputs: urls come from the request or from map_site. formats adds bodies, e.g. 'markdown,text'. config overrides fetch settings, e.g. {"render_js": "always"}; get_project with no project_id lists the keys. full=true reads one URL in full and runs config.actions first, e.g. [{"type": "click", "selector": "#load-more", "repeat": "until_gone"}]. Cost: 1 credit for a plain fetch, 4 with a browser, +1 for a screenshot. A page the site refuses is reported as blocked and is free. Lists: a list runs as one batch. If it outlasts the connection's time limit, a job comes back for get_job, and sending the same list again returns that batch. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | true reads the one URL in full -- raw html, head and extracted fields, images, the engine used -- running config's browser actions first. Default false. | |
| urls | Yes | Absolute http(s) URLs, 1 to 500; exactly one when full is true. | |
| config | No | Fetch settings to override, as {key: value}; omit for the defaults. | |
| formats | No | Bodies per page, comma-separated from markdown (default), text, cleanHtml and rawHtml. With full=true, config's formats list chooses them instead. | markdown |
| parse_documents | No | Read PDF, Word and spreadsheet URLs as text (default true). A parse_documents key in config wins. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | While a batch is still going: {kind: 'batch', id} for get_job and cancel_job. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| note | No | What was left out and how to get it. |
| page | No | full=true only: the page in full -- markdown, html, head {title, description, canonical, h1}, fields, images, engine, pageStatus -- with each body capped at 12,000 characters. |
| rest | No | A list past its index: {count, byStatus, notOk} for the urls not shown. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| index | No | A list only: every url as {url, title, words, status}, so none is lost when excerpts are cut. |
| pages | No | The pages read. A list: up to 50, each {url, title, words, status, links (a count), markdown excerpt}, the excerpts sharing 60,000 characters. One URL: that page in full, each body asked for capped at 12,000 characters. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| status | No | 'done' once read; 'running' with a `job` while a batch goes on; with full=true, 'blocked' when the site refused and 'error' when the read failed. On an error, the HTTP status code. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the credit cost model (1 plain, 4 browser, +1 screenshot), that blocked pages are free, that a list runs as one batch and may return a job for get_job if it outlasts the connection limit, and that write access is required (read-only connections refused with code 'read_only'). The annotations' readOnlyHint=false is consistent with and enriched by this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded and labelled ('Inputs:', 'Cost:', 'Lists:', 'Needs write access'), with the core action and its scope in the first sentence. Every subsequent sentence carries distinct operational information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, open-world, non-idempotent fetch tool with an output schema already present, the description covers everything an agent needs before calling: alternatives, input provenance, cost, batch/job behavior and auth requirements. Nothing material is left out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, and the description earns above that by supplying concrete examples: formats 'markdown,text', config {"render_js": "always"}, get_project with no project_id for valid keys, and a full=true config.actions example with a click/until_gone selector. It does overlap the schema on formats and full, so it is not maximally additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch pages whose URLs you already have and return their content') plus an explicit scoping constraint ('No project is created'). It immediately differentiates itself from crawl_site, map_site and list_pages by naming each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: crawl_site when URLs must be discovered by link-following, map_site to list URLs without fetching, list_pages with url for already-stored pages 'for free'. Each alternative is paired with the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_webSearch the webAInspect
Search the web for a query and return the ranked results, each with its title, url and snippet. The results are read from Google's results page, or Bing's when Google refuses. Use it to find pages whose URLs you do not know. It searches the web, unlike list_pages with q, which searches inside a project's stored run. For URLs you already have use scrape_urls; scrape_urls with full=true reads one result in full. Inputs: query as typed into a search engine, e.g. 'python http client'. scrape=true also fetches each result's page as markdown in the same call. include_domains=['python.org'] keeps the search to those sites; exclude_domains drops sites, and an exclude wins. Cost: Google's results page is read with a browser, 4 credits or more where it needs the stealth tier; Bing's, used when Google refuses, is a plain fetch at 1. A results page the engines refused is free. An equal search (same query, country, lang, freshness and domains) within an hour of a finished one comes from cache with no charge for the results page. Scraped pages are charged, cached or not. Timing: it waits for the results. If a search outlasts the connection's time limit, a job comes back for get_job; a scraping search whose pages are still landing returns its results with a job for the pages. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | A language code for the results, e.g. 'en'; omit for the default. | |
| limit | No | How many results to return, 1 to 10 (default 10). | |
| query | Yes | What to search the web for, 1 to 400 characters, as it would be typed into a search engine. | |
| scrape | No | true also fetches each result's page as markdown; each page costs credits. false (default) returns the results only. | |
| country | No | A 2-letter country code to search from, e.g. 'us' or 'de'; omit for the default. | |
| freshness | No | Only results from the last hour, day, week, month or year; omit for any time. | |
| exclude_domains | No | Up to 20 sites to leave out of the results, e.g. ['pinterest.com']; an exclude wins over an include. | |
| include_domains | No | Up to 20 sites to search within, e.g. ['python.org']; omit for the whole web. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The search's id: for get_job with kind 'search'. |
| job | No | While it is still going: {kind: 'search', id} for get_job. A scraping search can carry its results and a job for the pages still landing. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| note | No | The cache rule, and what to do next when it is still going. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| query | No | The query as searched. |
| cached | No | true when an equal search within the hour answered it, with no charge for the results page. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| engine | No | The engine whose results page answered, e.g. 'google' or 'bing'. |
| status | No | 'done'; 'blocked' when every engine refused the results page (nothing charged); 'running' with a `job` while it goes on. On an error, the HTTP status code. |
| results | No | Up to 10, as ranked, each {position, title, url, snippet, source, engine}; when scraped also `page`, {url, title, words, status, links (a count), markdown excerpt}, the excerpts sharing 60,000 characters. |
| attempts | No | Blocked only: each engine tried, and why it was refused. |
| creditsUsed | No | Credits this search spent, scraped pages included. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint=false, openWorldHint=true, destructiveHint=false, but the description adds substantial behavior beyond them: engine fallback order (Google then Bing), per-engine credit costs, free-refused-page rule, one-hour cache semantics, scraped-page charging, job/timeout behavior, and an explicit write-access requirement with the 'read_only' refusal code. This is unusually rich disclosure for a network-bound tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured into Inputs / Cost / Timing / Access blocks with the core purpose front-loaded. Every sentence carries operational information, though the cost and caching detail is long enough that it slightly overshoots what a routing decision needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need no explanation, and the description instead covers the things structured fields cannot: engine fallback, cost model, job handoff for long searches, and auth requirements. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: example query syntax, that scrape=true fetches pages in the same call, that include/exclude_domains take up to 20 sites, and that an exclude wins over an include. It does not cover lang, country, freshness, or limit (those rest entirely on the schema), which keeps it off a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Search the web for a query') and immediately describes the shape of the return (ranked results with title, url, snippet). It explicitly distinguishes itself from list_pages and scrape_urls by name, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives when-to-use ('find pages whose URLs you do not know'), when-not ('for URLs you already have use scrape_urls'), and names the sibling alternatives with the condition that selects each. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_runStart a project run nowAInspect
Crawl a project's site now with its saved settings, or re-read only the pages you list. The run is compared with the one before it. Use it after create_project or update_project, or whenever fresh results are wanted. For a site with no project use crawl_site. Inputs: project_id from list_projects. urls=['/pricing'] re-reads just those pages, resolved against the project's site, and compares them with the last full run; a URL on another site is refused before anything runs. wait=true returns the finished run instead of the queued one. Cost: 1 to 4 credits per page. A run that uses up the credit budget stops and keeps what it read. Refusals: 409 while another run is queued or running (stop it with cancel_job), and 402 with no credits left. Timing: with wait=true, a run that outlasts the connection's time limit comes back as a job for get_job. Read the results with list_pages and get_changes. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | Up to 500 pages of the project's site to re-read, as full URLs or paths; omit to crawl the whole site. | |
| wait | No | true waits for the run to finish (minutes for a large site); false (default) returns as soon as it is queued. | |
| project_id | Yes | The project's 32-character hex id, from list_projects. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The run's id: for get_job, cancel_job and the run_id of list_pages and get_changes. |
| job | No | When the wait ran out first: {kind: 'run', id, project_id} for get_job and cancel_job. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| note | No | What to do next when it is still going. |
| stop | No | Why it ended, e.g. the credit budget; empty while running. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| scope | No | How many URLs a start_run with urls listed; 0 for a full run. |
| counts | No | Pages by outcome, e.g. {ok, blocked, error}. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| pagesN | No | Pages read so far. |
| queued | No | true while it waits for a worker. |
| status | No | running, complete, partial (some pages refused), failed or cancelled. On an error, the HTTP status code. |
| trigger | No | manual, scheduled, api or recrawl. |
| changedN | No | Pages added, modified or removed against the run before; null until compared. |
| coverage | No | Percent of the known site this run reached. |
| startedAt | No | When it started (ISO 8601). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing cost (1-4 credits/page), budget-exhaustion behavior, specific refusal codes (409 for concurrent runs, 402 for no credits), the read_only rejection, and timing/timeout behavior with wait=true. This is exactly the operational context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then organizes the rest under labeled sections (Inputs, Cost, Refusals, Timing) so an agent can scan to the relevant behavior. Despite its length, each sentence carries distinct, decision-relevant information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-idempotent, credit-consuming crawl trigger, it covers cost, failure modes, auth requirements, and result retrieval (list_pages/get_changes). An output schema exists, so return-value detail is correctly left out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description adds real meaning on top — urls are resolved against the project's site, compared with the last full run, and a foreign-site URL is refused pre-run, while wait=true returns the finished run instead of the queued one. This enriches the schema's terse field docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: 'Crawl a project's site now with its saved settings, or re-read only the pages you list.' It explicitly names the sibling it is not ('For a site with no project use crawl_site'), so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use triggers ('after create_project or update_project, or whenever fresh results are wanted') and names the alternative (crawl_site) with its selecting condition. Preconditions like needing write access are also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_projectUpdate a project's settingsADestructiveInspect
Change a project's name, schedule or settings, its webhook among them, and send the webhook a test. Call get_project first to see the current values. To crawl with the new settings now, follow with start_run. A project's site cannot change: to watch another site use create_project. Inputs: project_id from list_projects. Only what you pass changes, and in config only the keys given, so config={"max_pages": 200} leaves every other setting alone. schedule='manual' stops scheduled runs. Valid keys come from get_project with no project_id. A webhook is config={"webhook_url": "https://example.com/hook", "webhook_events": ["run.finished", "page.changed"]}; webhook_url="" turns it off. test_webhook=true then queues a test run.finished message, and get_project shows whether it was delivered. Effect: it answers with the updated project. Nothing is fetched and no credits are spent. A replaced value is gone, not versioned. Changing how markdown is produced (e.g. only_main_content, include_tags, exclude_tags) makes the next run a new baseline, recorded rather than compared. Needs write access; a read-only connection is refused with code 'read_only'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A new name; omit to leave it. | |
| config | No | Settings to change as {key: value}; omit to leave them all. | |
| schedule | No | A new schedule; omit to leave it. | |
| project_id | Yes | The project's 32-character hex id, from list_projects. | |
| test_webhook | No | true sends a test run.finished message to the project's webhook URL, after any changes; the URL must be saved. Default false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | The project's 32-character hex id. |
| code | No | Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found. |
| host | No | The site it covers; fixed at creation. |
| name | No | Its display name. |
| note | No | No project_id only: how path globs work. |
| seed | No | Where its crawls start. |
| error | No | Only when the call failed: what went wrong, in words an assistant can act on. |
| config | No | Its settings as {key: value}; secrets such as chat_url come back masked. |
| detail | No | Only on a failure: the API's own wording, when the error was rephrased. |
| pagesN | No | Pages its last finished run read. |
| status | No | draft, crawling, healthy or failing. On an error, the HTTP status code. |
| coverage | No | Percent of the site the last run reached; under 90 means removals are withheld. |
| settings | No | No project_id only: every common setting as {key, meaning, default}. |
| webhooks | No | get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included. |
| lastRunAt | No | When the last run started (ISO 8601), or null. |
| nextRunAt | No | When the schedule runs it next, or null for manual. |
| retention | No | How long runs are kept, e.g. '90d'. |
| schedules | No | No project_id only: the valid schedules. |
| other_keys | No | No project_id only: further keys accepted but rarely needed. |
| scheduleKey | No | manual, hourly, daily or weekly. |
| webhookTest | No | update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved. |
| changeSummary | No | The last compared run in words, e.g. '3 new · 2 changed · 0 removed'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (destructiveHint=true, idempotentHint=false), and the description adds meaningful behavior beyond them: partial-merge semantics ('only what you pass changes... config={"max_pages": 200} leaves every other setting alone'), schedule='manual' stopping runs, replaced values not being versioned, markdown-affecting keys resetting the baseline, and the write-access/'read_only' refusal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is long, but dense and well-labeled with 'Inputs:', 'Effect:', and the closing access note, all front-loaded around the modify semantics. Almost every sentence carries non-obvious information, with only minor overlap with the schema's own parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent mutation tool with an output schema, the description covers prerequisites (get_project), side effects (baseline reset, unversioned replacement), permissions and error code, and follow-up actions. Nothing an agent needs before invoking it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining that config is a shallow key-level merge, that webhook_url="" disables the webhook, that schedule='manual' stops runs, and how test_webhook is sequenced after changes. Useful additions, though project_id's sourcing merely restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Change a project's name, schedule or settings, its webhook among them') and explicitly distinguishes siblings: create_project for another site, get_project for reading values, start_run to crawl. An agent can route to this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing: 'Call get_project first to see the current values,' 'to crawl with the new settings now, follow with start_run,' and 'to watch another site use create_project.' It also names the exclusion (a project's site cannot change) and where valid config keys come from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
11 tool updates
- Changed
create_project3 fields changed- changed
Output schema / descriptionPrevious value: -"A project, or with no project_id the settings any project can take."New value: +"A project, as get_project, create_project and update_project answer with it; get_project with no\nproject_id answers with the settings any project can take instead." - added
Output schema / properties / webhookTestAdded value: +{ + "description": "update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved.", + "title": "Webhooktest" +} - added
Output schema / properties / webhooksAdded value: +{ + "description": "get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included.", + "title": "Webhooks" +}
- Changed
get_changes2 fields changed- added
Input schema / properties / againstAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Another run's id, from list_runs, to compare with directly; omit to compare with the run just before.", + "title": "Against" +} - changed
Output schema / descriptionPrevious value: -"A run's change record against the run before it."New value: +"A run's change record against the run before it, or against the run named in `against`."
- Changed
get_job3 fields changed- changed
Input schema / properties / kind / descriptionPrevious value: -"'crawl' (crawl_site), 'run' (start_run), 'batch' (scrape_urls with several URLs) or 'search' (web_search)."New value: +"'crawl' (crawl_site), 'run' (start_run), 'batch' (scrape_urls with several URLs) or 'search' (search_web)." - changed
Output schema / descriptionPrevious value: -"A job's state, or its result once finished: a crawl gives crawl_site's answer, a batch scrape_urls',\na search web_search's, a run the run record, and `url` one page in full."New value: +"A job's state, or its result once finished: a crawl gives crawl_site's answer, a batch scrape_urls',\na search search_web's, a run the run record, and `url` one page in full." - changed
Output schema / properties / results / descriptionPrevious value: -"A search: the ranked results, as web_search returns them, with page excerpts when it scraped."New value: +"A search: the ranked results, as search_web returns them, with page excerpts when it scraped."
- Removed
get_page - Changed
get_project3 fields changed- changed
Output schema / descriptionPrevious value: -"A project, or with no project_id the settings any project can take."New value: +"A project, as get_project, create_project and update_project answer with it; get_project with no\nproject_id answers with the settings any project can take instead." - added
Output schema / properties / webhookTestAdded value: +{ + "description": "update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved.", + "title": "Webhooktest" +} - added
Output schema / properties / webhooksAdded value: +{ + "description": "get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included.", + "title": "Webhooks" +}
- Changed
list_pages18 fields changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from list_runs; empty means the project's latest finished run."New value: +"A run's id, from list_runs; empty means the latest finished run, or with url the newest copy across the project's last 50 runs." - added
Input schema / properties / urlAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "One page's full URL, as a listing shows it, to read that page in full; omit to list.", + "title": "Url" +} - changed
Output schema / descriptionPrevious value: -"A run's pages, or with q the pages that match."New value: +"A run's pages; with q the pages that match; with url one page in full." - added
Output schema / properties / cleanHtmlAdded value: +{ + "description": "With url: simplified html, when kept.", + "title": "Cleanhtml" +} - added
Output schema / properties / crawledAtAdded value: +{ + "description": "With url: when this copy was read (ISO 8601).", + "title": "Crawledat" +} - added
Output schema / properties / fieldsAdded value: +{ + "description": "With url: fields the project's json_schema extracted, or null.", + "title": "Fields" +} - added
Output schema / properties / headAdded value: +{ + "description": "With url: {title, description, canonical, h1, ...}.", + "title": "Head" +} - added
Output schema / properties / htmlAdded value: +{ + "description": "With url: the raw html, when the run kept it.", + "title": "Html" +} - changed
Output schema / properties / linkGraph / descriptionPrevious value: -"Without q: the run's link-graph summary (orphans, unlisted pages, dead ends), or null."New value: +"Listing: the run's link-graph summary (orphans, unlisted pages, dead ends), or null." - added
Output schema / properties / markdownAdded value: +{ + "description": "With url: its main content as markdown, capped at 12,000 characters.", + "title": "Markdown" +} - added
Output schema / properties / pageStatusAdded value: +{ + "description": "With url: ok, blocked, captcha, missing (404/410), timeout, redirect, robots or skipped.", + "title": "Pagestatus" +} - changed
Output schema / properties / pages / descriptionPrevious value: -"Without q: up to 500 rows, shallowest first, each {url, path, status, depth, words, changed, title, crawledAt}."New value: +"Listing: up to 500 rows, shallowest first, each {url, path, status, depth, words, changed, title, crawledAt}." - changed
Output schema / properties / runId / descriptionPrevious value: -"The run these pages are from; null when the project has no finished run."New value: +"The run these pages are from (with url, the run this copy is from); null when the project has no finished run." - changed
Output schema / properties / status / descriptionPrevious value: -"Only on a failure: the HTTP status code."New value: +"With url: the HTTP status the site answered. On an error, the API's status code." - added
Output schema / properties / textAdded value: +{ + "description": "With url: plain text, when kept.", + "title": "Text" +} - added
Output schema / properties / urlAdded value: +{ + "description": "With url: the page's URL as stored.", + "title": "Url" +} - added
Output schema / properties / versionsAdded value: +{ + "description": "With url: every stored copy across runs, newest first, each {runId, crawledAt, contentHash, words, status}; a changed contentHash is a changed page.", + "title": "Versions" +} - added
Output schema / properties / wordsAdded value: +{ + "description": "With url: words in its markdown.", + "title": "Words" +}
- Changed
list_projects1 field changed- added
Output schema / properties / workspaceAdded value: +{ + "description": "{plan, creditsLeft, creditsSpentThisMonth, oneTimeAllowance}: creditsLeft is what may still be spent, this month or, on a one-time allowance, ever; null means no limit. {note} instead when the balance could not be read.", + "title": "Workspace" +}
- Added
search_web - Changed
start_run1 field changed- changed
Output schema / properties / id / descriptionPrevious value: -"The run's id: for get_job, cancel_job and the run_id of list_pages, get_page and get_changes."New value: +"The run's id: for get_job, cancel_job and the run_id of list_pages and get_changes."
- Changed
update_project4 fields changed- added
Input schema / properties / test_webhookAdded value: +{ + "default": false, + "description": "true sends a test run.finished message to the project's webhook URL, after any changes; the URL must be saved. Default false.", + "title": "Test Webhook", + "type": "boolean" +} - changed
Output schema / descriptionPrevious value: -"A project, or with no project_id the settings any project can take."New value: +"A project, as get_project, create_project and update_project answer with it; get_project with no\nproject_id answers with the settings any project can take instead." - added
Output schema / properties / webhookTestAdded value: +{ + "description": "update_project with test_webhook only: {queued, id} when a test run.finished message was queued, or {error, status} when the API refused it, e.g. with no webhook URL saved.", + "title": "Webhooktest" +} - added
Output schema / properties / webhooksAdded value: +{ + "description": "get_project only: {url, events, deliveries}: where run and change events are POSTed, which events, and the last 10 deliveries, each {id, event, status (queued, retrying, delivered or failed), attempts, lastStatus, lastError, createdAt, deliveredAt}. The signing secret is never included.", + "title": "Webhooks" +}
- Removed
web_search
2 tool updates
- Changed
get_job5 fields changed- changed
Input schema / properties / kind / descriptionPrevious value: -"'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs)."New value: +"'crawl' (crawl_site), 'run' (start_run), 'batch' (scrape_urls with several URLs) or 'search' (web_search)." - changed
Input schema / properties / kind / enumPrevious value: -[ - "crawl", - "run", - "batch" -]New value: +[ + "crawl", + "run", + "batch", + "search" +] - changed
Output schema / descriptionPrevious value: -"A job's state, or its result once finished: a crawl gives crawl_site's answer, a batch scrape_urls',\na run the run record, and `url` one page in full."New value: +"A job's state, or its result once finished: a crawl gives crawl_site's answer, a batch scrape_urls',\na search web_search's, a run the run record, and `url` one page in full." - changed
Output schema / properties / id / descriptionPrevious value: -"A run: its id."New value: +"A run or a search: its id." - added
Output schema / properties / resultsAdded value: +{ + "description": "A search: the ranked results, as web_search returns them, with page excerpts when it scraped.", + "title": "Results" +}
- Added
web_search
20 tool updates
- Changed
cancel_job4 fields changed- changed
Input schema / properties / id / descriptionPrevious value: -"The job's id, from that 'job' object, or a crawl_site answer's crawl_id."New value: +"The job's id." - changed
Input schema / properties / kind / descriptionPrevious value: -"What the job is: 'crawl' (crawl_site), 'run' (start_run, recrawl_pages) or 'batch' (scrape_urls); the 'job' object a tool returned names it."New value: +"'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs)." - changed
Input schema / properties / project_id / descriptionPrevious value: -"Required for a run: the project it belongs to (the 'job' object carries it). Ignored for a crawl or a batch."New value: +"A run's project id; required for a run, ignored otherwise." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "What a cancel did.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "id": { + "description": "The job's id.", + "title": "Id" + }, + "kind": { + "description": "crawl, run or batch.", + "title": "Kind" + }, + "note": { + "description": "What a stop keeps and drops.", + "title": "Note" + }, + "outcome": { + "description": "'cancelled' (it had not started), 'cancelling' (it stops after the page in hand), or the status of a job that had already ended.", + "title": "Outcome" + }, + "project_id": { + "description": "A run: its project.", + "title": "Project Id" + }, + "status": { + "description": "Only on a failure: the HTTP status code.", + "title": "Status" + } + }, + "title": "CancelOut", + "type": "object" +}
- Changed
crawl_site4 fields changed- changed
Input schema / properties / config / descriptionPrevious value: -"Optional fetch settings: any subset of the keys describe_project_config lists, e.g. {\"render_js\": \"always\", \"only_main_content\": true}. Omit for the defaults."New value: +"Fetch settings to override, as {key: value}; omit for the defaults." - changed
Input schema / properties / include_paths / descriptionPrevious value: -"Globs over the URL path to keep, e.g. ['/blog/*'] for a section (its index included); a bare '/blog/' matches only that one page. Omit for the whole site."New value: +"Globs over the URL path to keep; a bare '/blog/' matches that one page only. Omit for the whole site." - changed
Input schema / properties / max_depth / descriptionPrevious value: -"How many links deep to follow from the start URL (0 = that page only; default 3)."New value: +"Link hops to follow from the start URL (0 = that page only; default 3)." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A crawl: the pages read, as an index plus excerpts, or a job when it is still going.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "counts": { + "description": "Pages by outcome, e.g. {ok, blocked, error}.", + "title": "Counts" + }, + "crawl_id": { + "description": "This crawl's id: for get_job, cancel_job, and create_project(crawl_id=...) to keep it.", + "title": "Crawl Id" + }, + "cursor": { + "description": "Present when more pages exist: pass it to get_job for the next window.", + "title": "Cursor" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "index": { + "description": "Every page read (up to 500) as {url, title, words, status}.", + "title": "Index" + }, + "job": { + "description": "While it is still going: {kind: 'crawl', id} for get_job and cancel_job.", + "title": "Job" + }, + "note": { + "description": "What was cut, and how to read a page in full.", + "title": "Note" + }, + "pages": { + "description": "Up to 50 pages, each {url, title, words, status, links (a count), markdown excerpt}.", + "title": "Pages" + }, + "status": { + "description": "'done', 'cancelled' or 'error' once finished, 'running' with a `job` while it goes on. On an error, the HTTP status code.", + "title": "Status" + }, + "stop": { + "description": "Why the crawl ended early, e.g. its page limit; empty otherwise.", + "title": "Stop" + }, + "url": { + "description": "The start URL.", + "title": "Url" + } + }, + "title": "CrawlOut", + "type": "object" +}
- Changed
create_project9 fields changed- changed
Input schema / properties / config / descriptionPrevious value: -"Any subset of the settings describe_project_config lists. For one section of a site pass include_paths, e.g. {\"include_paths\": [\"/blog/*\"]}; map_site shows the site's sections first. Omit for the defaults."New value: +"Settings as {key: value}, with a seed only; omit for the defaults." - added
Input schema / properties / crawl_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "A crawl_site answer's crawl_id, to keep that crawl as the project. Give this or seed.", + "title": "Crawl Id" +} - changed
Input schema / properties / name / descriptionPrevious value: -"A name for the project; omit to use the site's host name."New value: +"A display name; omit for the site's host (or the crawl's own name)." - added
Input schema / properties / seed / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / seed / defaultAdded value: +null - changed
Input schema / properties / seed / descriptionPrevious value: -"Where the crawl starts: a public site's URL or bare domain, e.g. 'https://example.com/blog/' or 'example.com'. The project covers that host."New value: +"The site to watch, as a URL or bare domain, e.g. 'https://example.com/blog/' or 'example.com'; its host is fixed for good. Give this or crawl_id." - removed
Input schema / properties / seed / typeRemoved value: -"string" - removed
Input schema / requiredRemoved value: -[ - "seed" -] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A project, or with no project_id the settings any project can take.", + "properties": { + "changeSummary": { + "description": "The last compared run in words, e.g. '3 new · 2 changed · 0 removed'.", + "title": "Changesummary" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "config": { + "description": "Its settings as {key: value}; secrets such as chat_url come back masked.", + "title": "Config" + }, + "coverage": { + "description": "Percent of the site the last run reached; under 90 means removals are withheld.", + "title": "Coverage" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "host": { + "description": "The site it covers; fixed at creation.", + "title": "Host" + }, + "id": { + "description": "The project's 32-character hex id.", + "title": "Id" + }, + "lastRunAt": { + "description": "When the last run started (ISO 8601), or null.", + "title": "Lastrunat" + }, + "name": { + "description": "Its display name.", + "title": "Name" + }, + "nextRunAt": { + "description": "When the schedule runs it next, or null for manual.", + "title": "Nextrunat" + }, + "note": { + "description": "No project_id only: how path globs work.", + "title": "Note" + }, + "other_keys": { + "description": "No project_id only: further keys accepted but rarely needed.", + "title": "Other Keys" + }, + "pagesN": { + "description": "Pages its last finished run read.", + "title": "Pagesn" + }, + "retention": { + "description": "How long runs are kept, e.g. '90d'.", + "title": "Retention" + }, + "scheduleKey": { + "description": "manual, hourly, daily or weekly.", + "title": "Schedulekey" + }, + "schedules": { + "description": "No project_id only: the valid schedules.", + "title": "Schedules" + }, + "seed": { + "description": "Where its crawls start.", + "title": "Seed" + }, + "settings": { + "description": "No project_id only: every common setting as {key, meaning, default}.", + "title": "Settings" + }, + "status": { + "description": "draft, crawling, healthy or failing. On an error, the HTTP status code.", + "title": "Status" + } + }, + "title": "ProjectOut", + "type": "object" +}
- Added
delete_project - Removed
describe_project_config - Removed
extract_url - Changed
get_changes3 fields changed- changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from list_runs, start_run or the runId a list_pages answer carries; leave empty for the last finished run."New value: +"A run's id, from list_runs; empty means the project's latest finished run." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A run's change record against the run before it.", + "properties": { + "change": { + "description": "{runId, prevRunId, baseline, rebaselined, coverage, degraded, counts {added, modified, removed}, summary, feed, fields, withheld}. feed: each changed page as {url, path, kind (added, modified or removed), added and removed (words, e.g. '+12'), wordsBefore, wordsAfter}. fields: head and extracted field changes as {url, field, before, after}. withheld: removals held back because coverage was under 90%. Each list holds up to 200.", + "title": "Change" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "runs": { + "description": "The finished runs a record exists for, newest first, for picking another run_id.", + "title": "Runs" + }, + "status": { + "description": "Only on a failure: the HTTP status code.", + "title": "Status" + } + }, + "title": "ChangesOut", + "type": "object" +}
- Changed
get_job6 fields changed- changed
Input schema / properties / cursor / descriptionPrevious value: -"Crawls only: the cursor a previous crawl answer returned, to read the next window of pages."New value: +"Crawls only: the cursor the previous answer returned." - changed
Input schema / properties / id / descriptionPrevious value: -"The job's id, from that 'job' object, or a crawl_site answer's crawl_id."New value: +"The job's id." - changed
Input schema / properties / kind / descriptionPrevious value: -"What the job is: 'crawl' (crawl_site), 'run' (start_run, recrawl_pages) or 'batch' (scrape_urls); the 'job' object a tool returned names it."New value: +"'crawl' (crawl_site), 'run' (start_run) or 'batch' (scrape_urls with several URLs)." - changed
Input schema / properties / project_id / descriptionPrevious value: -"Required for a run: the project it belongs to (the 'job' object carries it). Ignored for a crawl or a batch."New value: +"A run's project id; required for a run, ignored otherwise." - changed
Input schema / properties / url / descriptionPrevious value: -"Crawls only: one page's URL from the crawl's index, to read that page in full."New value: +"Crawls only: one page's URL from the crawl's index." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A job's state, or its result once finished: a crawl gives crawl_site's answer, a batch scrape_urls',\na run the run record, and `url` one page in full.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "counts": { + "description": "Pages by outcome so far.", + "title": "Counts" + }, + "crawl_id": { + "description": "A crawl: its id.", + "title": "Crawl Id" + }, + "cursor": { + "description": "A crawl with more pages: pass it back for the next window.", + "title": "Cursor" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "id": { + "description": "A run: its id.", + "title": "Id" + }, + "index": { + "description": "A finished crawl or batch: every page as {url, title, words, status}.", + "title": "Index" + }, + "job": { + "description": "While running: {kind, id, project_id} to call again with.", + "title": "Job" + }, + "markdown": { + "description": "With url: that page's markdown, capped at 12,000 characters.", + "title": "Markdown" + }, + "note": { + "description": "What to do next.", + "title": "Note" + }, + "pages": { + "description": "A finished crawl or batch: pages with excerpts.", + "title": "Pages" + }, + "status": { + "description": "'running' while it goes on; otherwise the finished job's status. On an error, the HTTP status code.", + "title": "Status" + } + }, + "title": "JobOut", + "type": "object" +}
- Changed
get_page4 fields changed- changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from list_runs or start_run, to read that run's copy; leave empty for the newest copy across the project's recent runs."New value: +"A run's id, to read that run's copy; empty means the newest copy across the project's last 50 runs." - changed
Input schema / properties / url / descriptionPrevious value: -"The page's full URL as list_pages or search_pages shows it; the other scheme or trailing slash is matched too."New value: +"The page's full URL, as list_pages shows it." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "One stored page in full.", + "properties": { + "cleanHtml": { + "description": "Simplified html, when kept.", + "title": "Cleanhtml" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "crawledAt": { + "description": "When this copy was read (ISO 8601).", + "title": "Crawledat" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "fields": { + "description": "Fields the project's json_schema extracted, or null.", + "title": "Fields" + }, + "head": { + "description": "{title, description, canonical, h1, ...}.", + "title": "Head" + }, + "html": { + "description": "The raw html, when the run kept it.", + "title": "Html" + }, + "markdown": { + "description": "Its main content as markdown, capped at 12,000 characters.", + "title": "Markdown" + }, + "pageStatus": { + "description": "ok, blocked, captcha, missing (404/410), timeout, redirect, robots or skipped.", + "title": "Pagestatus" + }, + "runId": { + "description": "The run this copy is from.", + "title": "Runid" + }, + "status": { + "description": "The HTTP status the site answered; on an error, the API's status code.", + "title": "Status" + }, + "text": { + "description": "Plain text, when kept.", + "title": "Text" + }, + "url": { + "description": "The page's URL as stored.", + "title": "Url" + }, + "versions": { + "description": "Every stored copy across runs, newest first, each {runId, crawledAt, contentHash, words, status}; a changed contentHash is a changed page.", + "title": "Versions" + }, + "words": { + "description": "Words in its markdown.", + "title": "Words" + } + }, + "title": "PageOut", + "type": "object" +}
- Changed
get_project6 fields changed- added
Input schema / properties / project_id / anyOfAdded value: +[ + { + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / project_id / defaultAdded value: +null - changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects; omit for the settings reference." - removed
Input schema / properties / project_id / typeRemoved value: -"string" - removed
Input schema / requiredRemoved value: -[ - "project_id" -] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A project, or with no project_id the settings any project can take.", + "properties": { + "changeSummary": { + "description": "The last compared run in words, e.g. '3 new · 2 changed · 0 removed'.", + "title": "Changesummary" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "config": { + "description": "Its settings as {key: value}; secrets such as chat_url come back masked.", + "title": "Config" + }, + "coverage": { + "description": "Percent of the site the last run reached; under 90 means removals are withheld.", + "title": "Coverage" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "host": { + "description": "The site it covers; fixed at creation.", + "title": "Host" + }, + "id": { + "description": "The project's 32-character hex id.", + "title": "Id" + }, + "lastRunAt": { + "description": "When the last run started (ISO 8601), or null.", + "title": "Lastrunat" + }, + "name": { + "description": "Its display name.", + "title": "Name" + }, + "nextRunAt": { + "description": "When the schedule runs it next, or null for manual.", + "title": "Nextrunat" + }, + "note": { + "description": "No project_id only: how path globs work.", + "title": "Note" + }, + "other_keys": { + "description": "No project_id only: further keys accepted but rarely needed.", + "title": "Other Keys" + }, + "pagesN": { + "description": "Pages its last finished run read.", + "title": "Pagesn" + }, + "retention": { + "description": "How long runs are kept, e.g. '90d'.", + "title": "Retention" + }, + "scheduleKey": { + "description": "manual, hourly, daily or weekly.", + "title": "Schedulekey" + }, + "schedules": { + "description": "No project_id only: the valid schedules.", + "title": "Schedules" + }, + "seed": { + "description": "Where its crawls start.", + "title": "Seed" + }, + "settings": { + "description": "No project_id only: every common setting as {key, meaning, default}.", + "title": "Settings" + }, + "status": { + "description": "draft, crawling, healthy or failing. On an error, the HTTP status code.", + "title": "Status" + } + }, + "title": "ProjectOut", + "type": "object" +}
- Removed
keep_crawl_as_project - Changed
list_pages5 fields changed- added
Input schema / properties / modeAdded value: +{ + "default": "content", + "description": "With q: 'content' (default) searches the markdown, 'selector' the stored html.", + "enum": [ + "content", + "selector" + ], + "title": "Mode", + "type": "string" +} - changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - added
Input schema / properties / qAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Text to find, 1 to 200 characters: words or a \"quoted phrase\", or with mode='selector' a CSS selector or an XPath starting with / or (. Omit to list every page.", + "title": "Q" +} - changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from list_runs, start_run or the runId a list_pages answer carries; leave empty for the last finished run."New value: +"A run's id, from list_runs; empty means the project's latest finished run." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A run's pages, or with q the pages that match.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "hits": { + "description": "With q: up to 500 matches, each {url, count (matches on the page), snippet}.", + "title": "Hits" + }, + "linkGraph": { + "description": "Without q: the run's link-graph summary (orphans, unlisted pages, dead ends), or null.", + "title": "Linkgraph" + }, + "noBody": { + "description": "With q: pages skipped because the body the mode needs was not kept (rawHtml for selector).", + "title": "Nobody" + }, + "pages": { + "description": "Without q: up to 500 rows, shallowest first, each {url, path, status, depth, words, changed, title, crawledAt}.", + "title": "Pages" + }, + "runId": { + "description": "The run these pages are from; null when the project has no finished run.", + "title": "Runid" + }, + "scanned": { + "description": "With q: pages searched.", + "title": "Scanned" + }, + "status": { + "description": "Only on a failure: the HTTP status code.", + "title": "Status" + }, + "truncated": { + "description": "With q: true when more pages matched than are listed.", + "title": "Truncated" + } + }, + "title": "PagesOut", + "type": "object" +}
- Changed
list_projects10 fields changed- added
Output schema / additionalPropertiesAdded value: +true - added
Output schema / descriptionAdded value: +"Every project the key can see." - added
Output schema / properties / codeAdded value: +{ + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" +} - added
Output schema / properties / detailAdded value: +{ + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" +} - added
Output schema / properties / errorAdded value: +{ + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" +} - added
Output schema / properties / projectsAdded value: +{ + "description": "Oldest first, each {id, name, seed, host, schedule, pages, coverage, lastRun, status}; status is draft, crawling, healthy or failing.", + "title": "Projects" +} - removed
Output schema / properties / resultRemoved value: -{ - "anyOf": [ - { - "items": {}, - "type": "array" - }, - { - "additionalProperties": true, - "type": "object" - } - ], - "title": "Result" -} - added
Output schema / properties / statusAdded value: +{ + "description": "Only on a failure: the HTTP status code.", + "title": "Status" +} - removed
Output schema / requiredRemoved value: -[ - "result" -] - changed
Output schema / titlePrevious value: -"list_projectsOutput"New value: +"ProjectsOut"
- Changed
list_runs3 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"How many runs to return, newest first: 1 to 100 (default 25)."New value: +"How many runs to return, 1 to 100 (default 25)." - changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A project's runs, newest first.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "runs": { + "description": "Each {id, status, trigger, scope, pagesN, changedN, counts, coverage, stop, startedAt, elapsed, baseline, rebaselined}; baseline is a first run with nothing to compare, rebaselined one whose settings changed how pages read, so it was recorded rather than compared.", + "title": "Runs" + }, + "status": { + "description": "Only on a failure: the HTTP status code.", + "title": "Status" + } + }, + "title": "RunsOut", + "type": "object" +}
- Changed
map_site3 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"The most URLs to return, 1 to 5,000 (default 1,000); totals still count them all."New value: +"The most URLs to return, 1 to 5,000 (default 1,000); totals count them all." - changed
Input schema / properties / search / descriptionPrevious value: -"Keep only URLs containing this text, e.g. '/blog/'; omit for all."New value: +"Keep only URLs containing this text; omit for all." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "The URLs a site's sitemaps declare.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "method": { + "description": "How the sitemaps were found, e.g. through robots.txt.", + "title": "Method" + }, + "sections": { + "description": "The section names the sitemaps group URLs under, e.g. 'blog'; empty when there are none.", + "title": "Sections" + }, + "status": { + "description": "Only on a failure: the HTTP status code.", + "title": "Status" + }, + "totals": { + "description": "Counts over every declared URL and sitemap file, whatever `limit` returned.", + "title": "Totals" + }, + "url": { + "description": "The site that was mapped.", + "title": "Url" + }, + "urls": { + "description": "The declared URLs, at most `limit`, filtered by `search`.", + "title": "Urls" + } + }, + "title": "MapOut", + "type": "object" +}
- Removed
recrawl_pages - Changed
scrape_urls6 fields changed- changed
Input schema / properties / config / descriptionPrevious value: -"Optional fetch settings: any subset of the keys describe_project_config lists, e.g. {\"render_js\": \"always\", \"only_main_content\": true}. Omit for the defaults."New value: +"Fetch settings to override, as {key: value}; omit for the defaults." - changed
Input schema / properties / formats / descriptionPrevious value: -"Comma-separated bodies to return per page, from markdown (default), text, cleanHtml and rawHtml, e.g. 'markdown,text'."New value: +"Bodies per page, comma-separated from markdown (default), text, cleanHtml and rawHtml. With full=true, config's formats list chooses them instead." - added
Input schema / properties / fullAdded value: +{ + "default": false, + "description": "true reads the one URL in full -- raw html, head and extracted fields, images, the engine used -- running config's browser actions first. Default false.", + "title": "Full", + "type": "boolean" +} - changed
Input schema / properties / parse_documents / descriptionPrevious value: -"Read PDFs, Word files and spreadsheets as text (default true); false leaves their text out. A parse_documents key in config wins."New value: +"Read PDF, Word and spreadsheet URLs as text (default true). A parse_documents key in config wins." - changed
Input schema / properties / urls / descriptionPrevious value: -"The pages to fetch: 1 to 500 absolute http(s) URLs."New value: +"Absolute http(s) URLs, 1 to 500; exactly one when full is true." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A scrape. A list: status, the pages with excerpts and an index of every url. One URL: that page in\nfull. full=true: the extraction, with the page under `page`. A batch still going: status 'running' and\na job.", + "properties": { + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "index": { + "description": "A list only: every url as {url, title, words, status}, so none is lost when excerpts are cut.", + "title": "Index" + }, + "job": { + "description": "While a batch is still going: {kind: 'batch', id} for get_job and cancel_job.", + "title": "Job" + }, + "note": { + "description": "What was left out and how to get it.", + "title": "Note" + }, + "page": { + "description": "full=true only: the page in full -- markdown, html, head {title, description, canonical, h1}, fields, images, engine, pageStatus -- with each body capped at 12,000 characters.", + "title": "Page" + }, + "pages": { + "description": "The pages read. A list: up to 50, each {url, title, words, status, links (a count), markdown excerpt}, the excerpts sharing 60,000 characters. One URL: that page in full, each body asked for capped at 12,000 characters.", + "title": "Pages" + }, + "rest": { + "description": "A list past its index: {count, byStatus, notOk} for the urls not shown.", + "title": "Rest" + }, + "status": { + "description": "'done' once read; 'running' with a `job` while a batch goes on; with full=true, 'blocked' when the site refused and 'error' when the read failed. On an error, the HTTP status code.", + "title": "Status" + } + }, + "title": "ScrapeOut", + "type": "object" +}
- Removed
search_pages - Changed
start_run3 fields changed- changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - added
Input schema / properties / urlsAdded value: +{ + "anyOf": [ + { + "items": { + "type": "string" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Up to 500 pages of the project's site to re-read, as full URLs or paths; omit to crawl the whole site.", + "title": "Urls" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A run of a project, or a job when a wait ran out first.", + "properties": { + "changedN": { + "description": "Pages added, modified or removed against the run before; null until compared.", + "title": "Changedn" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "counts": { + "description": "Pages by outcome, e.g. {ok, blocked, error}.", + "title": "Counts" + }, + "coverage": { + "description": "Percent of the known site this run reached.", + "title": "Coverage" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "id": { + "description": "The run's id: for get_job, cancel_job and the run_id of list_pages, get_page and get_changes.", + "title": "Id" + }, + "job": { + "description": "When the wait ran out first: {kind: 'run', id, project_id} for get_job and cancel_job.", + "title": "Job" + }, + "note": { + "description": "What to do next when it is still going.", + "title": "Note" + }, + "pagesN": { + "description": "Pages read so far.", + "title": "Pagesn" + }, + "queued": { + "description": "true while it waits for a worker.", + "title": "Queued" + }, + "scope": { + "description": "How many URLs a start_run with urls listed; 0 for a full run.", + "title": "Scope" + }, + "startedAt": { + "description": "When it started (ISO 8601).", + "title": "Startedat" + }, + "status": { + "description": "running, complete, partial (some pages refused), failed or cancelled. On an error, the HTTP status code.", + "title": "Status" + }, + "stop": { + "description": "Why it ended, e.g. the credit budget; empty while running.", + "title": "Stop" + }, + "trigger": { + "description": "manual, scheduled, api or recrawl.", + "title": "Trigger" + } + }, + "title": "RunOut", + "type": "object" +}
- Changed
update_project3 fields changed- changed
Input schema / properties / config / descriptionPrevious value: -"Settings to change, e.g. {\"max_pages\": 200}; keys not given keep their values. Omit to leave them all."New value: +"Settings to change as {key: value}; omit to leave them all." - changed
Input schema / properties / project_id / descriptionPrevious value: -"The project's id, as list_projects or create_project returns it."New value: +"The project's 32-character hex id, from list_projects." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "description": "A project, or with no project_id the settings any project can take.", + "properties": { + "changeSummary": { + "description": "The last compared run in words, e.g. '3 new · 2 changed · 0 removed'.", + "title": "Changesummary" + }, + "code": { + "description": "Only on a failure: a machine-readable reason, e.g. read_only, validation, plan_limit or not_found.", + "title": "Code" + }, + "config": { + "description": "Its settings as {key: value}; secrets such as chat_url come back masked.", + "title": "Config" + }, + "coverage": { + "description": "Percent of the site the last run reached; under 90 means removals are withheld.", + "title": "Coverage" + }, + "detail": { + "description": "Only on a failure: the API's own wording, when the error was rephrased.", + "title": "Detail" + }, + "error": { + "description": "Only when the call failed: what went wrong, in words an assistant can act on.", + "title": "Error" + }, + "host": { + "description": "The site it covers; fixed at creation.", + "title": "Host" + }, + "id": { + "description": "The project's 32-character hex id.", + "title": "Id" + }, + "lastRunAt": { + "description": "When the last run started (ISO 8601), or null.", + "title": "Lastrunat" + }, + "name": { + "description": "Its display name.", + "title": "Name" + }, + "nextRunAt": { + "description": "When the schedule runs it next, or null for manual.", + "title": "Nextrunat" + }, + "note": { + "description": "No project_id only: how path globs work.", + "title": "Note" + }, + "other_keys": { + "description": "No project_id only: further keys accepted but rarely needed.", + "title": "Other Keys" + }, + "pagesN": { + "description": "Pages its last finished run read.", + "title": "Pagesn" + }, + "retention": { + "description": "How long runs are kept, e.g. '90d'.", + "title": "Retention" + }, + "scheduleKey": { + "description": "manual, hourly, daily or weekly.", + "title": "Schedulekey" + }, + "schedules": { + "description": "No project_id only: the valid schedules.", + "title": "Schedules" + }, + "seed": { + "description": "Where its crawls start.", + "title": "Seed" + }, + "settings": { + "description": "No project_id only: every common setting as {key, meaning, default}.", + "title": "Settings" + }, + "status": { + "description": "draft, crawling, healthy or failing. On an error, the HTTP status code.", + "title": "Status" + } + }, + "title": "ProjectOut", + "type": "object" +}
6 tool updates
- Added
cancel_job - Changed
get_changes1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."New value: +"A run's id, from list_runs, start_run or the runId a list_pages answer carries; leave empty for the last finished run."
- Changed
get_page1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from start_run or a list_pages answer, to read that run's copy; leave empty for the newest copy across the project's recent runs."New value: +"A run's id, from list_runs or start_run, to read that run's copy; leave empty for the newest copy across the project's recent runs."
- Changed
list_pages1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."New value: +"A run's id, from list_runs, start_run or the runId a list_pages answer carries; leave empty for the last finished run."
- Added
list_runs - Changed
search_pages1 field changed- changed
Input schema / properties / run_id / descriptionPrevious value: -"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."New value: +"A run's id, from list_runs, start_run or the runId a list_pages answer carries; leave empty for the last finished run."
1 tool update
- Changed
recrawl_pages1 field changed- changed
Input schema / properties / urls / descriptionPrevious value: -"1 to 500 full URLs on the project's site to fetch again."New value: +"1 to 500 pages on the project's site to fetch again: full URLs, or paths such as '/pricing'."
15 tool updates
- Changed
crawl_site6 fields changed- added
Input schema / properties / config / descriptionAdded value: +"Optional fetch settings: any subset of the keys describe_project_config lists, e.g. {\"render_js\": \"always\", \"only_main_content\": true}. Omit for the defaults." - added
Input schema / properties / exclude_paths / descriptionAdded value: +"Globs over the URL path to skip, e.g. ['/tag/*', '*.pdf']; an exclude wins over an include." - added
Input schema / properties / include_paths / descriptionAdded value: +"Globs over the URL path to keep, e.g. ['/blog/*'] for a section (its index included); a bare '/blog/' matches only that one page. Omit for the whole site." - added
Input schema / properties / limit / descriptionAdded value: +"The most pages to read, 1 to 5,000 (default 50); the plan's page cap also applies." - added
Input schema / properties / max_depth / descriptionAdded value: +"How many links deep to follow from the start URL (0 = that page only; default 3)." - added
Input schema / properties / url / descriptionAdded value: +"The absolute http(s) URL to start from, e.g. the home page."
- Changed
create_project5 fields changed- added
Input schema / properties / config / descriptionAdded value: +"Any subset of the settings describe_project_config lists. For one section of a site pass include_paths, e.g. {\"include_paths\": [\"/blog/*\"]}; map_site shows the site's sections first. Omit for the defaults." - added
Input schema / properties / name / descriptionAdded value: +"A name for the project; omit to use the site's host name." - added
Input schema / properties / schedule / descriptionAdded value: +"How often it re-crawls on its own; 'manual' (default) runs only when start_run is called." - added
Input schema / properties / schedule / enumAdded value: +[ + "manual", + "hourly", + "daily", + "weekly" +] - added
Input schema / properties / seed / descriptionAdded value: +"Where the crawl starts: a public site's URL or bare domain, e.g. 'https://example.com/blog/' or 'example.com'. The project covers that host."
- Changed
extract_url3 fields changed- added
Input schema / properties / config / descriptionAdded value: +"Optional fetch settings: any subset of the keys describe_project_config lists, e.g. {\"render_js\": \"always\", \"only_main_content\": true}. Omit for the defaults." - added
Input schema / properties / parse_documents / descriptionAdded value: +"Read PDFs, Word files and spreadsheets as text (default true); false leaves their text out. A parse_documents key in config wins." - added
Input schema / properties / url / descriptionAdded value: +"The absolute http(s) URL of the page to read."
- Changed
get_changes2 fields changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / run_id / descriptionAdded value: +"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."
- Changed
get_job6 fields changed- added
Input schema / properties / cursor / descriptionAdded value: +"Crawls only: the cursor a previous crawl answer returned, to read the next window of pages." - added
Input schema / properties / id / descriptionAdded value: +"The job's id, from that 'job' object, or a crawl_site answer's crawl_id." - added
Input schema / properties / kind / descriptionAdded value: +"What the job is: 'crawl' (crawl_site), 'run' (start_run, recrawl_pages) or 'batch' (scrape_urls); the 'job' object a tool returned names it." - added
Input schema / properties / kind / enumAdded value: +[ + "crawl", + "run", + "batch" +] - added
Input schema / properties / project_id / descriptionAdded value: +"Required for a run: the project it belongs to (the 'job' object carries it). Ignored for a crawl or a batch." - added
Input schema / properties / url / descriptionAdded value: +"Crawls only: one page's URL from the crawl's index, to read that page in full."
- Changed
get_page3 fields changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / run_id / descriptionAdded value: +"A run's id, from start_run or a list_pages answer, to read that run's copy; leave empty for the newest copy across the project's recent runs." - added
Input schema / properties / url / descriptionAdded value: +"The page's full URL as list_pages or search_pages shows it; the other scheme or trailing slash is matched too."
- Changed
get_project1 field changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it."
- Changed
keep_crawl_as_project4 fields changed- added
Input schema / properties / crawl_id / descriptionAdded value: +"The crawl_id a crawl_site answer (or get_job on a crawl) returned." - added
Input schema / properties / name / descriptionAdded value: +"A name for the project; omit to keep the crawl's own name." - added
Input schema / properties / schedule / descriptionAdded value: +"How often the project re-crawls on its own; 'manual' (default) runs only when start_run is called. Every run spends credits." - added
Input schema / properties / schedule / enumAdded value: +[ + "manual", + "hourly", + "daily", + "weekly" +]
- Changed
list_pages2 fields changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / run_id / descriptionAdded value: +"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."
- Changed
map_site3 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"The most URLs to return, 1 to 5,000 (default 1,000); totals still count them all." - added
Input schema / properties / search / descriptionAdded value: +"Keep only URLs containing this text, e.g. '/blog/'; omit for all." - added
Input schema / properties / url / descriptionAdded value: +"Any URL on the site, usually its home page."
- Changed
recrawl_pages2 fields changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / urls / descriptionAdded value: +"1 to 500 full URLs on the project's site to fetch again."
- Changed
scrape_urls4 fields changed- added
Input schema / properties / config / descriptionAdded value: +"Optional fetch settings: any subset of the keys describe_project_config lists, e.g. {\"render_js\": \"always\", \"only_main_content\": true}. Omit for the defaults." - added
Input schema / properties / formats / descriptionAdded value: +"Comma-separated bodies to return per page, from markdown (default), text, cleanHtml and rawHtml, e.g. 'markdown,text'." - added
Input schema / properties / parse_documents / descriptionAdded value: +"Read PDFs, Word files and spreadsheets as text (default true); false leaves their text out. A parse_documents key in config wins." - added
Input schema / properties / urls / descriptionAdded value: +"The pages to fetch: 1 to 500 absolute http(s) URLs."
- Changed
search_pages5 fields changed- added
Input schema / properties / mode / descriptionAdded value: +"'content' (default) searches the extracted markdown; 'selector' searches the stored html." - added
Input schema / properties / mode / enumAdded value: +[ + "content", + "selector" +] - added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / q / descriptionAdded value: +"What to look for, 1 to 200 characters. In content mode every word must appear and \"quoted phrases\" match as written; in selector mode a CSS selector, or an XPath starting with / or (." - added
Input schema / properties / run_id / descriptionAdded value: +"A run's id, from start_run or the runId a list_pages answer carries; leave empty for the last finished run."
- Changed
start_run2 fields changed- added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - added
Input schema / properties / wait / descriptionAdded value: +"true waits for the run to finish (minutes for a large site); false (default) returns as soon as it is queued."
- Changed
update_project5 fields changed- added
Input schema / properties / config / descriptionAdded value: +"Settings to change, e.g. {\"max_pages\": 200}; keys not given keep their values. Omit to leave them all." - added
Input schema / properties / name / descriptionAdded value: +"A new name; omit to leave it." - added
Input schema / properties / project_id / descriptionAdded value: +"The project's id, as list_projects or create_project returns it." - changed
Input schema / properties / schedule / anyOfPrevious value: -[ - { - "type": "string" - }, - { - "type": "null" - } -]New value: +[ + { + "enum": [ + "manual", + "hourly", + "daily", + "weekly" + ], + "type": "string" + }, + { + "type": "null" + } +] - added
Input schema / properties / schedule / descriptionAdded value: +"A new schedule; omit to leave it."
17 tool updates
- First observed
crawl_site - First observed
create_project - First observed
describe_project_config - First observed
extract_url - First observed
get_changes - First observed
get_job - First observed
get_page - First observed
get_project - First observed
keep_crawl_as_project - First observed
list_pages - First observed
list_projects - First observed
map_site - First observed
recrawl_pages - First observed
scrape_urls - First observed
search_pages - First observed
start_run - First observed
update_project
Publisher details
- Operator
- MeshArc · Publisher source
- Operator website
- https://mesharc.dev
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://mesharc.dev/mcp
- Trust center
- https://mesharc.dev/legal/security
- Restrictions
- A MeshArc account is needed; fetching pages uses credits (free plan available). · Publisher source
Related MCP Connectors
Web pages and whole sites to clean Markdown for RAG and AI agents. Crawls links and sitemaps.
Web scraping to clean Markdown with JS rendering, multi-page crawl, structured extract, sitemaps.
Extract public webpages as Markdown, map sites, and run bounded crawl jobs. API key required.
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Related MCP Servers
- FlicenseNot gradedqualityAmaintenanceFetches web content locally, removes clutter, and converts pages to clean Markdown for efficient LLM consumption, with optional crawling and caching.-
- AlicenseNot gradedqualityAmaintenanceFetches webpages or crawls sites locally, strips noise, and converts content to clean Markdown while preserving links, enabling fast, token-efficient web scraping for AI agents and LLM pipelines.MIT
- AlicenseAqualityAmaintenanceAI-native web scraper: scrape, crawl and map any site to clean markdown over stdio. MIT-licensed.6152MIT
- AlicenseNot gradedqualityAmaintenanceFetches webpages and crawls sites locally, stripping noise and converting content into clean, link-preserving Markdown with a minimal token footprint. Supports configurable crawl depth, concurrency, robots.txt compliance, and caching for efficient AI agent and LLM pipelines.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.