Skip to main content
Glama
Sign In

webcap

by io.github.shoutsid-lab
OverviewDiscussionsAdmin

webcap_preview

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "webcap_preview"
  }
}

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema 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"
-}
  2. Changed1 schema 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"
+}
  3. Changed2 schema 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"
  4. First observed

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.

All webcap toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources