Capture a screenshot from a URL or HTML string (async job). Output: { jobId, status, poll } — poll job endpoint for image URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| html | No | ||
| device | No | ||
| blockAds | No | ||
| fullPage | No | ||
| selector | No | ||
| blockCookieBanners | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and open-world. The description adds valuable behavioral context by disclosing that this is an asynchronous job, that it returns { jobId, status, poll }, and that the image URL requires polling. This goes beyond what the annotations 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?
The description is compact and front-loaded, stating the core purpose in the first sentence and the async output behavior in the second. Every sentence adds essential information without waste.
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?
The description gives the critical async job flow and output shape, which is enough for a basic call. However, with 7 parameters, no output schema, and no documentation of selector/device/cookie-banner behavior, it is not fully complete for advanced usage.
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 description coverage is 0%, so the description must compensate for 7 undocumented parameters. It only references url and html; it does not explain device, blockAds, fullPage, selector, or blockCookieBanners semantics, leaving important optional behavior ambiguous.
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 names a specific action and resource: capture a screenshot from a URL or HTML string. This clearly differentiates it from sibling tools such as forgekit_render_pdf, forgekit_generate_og_image, or forgekit_generate_qr.
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?
The description implies when to use the tool: whenever a screenshot of web content is needed. However, it provides no explicit when-not-to-use guidance or alternatives, leaving an agent to infer routing from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
ship_verify and ship_verify_v2 are near-synonyms, and ship_bundle wraps ship_pack plus an audit while evidence_pack combines screenshot/PDF/HTML. The descriptions help, but an agent could easily pick the wrong granularity or version.
All tools use the forgekit_ prefix and snake_case, but verb placement is inconsistent: business_days_add/count place the noun first, evidence_pack has no verb, and the ship_* group mixes noun and verb senses. The set is readable but not uniformly patterned.
Fifteen tools is near the upper end of a reasonable utility-kit size, and most tools are individually useful. It feels slightly over-scoped because ship_verify_v2 and ship_bundle partially duplicate other capabilities rather than adding clearly new operations.
The web/media surface is broadly covered with screenshots, PDFs, QR encode/decode, OG previews, evidence packs, and agent-readiness audits. However, the set is an eclectic collection rather than one coherent workflow, and there are gaps such as no MCP-level polling for async jobs and no history/retrieval for evidence packs or ship bundles.