One-off renders are useful, but the shape that saves real work is a template with typed variables and a hundred-item batch behind it — event passes, team badges, a product catalogue — started as a job and collected when it finishes rather than looped one call at a time.
Pictify's rendering API as a server: images from HTML and CSS, from a URL screenshot or from a reusable template; animated GIFs from CSS animation or recorded off a live page; PDFs from templates; and batches of up to 100 personalised renders in one job.
- An image generated from HTML and CSS, a URL screenshot, or a template — OG images, social cards, banners, product shots
- Images from FabricJS canvas JSON, for anything authored on a canvas rather than in markup
- Animated GIFs two ways: rendered from CSS animation, or captured off a live web page over time
- PDFs from templates, single-page or multi-page, with the available page-size presets listable — invoices, certificates, reports, shipping labels
- A template system you can work from inside the conversation: templates listed with filters and paging, opened, created, updated and deleted, with their variable definitions and types readable before you render
- Templates rendered with variables and layout variants, backed by 50+ expression functions for conditionals, string handling and date formatting
- Batch renders of up to 100 items started asynchronously, polled for status and result URLs, and cancelled mid-run
- Everything generated stays listable and fetchable by ID afterwards, for images and GIFs alike
A Pictify account and an API token from the dashboard. Two ways in: over stdio from npm as @pictify/mcp-server with PICTIFY_API_KEY set, or the hosted remote at https://mcp.pictify.io added as a custom connector, where the client ID is pictify and the client secret is your token. PICTIFY_BASE_URL moves the API base and PICTIFY_DEBUG turns on verbose logging to stderr.
One command plus a key — npx -y @pictify/mcp-server, then supply credentials