MCP server for Junipr APIs — screenshots, PDFs, and metadata extraction
The server has 4 tools with explicit Zod schema definitions visible in src/index.ts. Three tools (screenshot, pdf, metadata) are well-defined with detailed parameter schemas and descriptions. The fourth tool (run_tool) is defined only in the tool handler but lacks a visible input schema in the code, it references external Junipr API slugs without exposing them as enumerated options or validated inputs. Parameter descriptions are generally solid (72-250 chars, meeting baseline), but the pdf tool has a design issue: it requires either 'url' or 'html' but Zod's optional() allows both to be omitted, creating runtime validation overhead. Error handling is present (try/catch, API error parsing) but messages are generic ('Screenshot failed: {error}') rather than actionable recovery guidance. No tool uses readOnlyHint or idempotentHint annotations. The run_tool parameters are not visible, preventing full schema assessment.
Extract metadata from any webpage — title, description, Open Graph tags, Twitter Cards, JSON-LD structured data, favicon, canonical URL, and more.
Generate a PDF from a URL or raw HTML. Returns the PDF as base64-encoded data.
Run any Junipr API tool by its slug. 75+ tools available across these categories: VALIDATION & CONVERSION: address-validator, disposable-email-checker, document-format-converter, email-validator, json-to-csv-converter, markdown-to-html, mx-lookup, phone-number-validator, temporary-email-generator; ANALYSIS & PROCESSING: ai-content-detector, brave-search, domain-whois-lookup, google-position-checker, image-to-pdf, image-to-text, lighthouse-checker, multi-resolution-screenshot, pdf-ocr-tool, pdf-to-html, pdf-to-text, rag-web-extractor, resize-image, sentiment-analyzer, seo-audit-tool, tech-stack-detector, watermark-image, web-page-change-monitor, webm-to-mp4, website-performance-analyzer, website-tech-stack-detector, website-to-rss; SCRAPERS & DATA EXTRACTION: amazon-reviews-scraper, b2b-lead-scraper, bluesky-scraper, booking-scraper, capterra-reviews-scraper, contact-info-scraper, craigslist-scraper, earnings-call-scraper
Capture a screenshot of any webpage. Returns the image as base64-encoded data.
run_tool lacks visible input schema. Tool references 75+ Junipr API slugs but does not expose them as validated enum or constrained parameter. LLMs cannot discover available tools or validate inputs without enumeration.
pdf tool allows both url and html parameters to be optional, but semantically requires exactly one. The validation logic is inline in the handler (if (!params.url && !params.html)) rather than in the schema. This shifts validation burden from compile-time (Zod) to runtime, and error message does not guide recovery.
Error messages are generic and do not guide recovery. Example: 'Screenshot failed: {error}' does not tell the LLM what to do next. Should include retry strategy, common causes (rate limit, invalid URL), or escalation guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. All four tools are read-only (they do not modify state), but this is not declared. LLMs cannot infer safety properties without explicit hints.
Output schema not documented. Tools return image/PDF as base64 or metadata objects, but the response structure (fields, types) is not described in tool definitions. LLMs cannot plan downstream tool calls or extract data confidently.