MCP server for sending physical postcards via Postcard.bot. Let AI agents send real postcards worldwide.
PostcardBot MCP server demonstrates solid tool definition quality with complete input schemas and descriptions for all 8 tools. Naming follows verb-first conventions (send_, check_, list_, create_, delete_). Descriptions are generally well-written (89-267 chars, within the 10-1024 baseline range) and explain WHAT the tool does and WHEN to use it. All parameters have type definitions and descriptions. However, several tools lack output schema documentation (not visible in source code), which prevents full assessment of response structure. Parameter constraints could be more explicit (e.g., enum for webhook event types, min/max for message length). Error handling guidance is missing from tool descriptions. The server correctly uses STDIO transport but this incurs a hard protocol readiness cap of 50.
Send the same postcard to multiple recipients (async). Same message, image, and return address for all cards — only the recipient addresses differ. Up to 5,000 recipients per request. Total cost is reserved upfront; failed cards are automatically refunded. Returns a bulk_id immediately — cards are processed in background batches. Use check_status with the bulk_id to poll progress.
Check account balance, lifetime top-up amount, and current volume pricing tier. Use this before sending to know your per-postcard cost and available funds.
Check the delivery status of a previously sent postcard. Returns the current status, delivery tracking info, and expected delivery date.
Register a webhook URL to receive postcard event notifications (sent, delivered, failed, returned). Events are signed with HMAC-SHA256. The signing secret is returned only once — save it securely. URL must use HTTPS. Maximum 10 webhooks per account.
Delete a registered webhook by its ID.
Output schemas not documented in source code. The tool descriptions state what they return (e.g., 'Returns the current status, delivery tracking info, and expected delivery date' for check_status) but the actual response structure (field names, types, required fields) is not visible. LLMs cannot plan multi-step operations without knowing the shape of returned data.
Constraint documentation uses prose examples instead of formal schema constraints. 'Event types to subscribe to: postcard.created, postcard.sent, postcard.delivered, postcard.failed, postcard.returned' should be declared as enum items. Message field states 'max 350 characters' in description rather than maxLength constraint. Image URL states format expectations in description rather than format+pattern constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Get postcard pricing tiers based on lifetime top-up amount. USA from $1.99 (<$50) down to $0.69 ($5000+), International from $2.99 down to $1.99.
List all registered webhooks for your account. Webhooks send real-time notifications to your URL when postcard events occur.
Send a physical postcard that will be printed and shipped to a real address. Delivery takes 5-10 business days. Price depends on volume tier based on lifetime top-up (from $0.69–$1.99 USA, $1.99–$2.99 international). Charged from the user's prepaid Postcard.bot balance. Use check_balance to see current pricing tier before sending. Requires an image URL (publicly accessible) and a message (max 350 characters).
Missing error handling guidance in tool descriptions. Users of these tools (especially send_postcard and bulk_send, which incur costs) need to know what can go wrong and what to do next. E.g., 'Check balance before sending if uncertain. Insufficient funds will reject the request, call check_balance to see your current tier and available balance.' Currently, descriptions do not explain failure modes or recovery steps.
No idempotency or confirmation mechanism for destructive operations. delete_webhook allows permanent deletion with no undo or dry-run option. send_postcard and bulk_send trigger real-world costs but lack a confirmation step or dry-run mode to prevent accidental ordering.
Pagination not declared for list_webhooks. Description says 'List all registered webhooks' but no limit, offset, or cursor parameters are present. If users can register up to 10 webhooks, this is acceptable, but for real-world growth (accounts with 50+ webhooks), missing pagination will cause full context window dumping.
No explicit permission scoping declared. Tools like create_webhook and delete_webhook should declare required permissions (e.g., 'admin:webhooks', 'write:account') so agents can be configured with least privilege. Current descriptions do not mention permission requirements.
check_status parameter 'postcard_id' lacks guidance on where to find the ID. Description says 'The postcard ID returned from send_postcard' but does not clarify if bulk_send postcards also return IDs or if a bulk_id must be used with check_status instead. This could confuse agents attempting to track bulk shipments.