Skip to main content
Glama

webcap

by io.github.shoutsid-lab
OverviewDiscussionsAdmin

Server Details

Screenshot, extract or audit any URL. Paid per call in USDC over x402; free tools need no wallet.

Ownership verified

Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.

If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.

Status
Unhealthy
Uptime
83.2% over 22 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
shoutsid-lab/webcap
GitHub Stars
0
Server Listing
webcap

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have distinct purposes (capture, extract, map, analyze), but there are notable overlaps: webcap_og vs webcap_audit both surface Open Graph data, and webcap_preview vs webcap_extract return overlapping page content. Descriptions do differentiate them (preview is a 'teaser', audit adds severity), so an agent can mostly choose correctly.

Naming Consistency5/5

Every tool uses the webcap_ prefix with snake_case (webcap_analyze, webcap_extract, webcap_map_lite), following a single predictable convention. No mixing of camelCase or alternate verb styles.

Tool Count5/5

8 tools is well-scoped for a web capture/analysis service, comfortably in the 3-15 range. Each tool maps to a real, distinct operation rather than padding the surface.

Completeness4/5

The surface covers the full lifecycle: discovery (map_lite), preview/peek (preview), structured extraction (extract), artifact capture (capture), metadata (og), analysis (analyze), audits (audit), and pricing discovery (service_catalog). Minor gaps exist (e.g., no batch capture or diff/change-tracking), but core workflows are fully covered.

Available Tools

8 tools
webcap_analyzeAInspect

PAID ($0.01): AI analysis of one URL. Pick the task that matches the question you are answering.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/
taskYesWhat to analyze (required, no default): classification = page type, accessibility = a11y issues, layout = structure and regions, entities = named entities and facts, sentiment = tone.

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses the $0.01 cost, which matters for a paid call, but says nothing about rate limits, auth requirements, latency, failure behavior, or what the response contains (no output schema exists either). Cost disclosure is real value, but the transparency is incomplete.

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

Conciseness5/5

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

Two short sentences, zero waste, with the most decision-critical fact (paid, $0.01) front-loaded ahead of the routing hint. Well-structured for scanning.

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?

Parameters are fully documented by the schema, but with no output schema and no annotations, an agent still lacks any picture of the return shape, response size, or error behavior. For a paid analysis call the description could reasonably say more about what comes back; it is adequate but not complete.

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 description coverage is 100% and the enum values are fully explained in the schema itself, so the description need not repeat them. Its added 'match the question you are answering' framing nudges task selection but does not add syntax or format meaning beyond the schema. Baseline 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?

Names a specific verb (AI analysis) and resource (one URL), and the leading 'PAID ($0.01)' tag immediately signals this is a metered AI call. It does not, however, distinguish itself from neighboring tools like webcap_extract or webcap_capture, so an agent cannot tell from the description alone which of these to pick for a given URL.

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?

'Pick the task that matches the question you are answering' gives light routing intuition toward the task enum, but there are no explicit when-to-use/when-not conditions and no named alternative among the many siblings (webcap_extract, webcap_audit, etc.). Usage is implied rather than stated.

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

webcap_auditAInspect

PAID ($0.002): SEO basics plus link and Open Graph health for one URL in a single call. Returns issues with severity, not just raw tags.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and it does disclose two useful traits: the tool is paid ($0.002) and it returns severity-ranked issues rather than raw tags. It says nothing about read-only nature, rate limits, caching, or failure behavior on unreachable URLs.

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

Conciseness5/5

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

Two sentences, zero waste, with the paid cost front-loaded so the agent knows the price before committing. Every clause carries information.

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

Completeness4/5

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

For a one-parameter audit tool with no output schema, the description covers cost, scope, and return shape (severity-ranked issues). The only gap is that it does not characterize what kinds of issues or how many might come back.

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?

Single url parameter with 100% schema description coverage, so the schema already documents the expected absolute http(s) format. The description adds no syntax or constraint details beyond that, matching the baseline 3 for full schema coverage.

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?

