Loading ToolBench
MCP server for Twitter/X posting and SQL database operations with Google Generative AI integration
TweetPilot-MCP has 4 tools with minimal-to-poor definition quality. Tool names lack clear verb prefixes and are sometimes generic. Descriptions are present but very brief (under 20 characters for 2 tools, under 50 for others). Parameter descriptions exist but are terse. No output schema documentation visible. Security concerns: credentials stored as environment variables are good, but the Twitter API integration lacks error recovery guidance. Tool composition is reasonable (separate read/write operations), but naming conventions deviate from best practices.
Add a user to the SQL database (name, email)
Add two numbers
Create a post on X (formerly Twitter)
See SQL records
Tool naming lacks clear action verbs. 'seeDatabaseRecords' uses 'see' (vague) instead of 'list' or 'query'. 'addDatabaseRecords' singular vs plural is inconsistent. Best practice: use verb_noun (list_database_records, add_database_record). LLMs rely on names to infer intent before reading descriptions.
Descriptions are too brief. 'See SQL records' (14 chars) and 'Add two numbers' (15 chars) lack context. Best practice: 10 - 1024 chars with explicit WHAT/WHEN/PREREQUISITES. Current descriptions do not explain when to use each tool, expected inputs, or output shape.
No output schema documentation in code or visible in server registration. Tools return MCP content arrays but LLMs cannot see what fields/structure to expect. Without schema, LLMs cannot plan downstream tool calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 10 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 38 | - | v1 |
'createPost' tool modifies state (publishes to Twitter) but description does not warn that this is irreversible. LLMs need to know which calls have side effects. No confirmation or dry-run option present.
Parameter descriptions are minimal. 'tableName' described as 'The name of the SQL table to query', does not hint at valid table names, format constraints, or what to do if a table is not found. 'status' for createPost lacks detail on length limits, content restrictions, or character encodings.
No error recovery guidance. If Twitter API fails, database lookup returns no rows, or invalid table name is passed, tools return generic errors with no 'what to do next' guidance. Pattern: error responses must suggest recovery steps.
No pagination support visible for 'seeDatabaseRecords'. If a table has 1000+ rows, the tool will dump all to the response, bloating context. Best practice: accept limit/offset/cursor params and return total count.