Vibe MCP ecosystem has 8 tools with basic schemas and descriptions, but significant gaps prevent higher scoring. All tools have input schemas and descriptions present, which meets minimum requirements. However, most descriptions are brief (under 100 chars), parameter descriptions are generic, and critical missing elements include: no error handling guidance, no output schemas documented, no tool annotations (readOnlyHint/destructiveHint/idempotentHint), no parameter constraints (enums for select fields), and no dependency documentation. The schema quality is moderate, parameters have type definitions but lack format constraints, ranges, or validation guidance. Tools lack composition clarity: for example, search_emails and read_email both operate on Gmail but their relationship and when to use each is not documented. Destructive operations (delete_email, send_email) have no confirmation or dry-run patterns. The ecosystem spans multiple packages (mcp-gmail, mcp-rag, agent-core) but inter-tool dependencies are undocumented.
No output schemas documented for any tool. Agents cannot infer what fields are returned, forcing them to guess at downstream data extraction and breaking tool chaining.
Destructive operations (send_email, delete_email) lack confirmation/dry-run patterns and have no toolAnnotations.destructiveHint. No schema guidance on irreversibility or recovery.
ingest_extracted_page parameter 'extractedPage' is typed as generic object with no nested schema shown. Agent doesn't know required fields, data types, or constraints.
Add full output schemas for all 8 tools. Document return fields, types, and structure. Example for search_emails: {type: 'object', properties: {emails: {type: 'array', items: {type: 'object', properties: {messageId: {type: 'string'}, sender: {type: 'string'}, subject: {type: 'string'}, snippet: {type: 'string'}, timestamp: {type: 'string', format: 'date-time'}}}}, total: {type: 'number'}}}
Add toolAnnotations to schema for all tools. Mark send_email and delete_email with {destructiveHint: true, idempotentHint: false}. Mark search_emails and read_email with {readOnlyHint: true}. Mark draft_email with {idempotentHint: true} if drafts are deduplicated.
Implement confirmation/dry-run pattern for destructive operations. Add optional 'confirm_delete' (boolean, default false) parameter to delete_email. Document that operation requires explicit confirmation and cannot be undone.
Expand tool descriptions to 100-200 chars minimum. Include: when to use (vs similar tools), prerequisites (Gmail auth), example use cases, and what is returned. Example for send_email: 'Send an email via Gmail. Use draft_email first if you need to edit. Requires Gmail OAuth token. Returns messageId and sent timestamp. Irreversible, double-check recipients before calling.'
Document parameter constraints and validation rules inline. Example for search_emails: 'query' → 'Gmail search query (e.g., from:user@example.com, subject:"keyword", after:2024-01-01). See https://support.google.com/mail/answer/7190 for syntax.'; 'maxResults' → 'Maximum results to return (1-100, default 10). Note: large limits may slow response.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 0 points across a rubric change (v1 → v2)
54/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
54
<=2025-11-25
v2
2026-03-09
D
54
1.13.0+
v1
send_emailwriteauthsource verified65/100
Send an email using Gmail
No error handling or recovery guidance in any tool. Descriptions lack context on failure modes, retryability, or actionable error messages.
Tool composition relationships undocumented. Agents don't know: when to call search_emails vs read_email, how ingest_extracted_page relates to search_knowledge_base, or when save_conversation_memory is appropriate.
Parameter descriptions lack format constraints, ranges, enums, and validation rules. Example: 'maxResults' has no documented range; 'query' has no documented syntax; 'messageId' has no format pattern.
Descriptions are minimal (18-85 chars). Most fall below the 100-char baseline for adequate context. Missing context on prerequisites, typical workflows, and alternative tools.
save_conversation_memory is domain-disconnected from Gmail/RAG tools and its purpose/lifecycle is unclear. Naming ('conversation exchange') is vague; composition with other tools undefined.
save_conversation_memory
Add composition documentation. Include 'Typical workflow:' sections explaining when each tool is called. Example: 'Typical workflow: (1) search_emails(query) to find candidates, (2) read_email(messageId) to fetch full content, (3) draft_email() to compose reply, (4) send_email() to deliver.'
Add error handling guidance for each tool. Include recoverable vs fatal errors and next steps. Example for delete_email: 'Error responses: messageId_not_found (try search first), permission_denied (check Gmail scope), quota_exceeded (retry later). Non-recoverable errors cannot be undone.'
Clarify save_conversation_memory purpose and lifecycle. Either: (1) rename and specialize (e.g., save_agent_insight → save structured insight to memory), (2) document how it integrates with search_knowledge_base and retrieval patterns, or (3) remove if redundant with ingest_extracted_page.
Add parameter validation and error messages at runtime. Example: if messageId format invalid, return 'Invalid messageId format. Expected Gmail message ID (e.g., 18b1234567890abc). Try search_emails first to obtain valid IDs.' instead of 500 error.
Document Gmail OAuth scope requirements for each tool. Mark read tools as requiring 'read:email' scope; send/draft as requiring 'write:email'; delete as requiring 'delete:email'. Enable least-privilege agent configuration.