Server has 8 tools with basic structure but significant quality gaps. All tools have names and descriptions, but descriptions are often generic and lack actionable context. Schemas are present and use Zod validation (good), but several tools have minimal parameter documentation. Output schemas are not documented. Error handling is weak, no guidance on retries, user-fixable vs fatal errors, or recovery steps. Tool composition is reasonable (each does one thing), but some descriptions could better explain WHEN to use each tool vs similar tools (e.g., send_smtp_email vs send_transactional_email distinction unclear). No tool has annotations beyond basic title/openWorldHint. Per-tool average: 51.3.
Tools (8)
add_subscriberwriteauthsource verified68/100
Add subscriber to a mailing list
get_listsread onlyauthsource verified62/100
Get all available mailing lists
get_single_listread onlyauthsource verified67/100
Get a single mailing list details: total count, status, etc
Output schemas not documented. Tools return content arrays with text, but the exact field structure and optional fields are never declared. LLMs cannot reliably parse responses or plan downstream tool chains.
Descriptions lack WHEN/WHY context. 'Send an email using SMTP' vs 'Send an email using transactional email service' do not explain when an LLM should choose one over the other. No guidance on prerequisites, expected use cases, or error scenarios.
Error handling absent. No tool catches or categorizes errors (retryable, user-fixable, fatal). Network failures, invalid emails, missing list IDs, and API errors will bubble up as unstructured exceptions without recovery guidance.
Expand tool descriptions with WHEN/WHY guidance. send_smtp_email: 'Send email via direct SMTP connection for custom headers or server control. Use send_transactional_email for Sitecore Send's managed transactional service.' send_transactional_email: 'Send email via Sitecore Send transactional service for tracking and bounce handling.'
Add parameter constraints and format guidance in descriptions. For 'to' and 'email' params: 'Valid email address (RFC 5322).' For 'listId': 'UUID of the mailing list (36 characters, e.g., 550e8400-e29b-41d4-a716-446655440000).' For 'tags' in add_subscriber: 'Array of tag strings; each tag 1-50 chars, lowercase alphanumeric + hyphens.'
Implement structured output. Parse text responses into JSON objects before returning. Example: get_lists should return { lists: [{ name, status, id }, ...], total: N } instead of concatenated strings.
Add pagination to get_lists and get_subscribers. Accept optional limit (default 20, max 100) and offset (default 0) parameters. Return total count and next_offset for chaining.
Add error handling with categorized recovery guidance. Wrap API calls in try/catch. For invalid emails: return { error: 'Invalid email format: must be RFC 5322 compliant', retryable: false }. For network timeouts: { error: 'API request timed out after 30s', retryable: true, suggestedDelay: 5 }. For permission errors: { error: 'API key lacks permission for this list', retryable: false, suggestedAction: 'Check API key scope in Sitecore Send dashboard' }.
Parameter descriptions incomplete or generic. 'Email address to send the email to' lacks format/validation hints. 'Tags of the subscriber' does not explain what tags mean in this domain or their format (CSV? Array? Limited set?). No constraints on required lengths.
Output results are unstructured text concatenation. get_lists returns '- Name, status: ..., (id: ...)' as plain text. No structured JSON with typed fields, making downstream parsing error-prone and wasting tokens on format negotiation.
No pagination support. get_subscribers and get_lists do not accept limit/offset or page parameters, and do not document maximum result counts. Returning all subscribers in a large list will blow context windows.
Destructive operations (unsubscribe_subscriber, send_smtp_email, send_transactional_email) lack confirmation or dry-run. Agents can irreversibly unsubscribe users or send duplicate emails without a safety mechanism.
UUID constraint for listId in get_single_list and get_subscriber_by_email uses z.string().uuid() in schema, but descriptions do not mention UUID format requirement. LLMs cannot see Zod constraints, they rely on description text.
Tool annotations minimal. Only basic title and openWorldHint provided. Missing readOnlyHint on GET tools and destructiveHint on WRITE tools, which prevents clients from applying safe defaults (caching, undo, permission checks).
For send_smtp_email and send_transactional_email, consider adding a 'dryRun' optional parameter (default false) or implement a separate validate_email_address tool to let agents preview before committing.
Document what fields are returned in list/subscriber responses explicitly. E.g. 'Returns list name, status (Active|Inactive|Deleted), subscriber count, and list ID. Does not return list owner or creation date.' This sets expectations and prevents wasted follow-up calls.
Add error message examples in descriptions. 'If listId is invalid: "List not found: verify the UUID format and that you have access to this list." If SMTP auth fails: "SMTP authentication failed: check SMTP_USER and SMTP_PASSWORD environment variables."'