snapforge
Server Details
Screenshots, PDFs and Markdown from any URL or HTML for AI agents, via the SnapForge API
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- sporty303/snapforge-mcp
- GitHub Stars
- 0
- Server Listing
- snapforge-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 4 of 4 tools scored.
Each tool performs a distinct function: markdown extraction, PDF rendering, screenshot capture, and account signup. There is no overlap in purpose, making it easy for an agent to select the correct tool.
All tools follow a consistent 'snapforge_<noun>' pattern, using clear and descriptive names (markdown, pdf, screenshot, signup). The naming convention is uniform and predictable.
With 4 tools, the server is well-scoped for its purpose of capturing web content in different formats plus account management. The count is neither too sparse nor excessive for a utility server.
The core functionality of rendering web content to Markdown, PDF, and screenshot is covered, along with signup. Minor gaps exist, such as managing saved captures or batch operations, but the set is complete for immediate use.
Available Tools
4 toolssnapforge_markdownSnapForge URL to MarkdownARead-onlyInspect
Extract a clean Markdown version of a public URL or raw HTML (article extraction + HTML→Markdown). Great for feeding live web content to an LLM. Requires a SnapForge API key (no key? call snapforge_signup first).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public http/https URL to render. Provide either url or html. | |
| html | No | Raw HTML to render instead of a URL (max 2MB). Provide either url or html. | |
| delay | No | Extra wait in milliseconds before capture (0–10000) | |
| waitUntil | No | When to consider the page ready: "load" (default) or "networkidle" |
Output Schema
| Name | Required | Description |
|---|---|---|
| markdown | Yes | The extracted Markdown content |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral context (article extraction + HTML→Markdown) and mentions the need for an API key. It does not disclose potential issues like rate limits or response size, but the annotations already provide sufficient transparency for a read-only tool.
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 concise (two sentences) and front-loaded with the key action. Every sentence adds value: the first states the function and benefits, the second gives usage guidance and prerequisite. No wasted words.
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?
Given the tool has an output schema (from context signals) and the annotations cover safety, the description is complete for its purpose. It specifies what it does, when to use it, and a necessary prerequisite. No missing information for a simple extraction tool.
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 100%, and the input schema provides detailed descriptions for all four parameters (url, html, delay, waitUntil). The description adds minimal parameter meaning by mentioning 'URL or raw HTML', but overall relies on the schema. Baseline 3 is appropriate.
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 clearly states it extracts clean Markdown from URLs or raw HTML, specifying the action (Extract, article extraction + HTML→Markdown) and the resource (public URL or raw HTML). It distinguishes itself from sibling tools like snapforge_pdf and snapforge_screenshot by focusing on Markdown conversion.
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 explicitly states when to use the tool ('Great for feeding live web content to an LLM') and provides a prerequisite ('Requires a SnapForge API key') along with an alternative action if the key is missing ('call snapforge_signup first'). This gives clear guidance on usage context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapforge_pdfSnapForge PDFARead-onlyInspect
Render a public URL or raw HTML to a PDF (returned as an embedded resource). Requires a SnapForge API key (no key? call snapforge_signup first).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public http/https URL to render. Provide either url or html. | |
| html | No | Raw HTML to render instead of a URL (max 2MB). Provide either url or html. | |
| delay | No | Extra wait in milliseconds before capture (0–10000) | |
| margin | No | CSS size applied to all margins, e.g. "1cm" | |
| landscape | No | Landscape orientation (default false) | |
| waitUntil | No | When to consider the page ready: "load" (default) or "networkidle" | |
| pageFormat | No | Paper size when paginating (default A4) | |
| singlePage | No | Output one continuous page sized to the content height (no A4 pagination) | |
| printBackground | No | Include CSS background colors and images (default true) |
Output Schema
| Name | Required | Description |
|---|---|---|
| bytes | Yes | Size of the generated PDF in bytes |
| mimeType | Yes | Always application/pdf |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds that the output is an embedded resource and that an API key is required. This provides useful behavioral context. No contradiction with annotations.
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?
Two sentences, zero wasted words. Front-loaded with the core action and resource, followed by the critical prerequisite. Efficient and clear.
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?
Given the rich schema (9 params, all described) and output schema presence, the description covers the crucial prerequisite and input types. It does not mention error handling or performance, but overall complete for the tool's complexity.
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 coverage is 100% with detailed parameter descriptions. The description adds minimal extra meaning (e.g., 'public URL or raw HTML' aligning with url/html params). Baseline score of 3 is appropriate.
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 uses specific verb 'Render' and clearly identifies the resource ('public URL or raw HTML to a PDF'), distinguishing it from sibling tools like snapforge_screenshot (image) and snapforge_markdown (markdown).
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?
Explicitly states the prerequisite of an API key and directs users lacking a key to snapforge_signup. This provides clear guidance on when to use this tool and an alternative. However, it does not explicitly exclude non-public URLs or compare with other rendering tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapforge_screenshotSnapForge screenshotARead-onlyInspect
Capture a screenshot of a public URL or raw HTML as a PNG/JPEG image. Full-page by default. Requires a SnapForge API key (no key? call snapforge_signup first).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public http/https URL to render. Provide either url or html. | |
| html | No | Raw HTML to render instead of a URL (max 2MB). Provide either url or html. | |
| delay | No | Extra wait in milliseconds before capture (0–10000) | |
| scale | No | Device pixel ratio for high-DPI/retina output (1–3) | |
| width | No | Viewport width in pixels (100–3840) | |
| format | No | Image format: "png" (default) or "jpeg" | |
| height | No | Viewport height in pixels (100–2160) | |
| quality | No | JPEG quality 1–100 (ignored for PNG) | |
| fullPage | No | Capture the full scrollable page (default true) | |
| waitUntil | No | When to consider the page ready: "load" (default) or "networkidle" |
Output Schema
| Name | Required | Description |
|---|---|---|
| bytes | Yes | Size of the returned image in bytes |
| mimeType | Yes | Image MIME type, e.g. image/png |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) are consistent with the read operation. The description adds behavioral context (full-page default, API key requirement) beyond annotations. No contradictions.
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 two sentences, front-loaded with the main purpose, and includes essential prerequisite. No redundant words.
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 covers high-level behavior, input types, output format, and prerequisite. An output schema exists, so return values are handled. Ambiguity remains about whether url or html is required (schema says optional), but overall sufficient.
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 descriptions cover all 10 parameters (100% coverage), so baseline is 3. The description adds value by noting full-page default and API key requirement, slightly improving clarity.
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 clearly states the action (capture screenshot), inputs (URL or raw HTML), output format (PNG/JPEG), and default behavior (full-page). It distinguishes from siblings (markdown, pdf, signup) by its unique function.
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 mentions a prerequisite (SnapForge API key) and directs to snapforge_signup if missing. It does not explicitly state when not to use this tool, but sibling tools are distinct, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapforge_signupSnapForge signup (free API key)AInspect
Create a free SnapForge account (100 renders/month) with just an email address and get the API key instantly. The key is bound to the current MCP session, so the screenshot/pdf/markdown tools work immediately after signup — no browser needed.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to attach the API key to (the key is also emailed there) |
Output Schema
| Name | Required | Description |
|---|---|---|
| plan | Yes | Plan name (free) |
| apiKey | Yes | Your SnapForge API key |
| monthlyQuota | Yes | Included renders per month |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide limited context (not readOnly, not destructive, openWorld). The description adds behavioral detail: the key is instant, session-bound, and works without a browser. No contradictions with annotations.
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?
Two sentences only, front-loaded with purpose and key benefit (100 renders/month, instant key). Every sentence adds value, no 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?
With a simple one-parameter signup and an output schema present, the description adequately covers the behavioral context (immediate use, session binding) and is sufficient for an agent to invoke the tool correctly.
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 coverage is 100% for the single parameter 'email' with a clear description. The tool description does not add new info beyond the schema, meeting the baseline for high coverage.
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 clearly states the tool creates a free SnapForge account (verb 'create') with specific resource 'account' and details the limit of 100 renders/month. It distinguishes from sibling rendering tools (snapforge_markdown, etc.) by being a prerequisite signup tool.
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 explicitly tells when to use this tool: before using the screenshot/pdf/markdown tools. It states the key is bound to the current MCP session and works immediately, implying no further setup needed. No when-not-to-use or alternative guidance, but it is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.