Loading ToolBench
MCP server for Inxmail Commerce transactional API — events, sendings, bounces, blocklist, blacklist, reactions, and delivery tracking from Claude.
Strong foundation with consistent naming patterns (all verb_noun), comprehensive descriptions for most tools, and well-structured Zod schemas. All 9 tools are explicitly registered with descriptions and input schemas. Descriptions average ~180 chars and clearly explain purpose, use cases, and prerequisites. Parameters use Zod types (z.string(), z.number(), z.record()) with descriptions. However, output schemas are not documented, responses are JSON-stringified but no structured schema is declared for downstream tool chaining. Error handling returns plain text error messages without recovery guidance or categorization. Some parameter constraints (e.g., 'max 500' for page size) are stated in descriptions but not enforced via schema constraints (no max: 500 in Zod). The single write tool (trigger_event) explicitly warns about side effects, and all other tools are read-only, which is good for safety. Missing: idempotency guidance for trigger_event (no mention of transactionId deduplication mechanism in error context), batch operations (no multi-trigger variants), and output field documentation.
Check the processing state of a previously triggered event. Use after trigger_event to verify whether the email was accepted, sent, bounced, or failed. Returns state details including any error information. Read-only.
Get detailed configuration of a single event type by its ID. Returns the event type name, description, and configuration. Use this when you already have an event type ID and need its details; use list_event_types to discover available IDs. Read-only.
Get full details of a specific transactional email sending by its ID. Returns recipient, event type, timestamps, and delivery status. Use this when you have a specific sending ID from list_sendings or get_event_state. For mail relay sendings, use get_relay_sending instead. Read-only.
Get the Inxmail Commerce API entry point. Returns HAL+JSON with _links to all available resources (sendings, bounces, blocklist, blacklist, events, etc.). Use this to discover available endpoints or verify API connectivity. Read-only, no side effects.
List bounced transactional emails. Bounces indicate delivery failures — hardbounces mean the address is permanently invalid (auto-added to blocklist), softbounces are temporary failures (e.g. mailbox full). Use this to investigate delivery issues for event-triggered emails. For mail relay bounces, use list_relay_bounces instead. Returns paginated HAL+JSON with bounce type, email, reason, and timestamps. Read-only.
Output schemas not documented. Tools return json(data) with no schema definition visible to downstream consumers. LLMs cannot infer available fields for chaining.
Pagination parameters (size, page) accepted but constraints not enforced via schema. Descriptions state 'max 500, default 200' but Zod schema has no max constraint, allowing invalid requests.
Error responses are plain text without recovery guidance or categorization. Errors do not indicate whether they are retryable, user-fixable, or fatal. Example: catch (e: any) { return error(e.message); } only surfaces the raw error message.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
List all configured transactional event types in Inxmail. Event types define the templates and triggers for transactional emails (e.g. order confirmation, password reset). Use this to discover available event type IDs before calling trigger_event. Returns paginated HAL+JSON with event type details. Read-only.
List recipient reactions (opens and clicks) for transactional emails. Use this to track engagement — who opened or clicked links in event-triggered emails. Filter by reaction type, recipient, event, sending, or date range. For mail relay reactions, use list_relay_reactions instead. Returns paginated HAL+JSON with reaction type, timestamp, and recipient details. Read-only.
List transactional email sendings (event-triggered emails only, not mail relay). Use this to audit which transactional emails were sent, to whom, and when. Filter by recipient email, event type, customer ID, or date range. For mail relay sendings, use list_relay_sendings instead. For a comprehensive delivery report including bounces and reactions, use check_email_delivery. Returns paginated HAL+JSON with sending details. Read-only.
Trigger a transactional email event, causing Inxmail to send an email to the recipient specified in the payload. This is a write operation — it dispatches an actual email. Use get_event_state with the returned transactionId to check delivery outcome. Provide a transactionId for deduplication within a 72-hour window. Returns the transaction ID and acceptance status.
trigger_event lacks explicit confirmation/dry-run pattern for this irreversible write operation. Agents cannot preview what will happen before dispatching real emails.
No documented output field mapping. trigger_event returns transactionId, but it is unclear if this is the exact field name LLMs should extract, or if the response includes nested _links or other HAL+JSON metadata. List tools mention HAL+JSON but don't describe the flattened response structure.