This server exposes 10 tools with explicit registration via Zod schemas and descriptions. Naming follows verb_noun conventions consistently (pylon_screenshot, pylon_pdf_parse, etc.). All tools have descriptions (10-70 chars, mostly adequate but brief). Input schemas are present and properly typed with Zod constraints (minima, maxima, enums, formats). However, descriptions lack depth, they state WHAT but rarely explain WHEN to use a tool vs. alternatives, and error handling is generic ('failed: {error}') without recovery guidance. Output schemas are implicit in the code (image, text, resource types) but not documented in tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being read-only. Parameter descriptions are functional but minimal; they don't explain dependencies or validation rules explicitly. Overall: solid foundation with room for maturity in LLM-facing descriptions and recovery patterns.
Generic error messages lack recovery guidance. All tools return 'Tool failed: {e.message}' without actionable next steps. LLM cannot determine if the error is retryable, requires user input, or is fatal.
Tool descriptions are brief (10-70 chars) and lack context for selection. E.g., 'Validate an email address' does not explain when to use this vs. other validation; 'Get crypto alpha alerts' does not clarify alert quality, latency, or use case (trading, research, tracking).
Output schemas are not documented in tool definitions. Code shows tools return image, text, or resource types, but the schema (fields, types, structure) is implicit. LLMs cannot plan chained calls or extract data reliably without knowing response structure.
Recommendations
Enhance tool descriptions to 50-200 characters. Include WHAT, WHEN, and any prerequisites. Example: 'Extract text and structured data from a PDF via URL. Call this to digitize documents, extract tables, or retrieve metadata (author, title, page count). Accepts publicly accessible HTTPS URLs only; returns JSON with text, page count, and detected language.'
Document output schemas explicitly in tool definitions or as separate schema comments. For pylon_domain_intel, specify: '{domain, registrar, registrant, nameservers: [{name, ip}], mx_records: [{host, priority}], created_at, expires_at}'. For pylon_alpha_alerts, specify: '{alerts: [{type, title, description, confidence: 0-1, source, timestamp}]}'.
Improve error messages with recovery hints. Replace 'PDF parse failed: {error}' with error-specific guidance: 'PDF parse failed: URL not publicly accessible. Verify the URL is HTTPS and returns a Content-Type: application/pdf header.' Or: 'PDF parse failed: Network timeout. Retry in 30 seconds.' Or: 'PDF parse failed: Invalid PDF structure. Try a different file.'
Add tool annotations to all tools. In the server.tool() call, include a fourth object parameter with hints: { readOnlyHint: true } (or similar annotation object if supported by the MCP SDK version). This signals safety and reduces agent reasoning.
For URL-accepting parameters (file_url, url), add explicit format/validation description: 'Must be a publicly accessible HTTPS URL. HTTP will be rejected. URL must resolve within 10 seconds and return appropriate Content-Type (application/pdf, image/*, etc.).'
Score history
Overall score trend
First recorded score · v2 rubric
58/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
D
58
2026-07-28+
v2
read only
auth
source verified
78/100
Extract text from an image using OCR. Provide a publicly accessible URL to the image.
pylon_pdf_parseread onlyauthsource verified78/100
Extract text and metadata from a PDF file. Provide a publicly accessible URL to the PDF.
pylon_qr_coderead onlyauthsource verified82/100
Generate a QR code image from text or a URL. Returns a PNG image.
No tool annotations despite all tools being read-only. Adding readOnlyHint=true would signal to agents and clients that these tools are safe to call without side-effect concern, reducing reasoning overhead.
pylon_domain_intel and pylon_alpha_alerts return JSON but lack schema documentation. Agents don't know what fields to expect (WHOIS response format, alert structure, confidence scores, timestamps). Chaining is blind.
Parameter descriptions for URL fields do not mention format requirements (HTTPS vs HTTP, accessibility, content-type expectations). E.g., pylon_pdf_parse says 'URL to the PDF file' but doesn't clarify if it must be publicly accessible or if authentication is supported.
pylon_pdf_parsepylon_image_resizepylon_ocr
Expand pylon_alpha_alerts description and parameter docs. Clarify: 'Returns recent on-chain signals, whale wallet movements, or new token launches. Alerts are sorted by recency. Type=latest (24h signals), whales (movements >$100k), launches (new tokens <7d old). Confidence scores 0-1 indicate signal quality. Use for research, not trading advice.'
Document rate limits and result caps. E.g., 'Returns up to 50 most recent alerts. If you need paginated results, call multiple times with different time windows.'
Add parameter dependency hints. E.g., pylon_screenshot: 'full_page=true may produce large images; consider pairing with width/height constraints to limit file size.'
For image/PDF tools, specify supported formats and size limits in descriptions. E.g., pylon_image_resize: 'Supports JPG, PNG, WebP. Max input 50MB. Output dimensions capped at 4096×4096. Aspect ratio preserved unless both width and height are specified.'
Include examples of when NOT to use a tool. E.g., pylon_screenshot is not suitable for dynamic SPAs that require interaction; suggest alternatives (browser automation, Selenium) if the user needs interactive screenshots.