Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Strong foundation with well-named tools following verb_noun convention (sendEmail, createTemplate, deleteWebhook). All 24 tools have descriptions and schemas visible in index.js. Good parameter descriptions provided for most inputs. However, output schemas are NOT documented, no indication of what fields agents should expect from responses. Tool descriptions lack depth about when to use them and dependencies between tools. Some parameter descriptions are minimal (e.g., 'Message tag for organizing and filtering' could be more specific about format/length constraints). Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present and correctly applied. Error handling guidance is absent, responses do not show how agents should recover from failures. No evidence of dry-run or confirmation patterns for destructive operations.
Tools (24)
activateBouncewriteauthsource verified75/100
Reactivate a bounced email address in Postmark
createSuppressionswriteauthsource verified78/100
Add email addresses to the suppression list in a message stream
Output schemas are completely undocumented. No indication of what fields agents should expect from responses. LLMs cannot plan downstream tool calls or extract required data without knowing response structure.
Destructive tools (deleteTemplate, deleteSuppressions, deleteWebhook) lack confirmation or dry-run capability. Agents can accidentally destroy data. No error recovery guidance provided.
deleteTemplatedeleteSuppressionsdeleteWebhook
Recommendations
Document output schemas for all 24 tools. For each tool, specify: return type (object/array), field names, field types, and descriptions. Include pagination details (total count, next_cursor) for list tools. Example: 'sendEmail returns {success: boolean, messageId: string, submittedAt: ISO 8601 timestamp}'.
Add 'WHEN TO USE' and 'WHEN NOT TO USE' sections to tool descriptions for disambiguation. E.g., 'Use getMessageDetails for full bounce reason and headers. Use searchOutboundMessages to find messages by recipient or date range. Use diagnoseDelivery to see recent history for an email address.'
Implement dry-run or confirmation for destructive tools (deleteTemplate, deleteSuppressions, deleteWebhook). Pattern: add optional 'confirm=true' parameter; if false, return summary of what would be deleted without executing.
Specify constraints for date parameters: 'fromdate and todate must be ISO 8601 format (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ). todate must be >= fromdate. Max range is 365 days.'
Document batch message structure. For sendBatch, clarify: 'messages is an array of objects, each with: to (string), from (string), subject (string), htmlBody (string), textBody (string), cc (optional string), bcc (optional string), tag (optional string).'
Add recovery guidance to error scenarios. E.g., 'If 'Invalid Sender' error, call getServerInfo to retrieve verified senders and retry with a verified address.'
Expand getServerInfo description: 'Returns server configuration: name, ID, bounce hook settings, spam hook settings, delivery hook settings, inbound domain, inbound hash, and API token metadata. Call this first to understand server capabilities.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Tool descriptions lack guidance on when to use each tool vs. similar alternatives. E.g., searchOutboundMessages, getMessageDetails, and diagnoseDelivery all work with messages but the distinctions are unclear. Agents waste reasoning cycles deciding between them.
Parameter descriptions are minimal and lack format constraints. E.g., 'Message tag for organizing and filtering' does not specify max length, allowed characters, or whether it is required. 'ISO 8601 format' is mentioned for dates but not validated or constrained in schema.
Batch tools (sendBatch, sendBatchWithTemplate) do not document the expected structure of array elements. What fields does each message in the array need? Can agents construct valid payloads without trial-and-error?
No error handling guidance. Responses do not show how LLMs should recover from failures (e.g., 'If sendEmail fails with 'invalid sender', call getServerInfo to list verified senders'). Agents face blank walls on errors.
Tool dependencies are not documented. E.g., createTemplate may require knowing valid templateType values; listTemplates should be called first to discover them. Multi-tool workflows lack guidance.
getServerInfo description is minimal (50 chars). Does not explain what information it returns, when to call it, or its role in the tool ecosystem.
getServerInfo
Add parameter validation in schema definitions. Use enum constraints for trackLinks ('None', 'HtmlAndText', 'HtmlOnly', 'TextOnly'), templateType ('Standard', 'Layout'), bounce type ('HardBounce', 'SoftBounce', 'Transient'), and suppression reason ('Bounce', 'SpamComplaint', 'ManualSuppression').
Document mutually exclusive or conditional parameters. E.g., 'sendEmail: either htmlBody or textBody (or both) must be provided. trackLinks is only valid if trackOpens=true or a link tracking mode is specified.'
For listTemplates, listSuppressions, searchOutboundMessages, and searchBounces, specify pagination limits: 'count defaults to 50 (or 100 for searches), max 500. offset defaults to 0. Returns total count and has_more flag.'
Add dependency hints to descriptions. E.g., 'createTemplate: if you only have a template name, call listTemplates first to check for naming conflicts. To test before creating, use validateTemplate.'
Expand batch tool descriptions with examples of success/failure per item. E.g., 'sendBatch returns an array of results, each with messageId or error. One failure does not halt processing of remaining messages.'