Loading ToolBench
MCP server for creating posts on X (formerly Twitter)
Server has a single tool 'createPost' with critical definition gaps. Tool name is verb-based (good), but description is extremely minimal (18 chars, well below 34-char baseline), parameter lacks description entirely, and no output schema is documented. Input schema exists but is bare-bones. No error guidance, no security documentation, no parameter constraints. Does not meet production-grade standards.
Create a post on X formally known as Twitter
Parameter 'status' has no description. LLMs cannot infer what content is expected, length limits, formatting requirements, or examples.
Tool description is only 18 characters ('Create a post on X formally known as Twitter ') and provides no context for LLM selection. Does not explain WHEN to use it, WHAT output format to expect, or limitations (e.g., 280-char truncation). Baseline for production tools is 34-392 chars.
No output schema documented. LLMs do not know what fields the response contains, their types, or structure. Code shows response is { content: [{ type: 'text', text: string }] } but this is not declared in the tool definition.
No error handling guidance. Code catches Twitter API errors (403, 429, etc.) but tool definition provides no recovery guidance. LLM will not know whether to retry, wait, or ask the user.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
No parameter constraints. 'status' accepts any string; code truncates to 280 chars silently. LLMs should know the length limit upfront (max 280 chars, or docs say 275 + '...'). Without explicit constraint, LLM may pass 5000-char text expecting it to fail gracefully.
No idempotency guarantee documented. Posting twice with identical text creates two separate tweets. If an LLM retries due to ambiguous failure, users get duplicate posts. Code provides no idempotency key or deduplication.
Tool is marked WRITE risk but no confirmation/dry-run pattern. Agents can post arbitrary text without review. Should support a 'dry_run' parameter or confirmation step to prevent accidental posts of sensitive/embarrassing content.
Twitter API credentials (4 env vars) are injected server-side (good), but no documentation of what permissions/scopes they require. LLM has no visibility into what auth scope the tool operates under or what actions it can perform.