Local stdio MCP server for the PixelLetter HTTPS interface: send PDF files or plain text as physical letters and faxes, with registered mail options, test mode and account balance.
Strong schema definitions with comprehensive parameter documentation. All 5 tools have clear descriptions (100-300 chars) and detailed input schemas using Zod validation. Tool names follow verb_noun pattern (send_letter, send_fax, get_account_info, cancel_order, sign_invoice). However, output schemas are not formally documented, responses are JSON-serialized but lack explicit field definitions. Error handling returns structured PixelLetterError objects with code/message/transaction, but recovery guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE, READ_ONLY, REVERSIBLE). Parameter descriptions are thorough (e.g., testMode includes safety rationale), but some advanced fields (returnAddress, control) are marked 'undocumented' or 'raw value', reducing clarity.
Cancels a submitted order by its PixelLetter order id, which is on the order confirmation e-mail. Only works while the order has not been printed yet, otherwise PixelLetter answers with error 055.
Reads the stored customer data and the current credit of the PixelLetter account. Use it before sending to make sure the balance covers the order, error 021 means the credit is too low.
Sends documents or plain text as a fax through PixelLetter, without posting a letter. Additional services such as registered mail do not apply to faxes.
Sends a letter through PixelLetter, either as ready made documents (absolute file paths, PDF preferred) or as plain text plus a recipient address that PixelLetter typesets. Optionally faxes the same document as well. Returns the result code and the transaction id.
Sends documents to the PixelLetter invoice signing service (action 4) and optionally mails the signed PDF to the invoice recipient. The account needs electronic signatures enabled once in the customer area, otherwise PixelLetter answers with error 046.
Output schemas not formally documented. Responses are JSON-serialized but lack explicit field definitions, type annotations, or pagination guidance. LLMs cannot reliably extract or chain results.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. send_letter and send_fax are WRITE operations; cancel_order is REVERSIBLE; get_account_info is READ_ONLY. Agents cannot infer safety without annotations.
Undocumented/raw API fields (returnAddress, control) reduce clarity. Descriptions state 'undocumented in public handbooks' or 'raw value for control field', forcing users to consult external PixelLetter docs. Should either hide these or provide clear guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Error recovery guidance is minimal. PixelLetterError includes code/message/transaction, but no hints on what to do next (retry, ask user, fatal). Error 021 (low credit) and 055 (already printed) are mentioned in descriptions but not in error responses.
Credentials (PIXELLETTER_EMAIL, PIXELLETTER_PASSWORD) are environment-injected, which is correct, but no scope/permission documentation. Tools should declare required permissions (e.g., 'write:letter', 'read:account') for audit and least-privilege configuration.