A MCP server for scheduling and posting tweets from Google Sheets
TweetScheduler has a single tool 'schedule-tweets' with critical definition and security gaps. The tool name lacks a clear action verb, description is minimal (58 chars, well below the 194-char baseline), input schema is present but parameters lack descriptions entirely, and the implementation contains severe security vulnerabilities (hardcoded credentials, plaintext password storage, no input validation). The tool combines multiple concerns (fetch, post, update) rather than being single-purpose. No output schema is documented. Error handling is absent, the implementation has no try-catch blocks, timeout handling, or recovery guidance for the LLM.
Fetch and post tweets from Google Sheets
Tool name 'schedule-tweets' uses hyphenated verb-noun but lacks clarity on multi-step responsibility. The name suggests scheduling but the implementation posts tweets immediately and updates status, three distinct operations (fetch, post, update) should be split into separate tools. Per pattern:tool, each tool should do exactly one thing.
Tool description is only 58 characters ('Fetch and post tweets from Google Sheets'), well below the 194-char baseline and the 10-1024 character recommendation. It lacks context for WHEN to use the tool, WHAT it returns, and that it performs destructive operations (posting to Twitter). Per pattern:tool-description, descriptions must be explicit and complete enough for LLM selection.
Input schema parameters 'sheet_url' and 'sheet_name' have NO descriptions. Per the rubric, every parameter must have a description explaining what it controls; 'sheet_url' and 'sheet_name' are ambiguous without context (e.g., what format, what constraints, what happens if the sheet is not found?). Per pattern:tool-description, this is a critical gap.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Hardcoded credentials in source code: service account JSON path 'C:/Users/KIIT/Desktop/KIIT/MCP/service_account.json' is hardcoded, and Twitter username/password are hardcoded as string placeholders in post_tweet() function. Per pattern:secret-injection, credentials must never appear as parameters or in code; use server-side secret injection via environment variables or secure vault.
No output schema documented. The tool returns only a single TextContent with a count ('Processed N tweets'). No structured schema is provided to the LLM, so it cannot plan downstream operations or know what fields to expect. Per pattern:tool and rubric section D, all tools must document their return type.
No error handling or recovery guidance. The implementation has no try-catch blocks, no validation of sheet_url or sheet_name, no timeout handling for external API calls (Google Sheets, Twitter), and no error messages that tell the LLM what to do next. Per pattern:recovery-guide, error responses must guide the agent on next steps.
No confirmation step for destructive operations. The tool marks a DESTRUCTIVE risk but immediately posts tweets and updates status without a dry-run or confirmation mechanism. Per pattern:confirmation-request, irreversible operations should support confirmation before execution to prevent LLM mistakes.
Multiple responsibilities in one tool. The 'schedule-tweets' tool fetches tweets, posts them, and updates status in a single call. Per pattern:tool, each tool should have a single clear purpose. This should be split into separate tools: 'fetch_tweets', 'post_tweet', 'update_tweet_status'.
Async/await misuse: The code calls asyncio.sleep(5) in a synchronous function context (post_tweet is not declared async). This will raise TypeError at runtime. The selenium webdriver calls are also synchronous and will block the event loop, making the server unresponsive.
No input validation. The tool accepts sheet_url and sheet_name without validation (type, format, length checks). An invalid URL or non-existent sheet name should return a helpful error, not crash.
No permission checks or audit logging. The tool executes destructive operations (posting to Twitter, updating sheets) without verifying caller authority or logging who called it, when, and what happened. Per pattern:permission-gate and pattern:audit-trail, destructive tools must gate access and be fully auditable.