Enhanced MCP Server with dual transport support (HTTP and stdio). Supports both remote API access and Claude Desktop integration. Provides tools for weather, calendar, contacts, and time management integrated with Google APIs.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Server has 22 tools with mostly clear names but inconsistent schema completeness and moderate description quality. Names follow verb_noun convention (get_weather_alerts, add_calendar_event, search_contact, etc.), which is strong. However, schemas vary significantly in completeness, some parameters lack type information in visible definitions, descriptions are generic for many tools (e.g., 'Get weather alerts for a US state.' is 39 chars, below the ideal 50-200 range), and output schemas are not documented. Error handling is minimal, no recovery guidance visible. No tool annotations (readOnlyHint, destructiveHint) detected despite tools having clear risk classifications. The server demonstrates basic organization but lacks production-grade polish in schema documentation and error patterns.
Tools (22)
add_calendar_eventwriteauthsource verified78/100
Create a new Google Calendar event with optional location and attendees.
add_new_contactwritesource verified73/100
Add a new fallback contact with the given name and email.
create_name_aliaswritesource verified77/100
Create a name alias for quick reference (e.g., 'my manager' -> '[email protected]').
Tool names with 'and' indicate multiple responsibilities, find_and_update_calendar_event and find_and_delete_calendar_event should be split into separate discovery and action tools.
Descriptions are too short (39-60 chars on average) to guide LLM tool selection effectively. Best practice is 50-200 chars with clear WHAT/WHEN/HOW context.
No tool annotations detected (readOnlyHint, destructiveHint, idempotentHint) despite tools having explicit risk classifications (READ_ONLY, WRITE, DESTRUCTIVE). These annotations are required in current spec for agent safety.
All 22 tools
HIGH
Recommendations
Split find_and_update_calendar_event into search_calendar_events (discovery) + update_calendar_event (action). Similarly, split find_and_delete_calendar_event into search_calendar_events + delete_calendar_event. This aligns with single-responsibility principle and lets agents compose these operations.
Expand all tool descriptions to 50-200 characters with explicit WHAT/WHEN/HOW guidance. Example: 'Get weather alerts for a US state' → 'Retrieve active severe weather alerts (tornado, flood, extreme wind, etc.) for a US state. Call this before weather planning or emergency response. Returns alert titles, issue times, and expected end times.'
Add tool annotations to every tool definition. Use readOnlyHint=true for GET operations, destructiveHint=true for DELETE operations (delete_calendar_event, delete_contact, find_and_delete_calendar_event), and idempotentHint=true where applicable (get_* operations, list_* operations).
Document output schemas for all tools. For example, add_calendar_event should document: 'Returns {event_id: string, summary: string, start: string (ISO 8601), end: string (ISO 8601), calendar: string, attendees: [{email: string, status: string}], error?: string}'. This enables LLMs to chain tool calls (e.g., create event → get event ID → add comment).
Implement structured error handling with recovery guidance. Example: Instead of raising HTTPException, return {success: false, error: 'User [email protected] not found', recovery: 'Try search_contact(name="John") to find their email first'}.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Create a calendar event with smart name resolution for attendees. Instead of requiring email addresses, you can provide names that will be resolved to emails. Any names that cannot be automatically resolved will be returned as unresolved_attendees.
Output schemas are not documented in tool definitions. LLMs need to know the structure of responses to plan downstream calls and extract relevant data.
No error handling or recovery guidance visible. Tools do not return actionable error messages (e.g., 'User not found. Try search_contact() first.'). Errors appear to be raw exceptions.
All tools with external dependencies (weather, calendar, contacts)
Credentials and authentication details are hardcoded in source (MCP_API_TOKEN env var with fallback 'ROCKY_MCP_TOKEN_2025'). Token validation is visible but secret injection pattern is incomplete.
All tools requiring Google Calendar/Contacts API access
No permission checks or scope declarations visible. Tools like delete_calendar_event and delete_contact execute without verifying user/agent authority or logging access.
Parameter descriptions are often generic and do not specify constraints (range, format, allowed values). Example: 'List of attendee email addresses (optional)', no validation of email format mentioned.
No pagination or result limits documented for list_calendar_events and list_contacts. Unbounded result sets could exhaust context window or cause timeouts.
list_calendar_eventslist_contactssearch_contact
Add dry-run support to destructive operations. Introduce a confirm_delete parameter (default false) that returns a preview instead of executing. Or introduce a separate preview_delete_calendar_event tool that shows what would be deleted without committing.
Add input validation and return actionable errors. For date/time parameters, validate ISO 8601 format and return clear messages. For email lists, validate email addresses and report invalid ones by position.
Implement pagination for list_* and search_* tools. Add max_results (default 20, max 100) and next_cursor parameters. Document result limits in descriptions to manage LLM expectations.
Add permission checks before destructive or write operations. Log {user_id, agent_id, action, parameters, timestamp, result} to an audit trail. Return {success: false, error: 'Insufficient permissions'} for unauthorized calls.
Document parameter constraints inline. Example: 'List of attendee email addresses (optional, max 50 per event, each must be valid RFC 5322 email format)' instead of just 'List of attendee email addresses (optional)'.
Move credentials to secure environment injection. Remove the hardcoded fallback token. Use secrets management (Vault, AWS Secrets Manager) for Google API credentials, not env vars in application code.
Add natural identifier support. allow calendar event creation by searching for attendee names (e.g., attendee_names=['John', 'Alice']) instead of requiring exact emails. smart_add_calendar_event already does this, apply the pattern to other contact-aware tools.