Server has 6 email-sending tools with complete Zod schemas and basic descriptions. All tools follow verb_noun naming (send_*). However, descriptions are minimal (10-50 chars), lack context on when to use each tool, and omit error recovery guidance. Parameters are typed but lack format constraints (e.g., email validation, attachment size limits). Output is unstructured text rather than JSON objects. No tool distinguishes itself from others, LLM must infer when to pick send_email vs send_html_email vs send_with_attachment. Error handling returns plain strings without actionable recovery steps.
Sends an email using the customer service template
Sends a simple plain text email
Sends an email with HTML content
Sends an email using the marketing email template
Sends an email using the welcome email template
Sends an email with attachments
Descriptions are too brief (10-50 chars) and lack context. 'Sends a simple plain text email' does not explain when to use send_email vs send_html_email vs send_with_attachment. LLM cannot disambiguate.
Output is unstructured plain text (e.g., 'Email sent successfully, ID: {id}') instead of JSON with typed fields. LLM cannot reliably extract email_id or status for downstream operations.
Error responses are plain strings without recovery guidance. 'Failed to send email: {error}' does not tell LLM whether to retry, ask user, or abort. No error classification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Parameters lack format constraints. 'from' and 'to' accept any string, no email validation, no guidance on comma-separated format for multiple recipients. Attachments lack size limits or MIME type validation.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are WRITE operations but lack explicit marking. LLM cannot reason about side effects or retry safety.