Official Model Context Protocol (MCP) server for the WellMarked API — let AI agents convert any URL to clean Markdown, bulk-extract, and crawl sites.
WellMarked MCP demonstrates strong definition quality with comprehensive schemas, detailed parameter descriptions, and clear tool naming. All 6 tools have explicit input schemas with type definitions and descriptions. Tool names follow verb_noun convention (extract, bulk, crawl, get_job, wait_for_job, get_usage). Descriptions are well-written (100-300 chars), explaining WHAT the tool does and WHEN to use it. Shared policy parameters (allow_domains, deny_patterns, respect_robots) are well-documented with constraints. Error handling via toErrorResult() surfaces error codes, HTTP status, and retry guidance. Main gaps: output schemas are not formally documented in the code (only mentioned in comments), and some parameter descriptions could be more explicit about return value structure. The server correctly uses JSON-as-text for results rather than structuredContent, which is appropriate for LLM consumption.
Submit a batch of URLs for concurrent extraction. Returns a job that runs asynchronously. By default this blocks until the job finishes and returns all results; set wait=false to return the queued job id immediately and poll with get_job / wait_for_job. Available on every plan; the plan caps URLs per job (Free 5, Pro 50, Growth 200, Enterprise unlimited).
Crawl a site from a root URL, following links up to a depth limit and respecting robots.txt. Returns a job that runs asynchronously. By default this blocks until the job finishes and returns all results; set wait=false to return the queued job id immediately and poll with get_job / wait_for_job. Available on Pro, Growth, and Enterprise plans.
Fetch a single web page and return its main content as clean Markdown, stripped of nav, ads, and boilerplate. Use this to read an article, doc page, or any URL the user references. Returns the Markdown plus metadata (title, author, published date).
Poll a bulk or crawl job once. Returns the job's current state: status (queued/running/done), result count, and — if done — all results or an error. Use this to check on a job you submitted with wait=false, or to re-fetch results from a past job.
Output schemas not formally documented in code. Tool descriptions mention return fields (status, completed, ok, tokensSaved) but no explicit JSON Schema for responses is visible in src/server.ts. LLMs cannot reliably plan downstream operations without knowing response structure.
Async job polling (bulk, crawl) lacks explicit guidance on polling strategy. wait_for_job accepts poll_interval_ms but description does not explain when to use get_job vs wait_for_job vs blocking with wait=true. Agents may choose inefficient polling patterns.
No pagination or result limits documented for bulk/crawl results. If a crawl returns 100+ pages, the response could exceed context window. Tool descriptions should state max result count and offer pagination guidance.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Fetch the current billing-period quota state: URLs extracted, URLs remaining, and the reset date. Use this to check whether you have budget left before submitting a large bulk or crawl job.
Block until a bulk or crawl job finishes, polling at a fixed interval. Returns the job's final state: status (done), result count, and all results or an error. Throws if the timeout is exceeded before the job finishes.
Error handling surfaces WellMarkedError details (code, statusCode, retryAfter) but does not categorize errors as retryable vs user-fixable vs fatal. An LLM cannot distinguish 'retry this immediately' from 'ask the user to upgrade their plan' from 'this URL is permanently blocked'.
Destructive operations (crawl with max_pages=1000, extract with render_js=true consuming quota) lack confirmation or dry-run support. Agents could accidentally exhaust billing quota without warning.