PaperSprocket MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PAPERSPROCKET_API_KEY | Yes | Your PaperSprocket API key. Secret/config state — never a tool argument. | |
| PAPERSPROCKET_BASE_URL | No | API base URL. Fixed/config state. | https://papersprocket.com/api |
| PAPERSPROCKET_MCP_OUTPUT_DIR | No | Directory where rendered PDFs are also written (best-effort) for filesystem-local clients. | ./output |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_html_to_pdfA | Render HTML to a PDF through the PaperSprocket API. Returns the PDF as an application/pdf embedded resource (base64 blob), the local file path when the server can write it, and render metadata (render_id, page_count, charged_cents, balance_cents). Billed to the configured PaperSprocket account. |
| check_balanceB | Check the prepaid balance of the configured PaperSprocket account. Returns account_id, balance_cents, currency, and page_price_cents. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one performs the core rendering action and the other retrieves account balance information. There is no overlap or ambiguity in when to use each tool.
Both tools follow a consistent snake_case verb_noun pattern (render_html_to_pdf, check_balance). The convention is predictable and readable.
With only two tools, the surface feels thin for a server that wraps a rendering API. While each tool earns its place, the set is minimal and may leave agents wanting more operations.
The core workflow of rendering HTML to PDF and checking balance is covered, but there are minor gaps such as retrieving render history, checking render status, or managing account details. These gaps are unlikely to block basic usage.