States a specific verb (audit) and resource (a single URL) with the exact scope: SEO basics plus link and Open Graph health. This implicitly separates it from single-purpose siblings like webcap_og, though it never names them explicitly.

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 phrase 'for one URL in a single call' implies this is the consolidated alternative to the narrower siblings, but there is no explicit when-to-use or when-not-to-use guidance compared to webcap_og or webcap_analyze.

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

webcap_captureAInspect

PAID ($0.001 image/PDF, $0.005 video): turn a URL into a persistent public artifact. png/jpeg/pdf are a screenshot or PDF and include free OG metadata; mp4/webm scroll-record the page as WebM/VP8 (mp4 is a legacy alias). Settles gasless USDC over x402 — but an unpaid call runs free while the rolling per-IP allowance lasts, so just call it.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/
formatNoArtifact format, default png. png/jpeg/pdf = screenshot/PDF at $0.001 (POST /v1/x402/capture); mp4/webm = scroll video at $0.005 (POST /v1/x402/video), always recorded as WebM/VP8. The 402 challenge states the exact price for the format you chose.png
fullPageNoImage/PDF only. true captures the whole scrollable page (default false: viewport only).
durationMsNoVideo formats only. Scroll duration in milliseconds, 1-30000; default 5000.

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the pricing model, gasless USDC settlement over x402, the free-unpaid fallback, included OG metadata, and that video is always encoded as WebM/VP8. It does not say how long the artifact persists or whether calls are idempotent/retryable on a 402.

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?

Cost is front-loaded and every clause carries information (price, artifact type, payment rail, free path). The single dense paragraph is slightly run-on but has no filler sentences.

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

Completeness4/5

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

For a payment-gated tool with no output schema, it covers the cost, settlement, and format behaviors well, which is the critical context. The one real gap is that it never states what the call returns (e.g., an artifact URL), leaving the response shape undocumented.

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 description coverage is 100%, so the baseline is 3. The description adds only marginal extra meaning beyond the schema ("mp4 is a legacy alias") and otherwise restates the per-format pricing and endpoint split already documented on the format property.

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 states a specific verb+resource (turn a URL into a persistent public artifact) and clarifies the artifact types (screenshot/PDF vs scroll video). It does not, however, differentiate itself from plausible siblings like webcap_preview or webcap_og, which an agent would need to pick between.

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?

It gives a directive ("just call it") plus the condition that an unpaid call runs free while the rolling per-IP allowance lasts, which implies when it is cheap to use. But it names no alternatives and gives no explicit when-not-to-use guidance against the seven sibling tools.

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

webcap_extractAInspect

PAID ($0.01, one payment covers a batch of up to 50 URLs): structured content as JSON — title, headings, paragraphs, links, images, document-order markdown. Provide exactly one of "url" (a single page) or "urls" (a batch); "url" is shorthand for a one-item "urls".

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoA single page to extract, e.g. https://example.com/. Shorthand for "urls": ["<url>"]. Mutually exclusive with "urls" — sending both is an error.
urlsNoBatch of pages for one payment, at most 50 items; a batch of one is allowed. Mutually exclusive with "url" — sending both is an error.
schemaNoOptional natural-language description of the JSON to extract. Omit it to get the default page structure.

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the critical behavioral trait: $0.01, one payment covering a batch of up to 50 URLs. It also scopes the return format. It stops short of payment mechanics (auto-charge timing, failure/refund behavior) and any auth or rate-limit context.

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?

A single dense sentence with the most decision-relevant fact (PAID, price, batch cap) front-loaded, followed by output shape and parameter rules. No filler, though it packs everything into one long clause chain.

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

Completeness4/5

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

No output schema exists, and the description compensates by enumerating the returned structure; the sole optional "schema" parameter is documented in the schema itself. Combined with the disclosed pricing model, this is nearly sufficient for a 3-parameter tool, with the main gap being no routing to the trial sibling.

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 description coverage is 100%, so baseline is 3. The description's statement that "url" is shorthand for a one-item "urls" and that exactly one must be provided merely restates the schema's oneOf and mutual-exclusivity notes rather than adding new meaning.

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?

States a specific verb+resource ("structured content as JSON") and enumerates the returned fields (title, headings, paragraphs, links, images, markdown), so the agent knows exactly what it gets. It implies differentiation from siblings like webcap_capture via the content-oriented output, but never names the near-identical webcap_trial_claim_extract, so sibling routing is left to inference.

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

