A collection of multiple MCP (Model Context Protocol) servers for various services including email (Resend), SMS (Twilio), SQLite database management, DigitalOcean function deployment, and DigitalOcean App Platform management
This collection of 10 MCP servers exhibits significant quality gaps across naming, descriptions, parameter documentation, output schemas, and error handling. Most tools have minimal descriptions (under 50 chars), underdocumented parameters, and no formal output schema documentation. Several tools expose implementation details poorly and lack actionable error guidance. The use of fastmcp is commendable, but the tool definitions themselves are underspecified for production LLM use. Average tool score: 38/100.
Tools (10)
add_userwritesource verified72/100
Insert a new user with name and city
create_appwriteauthsource verified73/100
Create a new app on DigitalOcean App Platform
deploy_functionwriteauthsource verified62/100
Deploys a Python file as a serverless function to DigitalOcean using doctl.
get_app_detailsread onlyauthsource verified67/100
Get detailed information about a specific app
get_appsread onlyauthsource verified53/100
Get a list of all apps in your DigitalOcean account
ADD OUTPUT SCHEMAS: Document every tool's return type and fields. E.g., send_email returns {success: bool, message_id: string, recipient: string}. get_apps returns {apps: [{id, name, region, created_at}], total: int, cursor?: string}. This is critical for LLM planning.
RENAME 'query_data' to something domain-specific like 'execute_read_query' or split into separate tools: 'get_user_by_id', 'list_users', 'search_users_by_name'. Generic names invite misuse.
ADD SQL INJECTION DEFENSE AND DOCUMENTATION: Specify which SQL commands are allowed (SELECT only? Parameterized queries required?). Add a note: 'This tool accepts only SELECT queries with parameterized WHERE clauses. Injected SQL will be rejected.'
ADD TOOL ANNOTATIONS: Use FastMCP's @mcp.tool(annotations={...}) to mark destructive operations. E.g., send_email, send_sms, add_user, deploy_function, create_app should be marked with destructiveHint=true. Example: @mcp.tool(description='...', annotations={'destructiveHint': True}).
EXPAND PARAMETER DESCRIPTIONS: For each parameter, explain the format, constraints, and dependencies. E.g., 'requirements: Python package names as a JSON array, e.g., ["requests", "boto3"]. If omitted, defaults to empty (no deps).' For validate_phone_number, explain: 'Must include country code and start with +, e.g., +1-555-123-4567 or +441234567890.'
ADD ERROR RECOVERY GUIDANCE: Wrap errors with actionable next steps. E.g., instead of 'Error: {str(e)}', return 'Failed to send email: {error_detail}. Verify RESEND_API_KEY is set and recipient is valid.' For query_data: 'SQL error: {error}. Hint: Use schema://main resource to inspect available tables and columns first.'
Parameter descriptions missing or minimal across many tools. E.g., 'validate_phone_number' does not explain validation rules; 'deploy_function' does not explain 'requirements' format.
No error handling guidance. Tools return generic error strings ('Error: ...'). LLMs do not know if errors are retryable, require user input, or are fatal.
Pagination not implemented. Tools like 'get_apps' and 'get_deployments' return entire result sets with no limit, offset, or cursor parameters. Large results blow context window.
Descriptions are often too short (<50 chars) or generic. E.g., 'validate_phone_number' (30 chars) does not explain what format rules apply. Rubric baseline: 50-200 chars for optimal LLM parsing.
Tool composition breaks chains: e.g., 'create_app' returns undocumented structure; LLM cannot know if response contains app_id for use in 'get_deployments'. Missing ID chaining.
create_appget_app_detailsget_deployments
IMPLEMENT PAGINATION: Add limit (default 20, max 100) and offset/cursor parameters to get_apps, get_app_details, get_deployments. Return {items: [...], total: int, next_cursor?: string}. Add a note to descriptions: 'Default limit is 20. Use cursor-based pagination for large result sets.'
ADD CONFIRMATION PATTERN FOR WRITES: For send_email, send_sms, add_user, deploy_function, create_app, support a dry_run=true parameter (default false). When true, return what WOULD happen without executing. E.g., 'Would send email to user@example.com with subject "Hello". Call again with dry_run=false to execute.'
DOCUMENT CHAINING: In create_app response, include app_id and app_name so downstream calls (get_app_details, get_deployments) have what they need. Add a note to create_app: 'Returns app_id for use with get_app_details and get_deployments.'
IMPROVE SHORT DESCRIPTIONS: Expand descriptions to 50-200 chars and include WHEN to use the tool. E.g., validate_phone_number: 'Validate phone number format before sending SMS. Checks that the number includes a country code (e.g., +1, +44) and is 10-15 digits. Use this before calling send_sms to avoid failed deliveries.' get_apps: 'List all apps in your DigitalOcean account. Supports pagination (default limit: 20). Use this to discover available apps before calling get_app_details or get_deployments.'
ADD RATE LIMITING: All tools that call external APIs should document rate limits and backoff behavior. E.g., for Resend, Twilio, and DigitalOcean: 'Rate limit: 60 requests per minute. If rate limit exceeded, retry after 60 seconds.' Implement retry logic with exponential backoff.
VALIDATE INPUTS EARLY: Reject invalid enums, formats, and required parameters with clear messages before calling APIs. E.g., for deploy_function region param, validate against a hardcoded list of valid DigitalOcean regions and return 'Invalid region. Valid regions are: nyc1, nyc3, sfo1, sfo2, ...'
SEPARATE CONCERNS: If any tool does multiple things (e.g., deploy_function creates AND deploys), split into separate tools. This enables agent composition and clearer intent.