Skip to main content
Glama
CaptureKit MCP Server

CaptureKit MCP Server

Official

Content

content
Read-only

Extract structured webpage data, metadata, links, HTML, and Markdown in one request to support SEO, monitoring, indexing, and automation.

Instructions

Content. CaptureKit Content API extracts structured webpage data, metadata, links, HTML/Markdown: in one request for SEO, monitoring, indexing and automation. Credit cost: 1 credit per call.

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL of the webpage to capture.
cacheNoCache the response. Default: false.
delayNoDelay in seconds before capturing the screenshot. Default: 0.
proxyNoSpecify a proxy server to route your request through.
fieldsNoComma-separated list of fields to keep in the response, with dot notation for nested fields (e.g. name,location.city). Does not change the credit cost.
cache_ttlNoCache the response for a custom TTL (in seconds). Default: 2592000.
block_urlsNoComma-separated list of URL patterns to block (e.g., “analytics,tracking,advertisement”).
remove_adsNoAutomatically remove ads before capturing. Default: false.
wait_untilNoDefine when to capture. Allowed values: domcontentloaded, load, networkidle0, networkidle2.
include_htmlNoInclude the raw HTML of the webpage in the response. Default: false.
use_defuddleNoUse Defuddle to clean and extract the main content from web pages. This popular library removes unnecessary elements like comments, sidebars, headers, footers, and other non-essential elements, leaving only the primary content. When enabled, the HTML response will be processed through Defuddle befo… Default: false.
block_resourcesNoComma-separated list of resource types to block (e.g., “image,stylesheet,font”). Allowed values: document, eventsource, fetch, font, image, manifest, media, other, script, stylesheet, texttrack, websocket, xhr.
include_sitemapNoInclude the sitemap of the website in the response. Default: false.
include_markdownNoInclude the Markdown of the webpage in the response. Default: false.
remove_selectorsNoA comma-separated list of elements to hide before capturing (e.g., ads, popups).
wait_for_selectorNoWait for a specific element to appear before taking the screenshot.
remove_cookie_bannersNoAutomatically remove cookie banners before capturing. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful non-schema context — a fixed cost of 1 credit per call — but says nothing about response shape, caching behavior, or failure modes for what is a 17-parameter scraping request.

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

Conciseness4/5

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

Three tight sentences, front-loaded with the core capability and ending with the cost caveat. The leading one-word 'Content.' merely restates the title and could be dropped, but otherwise there is no wasted wording.

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

Completeness3/5

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

For a 17-parameter extraction tool with no output schema, the description does at least inventory the kinds of data returned (metadata, links, HTML/Markdown). It still leaves an agent guessing about the response envelope and how the many optional toggles combine, which matters given the absence of an output schema.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter is already documented with examples, defaults, and allowed values in the schema itself. The description only loosely gestures at the HTML/Markdown toggles and adds no format or interaction detail beyond what the schema provides, so the baseline of 3 applies.

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

Purpose4/5

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

The description names a specific verb (extracts) and enumerates concrete outputs — structured webpage data, metadata, links, HTML/Markdown — plus the scenarios it serves (SEO, monitoring, indexing, automation). It is clear on its own but never distinguishes itself from siblings like 'capture' or 'analyze', which an agent could easily confuse it with given the generic name 'content'.

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

Usage Guidelines3/5

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

The listed use cases (SEO, monitoring, indexing, automation) imply when the tool is appropriate, which is better than nothing. However, there is no explicit guidance on when to choose this over 'capture', 'analyze', or 'website_crawler', and no stated exclusions or prerequisites.

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

Deploy Server

Other Tools