PageShot

generate_pdf

Convert a webpage URL or raw HTML to a PDF document. Supports page size, orientation, margins, and background printing. Returns PDF as base64.

Input Schema

TableJSON Schema

Name	Required	Description
`css`	No	Custom CSS to inject before PDF generation
`url`	No	URL to convert to PDF (provide url OR html, not both)
`html`	No	Raw HTML to convert to PDF (provide html OR url, not both)
`locale`	No	BCP 47 locale tag for the browser context (e.g., "en-US")
`cookies`	No	Cookies to set before capture (e.g., [{"name": "session", "value": "abc123"}])
`headers`	No	Custom HTTP headers to send with the request (e.g., {"Authorization": "Bearer token"})
`evaluate`	No	JavaScript code to execute on the page before PDF generation (max 10KB). Runs in the browser context.
`latitude`	No	Geolocation latitude (-90 to 90)
`timezone`	No	IANA timezone for the browser context (e.g., "America/New_York")
`block_ads`	No	Block ads and trackers
`dark_mode`	No	Enable dark mode emulation
`landscape`	No	Landscape orientation (default: false)
`longitude`	No	Geolocation longitude (-180 to 180)
`pdf_scale`	No	Content scale 0.1-2 (default: 1)
`pdf_format`	No	Page size (default: A4)
`wait_until`	No	Page load strategy (default: domcontentloaded). Use "networkidle" for SPAs.
`print_background`	No	Include background colors/images (default: true)
`disable_javascript`	No	Disable JavaScript execution on the page
`ignore_https_errors`	No	Ignore HTTPS/TLS certificate errors

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedMar 13, 2026

addedInput schema / properties / ignore_https_errors

Added value: +{
+  "description": "Ignore HTTPS/TLS certificate errors",
+  "type": "boolean"
+}

addedInput schema / properties / wait_until

Added value: +{
+  "description": "Page load strategy (default: domcontentloaded). Use \"networkidle\" for SPAs.",
+  "enum": [
+    "commit",
+    "domcontentloaded",
+    "load",
+    "networkidle"
+  ],
+  "type": "string"
+}

Changed3 schema fields changedMar 11, 2026

addedInput schema / properties / disable_javascript

Added value: +{
+  "description": "Disable JavaScript execution on the page",
+  "type": "boolean"
+}

addedInput schema / properties / latitude

Added value: +{
+  "description": "Geolocation latitude (-90 to 90)",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / longitude

Added value: +{
+  "description": "Geolocation longitude (-180 to 180)",
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

Changed2 schema fields changedMar 10, 2026

addedInput schema / properties / locale

Added value: +{
+  "description": "BCP 47 locale tag for the browser context (e.g., \"en-US\")",
+  "type": "string"
+}

addedInput schema / properties / timezone

Added value: +{
+  "description": "IANA timezone for the browser context (e.g., \"America/New_York\")",
+  "type": "string"
+}

Changed1 schema field changedMar 9, 2026

addedInput schema / properties / evaluate

Added value: +{
+  "description": "JavaScript code to execute on the page before PDF generation (max 10KB). Runs in the browser context.",
+  "type": "string"
+}

Changed2 schema fields changedMar 8, 2026

addedInput schema / properties / cookies

Added value: +{
+  "description": "Cookies to set before capture (e.g., [{\"name\": \"session\", \"value\": \"abc123\"}])",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "path": {
+        "type": "string"
+      },
+      "value": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "value"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Custom HTTP headers to send with the request (e.g., {\"Authorization\": \"Bearer token\"})",
+  "type": "object"
+}

AddedMar 7, 2026

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that the tool returns a base64 PDF and supports certain options, but it does not disclose potential side effects (e.g., network fetching, JavaScript execution, headless browser usage), error conditions, or any safety considerations. This is a significant gap for a tool with 19 parameters.

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?

The description is exceptionally concise: two sentences front-load the core purpose, then list capabilities and output format. Every sentence earns its place, and there is no redundant restating of the tool name or schema details.

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

Completeness2/5

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

Given the tool's complexity (19 parameters, no output schema, no annotations), the description is too thin. It does not mention the headless browser context, execution behavior (e.g., JavaScript execution, network requests), potential performance implications, or any usage tips for advanced options like wait_until. The schema covers parameter details, but the description fails to provide a holistic overview of the tool's behavior and constraints.

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 input schema has 100% parameter description coverage, so the baseline is 3. The description mentions page size, orientation, margins, and background printing, which map to existing parameters but do not add new meaning or clarify usage beyond the schema. It does not explain the url/html exclusivity or any parameter interdependencies, but the schema already handles that.

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 clearly states the verb "Convert" and the resource (webpage URL or raw HTML) to a PDF document, which immediately distinguishes it from sibling tools that handle screenshots or HTML rendering. It also explicitly mentions the output format (base64), making the tool's purpose unambiguous.

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?

The description conveys the tool's context: it converts web content to PDF, and indicates the accepted input types (URL or raw HTML). However, it does not explicitly mention alternatives or when to prefer this over sibling tools like take_screenshot or render_html. Still, the clarity of purpose provides enough context for an agent to decide appropriately.

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

All PageShot tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation4/5

take_screenshot and batch_screenshot both capture screenshots, but batch_screenshot handles multiple URLs while take_screenshot handles a single page, making them distinct enough. render_html and generate_pdf are clearly separate (image vs. PDF, HTML input vs. URL/HTML). Minor confusion possible between the two screenshot tools.

Naming Consistency4/5

Three tools follow the verb_noun pattern (take_screenshot, generate_pdf, render_html), but batch_screenshot breaks the pattern by leading with an adjective/noun rather than a verb. The inconsistency is minor and the names remain readable.

Tool Count5/5

Four tools is well-scoped for a page capture server. Each tool covers a distinct use case: single screenshot, batch screenshot, HTML rendering to image, and PDF generation. No redundancy or excessive bloat.

Completeness4/5

The set covers core web capture needs: single page screenshots, batch captures, HTML/CSS to image, and PDF conversion. Minor gaps include no explicit full-page screenshot option or advanced viewport control, but common workflows are supported.

Resources

Need Help?