Usage Guidelines2/5

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

The "PAID" prefix hints a fee-based alternative may exist but no when-to-use, when-not-to-use, or alternative tool is named — notably the sibling webcap_trial_claim_extract is never mentioned. The only "provide exactly one of url/urls" line is invocation mechanics, not usage guidance.

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

webcap_map_liteAInspect

PAID ($0.002): discover a site's URLs from its sitemap and robots.txt plus a 1-hop same-host crawl, and return them as a JSON list. Cheaper than crawling each page with webcap_extract.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/
maxUrlsNoMaximum number of URLs to return. Integer 1-50; default 20 when omitted.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it does disclose several traits: the tool is paid ($0.002), it works from sitemap/robots.txt plus a bounded 1-hop crawl, and it returns a JSON list. Not covered are failure behavior when no sitemap exists, rate limiting, or whether the 1-hop crawl respects robots directives.

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

Conciseness5/5

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

Two sentences, zero filler, and the cost and mechanism lead. The comparison to webcap_extract is placed last where it belongs as a routing hint.

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

Completeness4/5

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

For a two-parameter, non-destructive discovery tool with no output schema, the description tells the agent the source of URLs, the crawl depth, the output format, and the cost. Missing only edge-case behavior (empty sitemap, redirect handling) that would push it to a 5.

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 description coverage is 100%, including the url format and the maxUrls range/default, so the schema already documents both parameters fully. The description adds no syntax or format detail beyond it, which makes the baseline 3 appropriate.

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

Purpose5/5

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

States a specific verb (discover) and resource (a site's URLs) plus the exact mechanism (sitemap, robots.txt, 1-hop same-host crawl) and the return shape (JSON list). It explicitly contrasts itself with webcap_extract, so an agent can distinguish it from siblings without reading schemas.

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

Usage Guidelines4/5

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

Gives a clear selection signal: it is 'cheaper than crawling each page with webcap_extract,' which tells the agent to prefer this for URL enumeration over page-level extraction. It does not state when NOT to use it (e.g. dynamic sites without sitemaps) or any preconditions like host reachability.

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

webcap_ogBInspect

Free Open Graph metadata for a URL: title, description, image, icon. No payment.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/

TDQS

B3.2/5.0
Behavior3/5

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

Annotations are absent, so the description carries the full behavioral burden. It adds a pricing trait ('Free... No payment') and names output fields, but omits auth requirements, rate limits, read-only/no-side-effect confirmation, and error behavior.

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?

One compact sentence/fragment with no filler and front-loaded purpose. 'No payment' is somewhat redundant with 'Free,' but the description remains efficient.

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 simple one-parameter tool with no output schema and no annotations, the description is minimal but mostly adequate: it names the returned fields (title, description, image, icon). It still leaves return structure and error/fallback behavior unspecified, so completeness is only fair.

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?

The single url parameter is fully described in the schema (absolute http(s) URL, example), and the description adds no syntax or format beyond that. With 100% schema coverage and one parameter, baseline 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?

States a specific resource and return fields: Open Graph metadata (title, description, image, icon) for a URL. It distinguishes this from generic capture/analyze siblings by focusing on OG metadata, but it does not explicitly name or contrast with any sibling, so not a 5.

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

Usage Guidelines2/5

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

No guidance on when to choose webcap_og over webcap_preview, webcap_extract, or other siblings. The only contextual hint is 'No payment,' which implies a free tier but not a use case or exclusion.

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

webcap_previewAInspect

Free bounded preview of a page: title, description, headings, links, word count and a truncated markdown slice. Use it to peek before the full extract. Rate-limited per IP. This is a teaser, not the product: the real products are free too inside the rolling per-IP allowance.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesAbsolute http(s) URL of the page to process, e.g. https://example.com/

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden and does add real behavior: results are truncated/bounded, output is a 'slice', and the tool is rate-limited per IP. It does not describe failure behavior on rate-limit exhaustion, auth requirements, or pagination, leaving some operational gaps.

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?

Front-loaded with what it returns and how to use it; the rate-limit and 'teaser, not the product' sentences earn their place by preempting confusion with the full extraction tools. The final clause is slightly promotional but still conveys that the fuller products are also free.

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

Completeness4/5

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

No output schema exists, so the description appropriately enumerates the returned fields and discloses truncation and rate limiting. It omits error/limit-exceeded behavior and any hint of response size or latency, but is otherwise sufficient for a single-argument preview tool.

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?

Only one parameter exists and schema description coverage is 100%, so the schema already documents 'url' fully with format and an example. The description adds no format or constraint detail beyond the schema, matching the baseline for well-covered schemas.

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

Purpose5/5

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

States a specific verb+resource ('bounded preview of a page') and enumerates exactly what it returns (title, description, headings, links, word count, truncated markdown). It also explicitly contrasts itself with 'the full extract', which maps to the sibling webcap_extract, so an agent can distinguish the two 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.

Usage Guidelines4/5

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

'Use it to peek before the full extract' gives a clear condition for selecting this tool over the heavier extract sibling. There is no explicit when-not or exclusion guidance (e.g., when preview is insufficient), so it falls short of the top score.

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

webcap_service_catalogAInspect

Free service catalog (no payment): every paid endpoint with its exact price in USDC, the settlement network, USDC asset, payTo address, facilitator and the step-by-step x402 how-to-pay flow, plus the free allowance this caller has left. Call this first to learn what webcap sells and what it costs.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool is free (no payment), returns exact pricing, and reports the caller's remaining free allowance. It does not mention auth requirements or rate limits, but for a public read-only catalog those gaps are minor.

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

Conciseness5/5

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

Two sentences, front-loaded with the free-of-charge nature and a compact enumeration of what is returned. Every element earns its place and the closing directive is clear.

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

Completeness5/5

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

With no output schema, the description must describe the return content; it does so by listing the specific fields (prices, network, asset, payTo, facilitator, x402 flow, allowance). This is complete enough for an agent to know exactly what to expect from a zero-parameter catalog call.

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

Parameters4/5

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

The tool takes zero parameters, so there are no parameter semantics to explain. Per the baseline rule for 0 params, a 4 is appropriate; the description does not need to add parameter details.

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

Purpose5/5

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

The description states a specific resource (service catalog) and enumerates its contents: paid endpoints, USDC prices, settlement network, payTo address, facilitator, x402 flow, and caller's free allowance. This clearly distinguishes it from sibling action tools like webcap_analyze or webcap_capture, which perform operations rather than catalog discovery.

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

Usage Guidelines5/5

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

It explicitly directs the agent to 'Call this first' to learn what webcap sells and what it costs. That is a clear when-to-use instruction, and for a discovery/catalog tool no alternative or exclusion is necessary.

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.

  1. 1 tool update
    • Changedwebcap_capture1 field changed
      • changedInput schema / properties / format / description
        Previous value: -"Artifact format, default png. png/jpeg/pdf = screenshot/PDF at $0.001 (POST /v1/x402/capture); mp4/webm = scroll video at $0.005 (POST /v1/x402/video). The 402 challenge states the exact price for the format you chose."New value: +"Artifact format, default png. png/jpeg/pdf = screenshot/PDF at $0.001 (POST /v1/x402/capture); mp4/webm = scroll video at $0.005 (POST /v1/x402/video), always recorded as WebM/VP8. The 402 challenge states the exact price for the format you chose."
  2. 3 tool updates
    • Changedwebcap_preview1 field changed
      • removedInput schema / properties / thumbnail
        Removed value: -{
-  "default": false,
-  "description": "false (default) = JSON preview. true = a free JPEG thumbnail artifact instead (no wallet needed, 3/day per IP), for a quick visual check rather than a citable artifact.",
-  "type": "boolean"
-}
    • Changedwebcap_service_catalog1 field changed
      • removedInput schema / properties / payer
        Removed value: -{
-  "description": "Optional 0x-prefixed 20-byte EVM address. When given, the result also lists which free trials that wallet has claimed and which it can still claim. Omit for the plain catalog.",
-  "pattern": "^0x[0-9a-fA-F]{40}$",
-  "type": "string"
-}
    • Removedwebcap_trial
  3. 14 tool updates
    • Changedwebcap_capture4 fields changed
      • addedInput schema / properties / durationMs
        Added value: +{
+  "default": 5000,
+  "description": "Video formats only. Scroll duration in milliseconds, 1-30000; default 5000.",
+  "maximum": 30000,
+  "minimum": 1,
+  "type": "integer"
+}
      • changedInput schema / properties / format / description
        Previous value: -"Screenshot format; one of png, jpeg, pdf. Default png."New value: +"Artifact format, default png. png/jpeg/pdf = screenshot/PDF at $0.001 (POST /v1/x402/capture); mp4/webm = scroll video at $0.005 (POST /v1/x402/video). The 402 challenge states the exact price for the format you chose."
      • changedInput schema / properties / format / enum
        Previous value: -[
-  "png",
-  "jpeg",
-  "pdf"
-]New value: +[
+  "png",
+  "jpeg",
+  "pdf",
+  "mp4",
+  "webm"
+]
      • changedInput schema / properties / fullPage / description
        Previous value: -"true captures the whole scrollable page (default false: viewport only)."New value: +"Image/PDF only. true captures the whole scrollable page (default false: viewport only)."
    • Removedwebcap_feedback
    • Removedwebcap_health
    • Changedwebcap_preview1 field changed
      • addedInput schema / properties / thumbnail
        Added value: +{
+  "default": false,
+  "description": "false (default) = JSON preview. true = a free JPEG thumbnail artifact instead (no wallet needed, 3/day per IP), for a quick visual check rather than a citable artifact.",
+  "type": "boolean"
+}
    • Removedwebcap_quick_thumbnail
    • Changedwebcap_service_catalog1 field changed
      • addedInput schema / properties / payer
        Added value: +{
+  "description": "Optional 0x-prefixed 20-byte EVM address. When given, the result also lists which free trials that wallet has claimed and which it can still claim. Omit for the plain catalog.",
+  "pattern": "^0x[0-9a-fA-F]{40}$",
+  "type": "string"
+}
    • Addedwebcap_trial
    • Removedwebcap_trial_claim_analyze
    • Removedwebcap_trial_claim_audit
    • Removedwebcap_trial_claim_capture
    • Removedwebcap_trial_claim_extract
    • Removedwebcap_trial_claim_map_lite
    • Removedwebcap_trial_status
    • Removedwebcap_video
  4. 18 tool updates
    • Removedwebcap_agent_funnel
    • Changedwebcap_analyze3 fields changed
      • changedInput schema / properties / task / description
        Previous value: -"What to analyze"New value: +"What to analyze (required, no default): classification = page type, accessibility = a11y issues, layout = structure and regions, entities = named entities and facts, sentiment = tone."
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_audit2 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_capture6 fields changed
      • addedInput schema / properties / format / default
        Added value: +"png"
      • changedInput schema / properties / format / description
        Previous value: -"Screenshot format (default png)"New value: +"Screenshot format; one of png, jpeg, pdf. Default png."
      • addedInput schema / properties / fullPage / default
        Added value: +false
      • changedInput schema / properties / fullPage / description
        Previous value: -"Capture the full scrollable page"New value: +"true captures the whole scrollable page (default false: viewport only)."
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_extract7 fields changed
      • addedInput schema / oneOf
        Added value: +[
+  {
+    "required": [
+      "url"
+    ]
+  },
+  {
+    "required": [
+      "urls"
+    ]
+  }
+]
      • changedInput schema / properties / schema / description
        Previous value: -"Optional natural-language description of the JSON to extract"New value: +"Optional natural-language description of the JSON to extract. Omit it to get the default page structure."
      • changedInput schema / properties / url / description
        Previous value: -"A single page to extract"New value: +"A single page to extract, e.g. https://example.com/. Shorthand for \"urls\": [\"<url>\"]. Mutually exclusive with \"urls\" — sending both is an error."
      • addedInput schema / properties / url / format
        Added value: +"uri"
      • changedInput schema / properties / urls / description
        Previous value: -"Batch (at most 50) for one payment"New value: +"Batch of pages for one payment, at most 50 items; a batch of one is allowed. Mutually exclusive with \"url\" — sending both is an error."
      • addedInput schema / properties / urls / items / format
        Added value: +"uri"
      • addedInput schema / properties / urls / maxItems
        Added value: +50
    • Changedwebcap_map_lite6 fields changed
      • addedInput schema / properties / maxUrls / default
        Added value: +20
      • changedInput schema / properties / maxUrls / description
        Previous value: -"1-50 (default 20)"New value: +"Maximum number of URLs to return. Integer 1-50; default 20 when omitted."
      • addedInput schema / properties / maxUrls / maximum
        Added value: +50
      • addedInput schema / properties / maxUrls / minimum
        Added value: +1
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_og2 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_preview2 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_quick_thumbnail2 fields changed
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Removedwebcap_service
    • Addedwebcap_service_catalog
    • Changedwebcap_trial_claim_analyze6 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Your lowercase 0x EVM address"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars). The server lowercases it, so sign the lowercase form."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
      • changedInput schema / properties / signature / description
        Previous value: -"EIP-191 personal_sign of exactly \"Claim one free webcap trial {endpoint} for {payer}\", with {payer} lowercase. A repeat claim answers 409 with a paidNext pointer."New value: +"EIP-191 personal_sign (0x-prefixed, 65 bytes = 2 + 130 hex chars) of exactly \"Claim one free webcap trial analyze for <your lowercase payer>\". A malformed signature is rejected locally; one that does not recover to your payer answers 401 with the expected message; a repeat claim answers 409 with a paidNext pointer."
      • addedInput schema / properties / signature / pattern
        Added value: +"^0x[0-9a-fA-F]{130}$"
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_trial_claim_audit6 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Your lowercase 0x EVM address"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars). The server lowercases it, so sign the lowercase form."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
      • changedInput schema / properties / signature / description
        Previous value: -"EIP-191 personal_sign of exactly \"Claim one free webcap trial {endpoint} for {payer}\", with {payer} lowercase. A repeat claim answers 409 with a paidNext pointer."New value: +"EIP-191 personal_sign (0x-prefixed, 65 bytes = 2 + 130 hex chars) of exactly \"Claim one free webcap trial audit for <your lowercase payer>\". A malformed signature is rejected locally; one that does not recover to your payer answers 401 with the expected message; a repeat claim answers 409 with a paidNext pointer."
      • addedInput schema / properties / signature / pattern
        Added value: +"^0x[0-9a-fA-F]{130}$"
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_trial_claim_capture6 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Your lowercase 0x EVM address"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars). The server lowercases it, so sign the lowercase form."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
      • changedInput schema / properties / signature / description
        Previous value: -"EIP-191 personal_sign of exactly \"Claim one free webcap trial {endpoint} for {payer}\", with {payer} lowercase. A repeat claim answers 409 with a paidNext pointer."New value: +"EIP-191 personal_sign (0x-prefixed, 65 bytes = 2 + 130 hex chars) of exactly \"Claim one free webcap trial capture for <your lowercase payer>\". A malformed signature is rejected locally; one that does not recover to your payer answers 401 with the expected message; a repeat claim answers 409 with a paidNext pointer."
      • addedInput schema / properties / signature / pattern
        Added value: +"^0x[0-9a-fA-F]{130}$"
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_trial_claim_extract6 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Your lowercase 0x EVM address"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars). The server lowercases it, so sign the lowercase form."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
      • changedInput schema / properties / signature / description
        Previous value: -"EIP-191 personal_sign of exactly \"Claim one free webcap trial {endpoint} for {payer}\", with {payer} lowercase. A repeat claim answers 409 with a paidNext pointer."New value: +"EIP-191 personal_sign (0x-prefixed, 65 bytes = 2 + 130 hex chars) of exactly \"Claim one free webcap trial extract for <your lowercase payer>\". A malformed signature is rejected locally; one that does not recover to your payer answers 401 with the expected message; a repeat claim answers 409 with a paidNext pointer."
      • addedInput schema / properties / signature / pattern
        Added value: +"^0x[0-9a-fA-F]{130}$"
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_trial_claim_map_lite6 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Your lowercase 0x EVM address"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars). The server lowercases it, so sign the lowercase form."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
      • changedInput schema / properties / signature / description
        Previous value: -"EIP-191 personal_sign of exactly \"Claim one free webcap trial {endpoint} for {payer}\", with {payer} lowercase. A repeat claim answers 409 with a paidNext pointer."New value: +"EIP-191 personal_sign (0x-prefixed, 65 bytes = 2 + 130 hex chars) of exactly \"Claim one free webcap trial map-lite for <your lowercase payer>\". A malformed signature is rejected locally; one that does not recover to your payer answers 401 with the expected message; a repeat claim answers 409 with a paidNext pointer."
      • addedInput schema / properties / signature / pattern
        Added value: +"^0x[0-9a-fA-F]{130}$"
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
    • Changedwebcap_trial_status2 fields changed
      • changedInput schema / properties / payer / description
        Previous value: -"Lowercase 0x EVM address to look up"New value: +"Your 0x-prefixed 20-byte EVM address (2 + 40 hex chars), lowercased for the lookup."
      • addedInput schema / properties / payer / pattern
        Added value: +"^0x[0-9a-fA-F]{40}$"
    • Changedwebcap_video8 fields changed
      • addedInput schema / properties / durationMs / default
        Added value: +5000
      • changedInput schema / properties / durationMs / description
        Previous value: -"Scroll duration in ms (default 5000, max 30000)"New value: +"Scroll duration in milliseconds, 1-30000; default 5000."
      • addedInput schema / properties / durationMs / maximum
        Added value: +30000
      • addedInput schema / properties / durationMs / minimum
        Added value: +1
      • addedInput schema / properties / format / default
        Added value: +"mp4"
      • changedInput schema / properties / format / description
        Previous value: -"Video format (default mp4)"New value: +"Video format; mp4 or webm. Default mp4."
      • changedInput schema / properties / url / description
        Previous value: -"Absolute http(s) URL to fetch"New value: +"Absolute http(s) URL of the page to process, e.g. https://example.com/"
      • addedInput schema / properties / url / format
        Added value: +"uri"
  5. 19 tool updates
    • First observedwebcap_agent_funnel
    • First observedwebcap_analyze
    • First observedwebcap_audit
    • First observedwebcap_capture
    • First observedwebcap_extract
    • First observedwebcap_feedback
    • First observedwebcap_health
    • First observedwebcap_map_lite
    • First observedwebcap_og
    • First observedwebcap_preview
    • First observedwebcap_quick_thumbnail
    • First observedwebcap_service
    • First observedwebcap_trial_claim_analyze
    • First observedwebcap_trial_claim_audit
    • First observedwebcap_trial_claim_capture
    • First observedwebcap_trial_claim_extract
    • First observedwebcap_trial_claim_map_lite
    • First observedwebcap_trial_status
    • First observedwebcap_video

Publisher details

Operator
shoutsid · Publisher source
Operator website
https://webcap.shoutsid.fyi · Publisher source
Vendor relationship
Not applicable
Documentation
Unknown
Trust center
Unknown
Restrictions
Unknown

Related MCP Connectors

Related MCP Servers

  • screenshot-pdf

    Br0ski777
    A
    license
    Not graded
    quality
    C
    maintenance
    Captures full-page screenshots and PDFs from any URL using Chromium rendering, with pay-per-call via x402 micropayments.
    MIT

  • skim-mcp

    JessieJanie
    A
    license
    A
    quality
    C
    maintenance
    Pay-per-use clean web reader for AI agents. URL in, markdown plus metadata out, in milliseconds. Settled per-call in USDC over x402 — no signup, no API keys.
    1
    71 npm
    3
    MIT
  • dev.oassis/scraper-crawler by oassisdev

    dev.oassis/scraper-crawlerofficial

    oassisdev
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables agents to read any web page or document as markdown, html, links, screenshots or extracted JSON, map and crawl entire sites, and drive a persistent browser session that stays open between calls so pages can be inspected and clicked without reloading. Callers pay per request with a wallet over x402 — no API key or signup — and every route answers its own free GET with the fields it expects.
    1
    -
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources