An MCP server for managing social media posts, with integration to X (formerly Twitter)
This server has significant gaps in definition quality. All three tools are explicitly registered in src/index.ts with schemas and descriptions, but the quality is inconsistent. Tool names follow verb_noun conventions (post_to_x, list_x_posts, create_x_thread), which is good. However, descriptions are minimal (16-40 chars), parameter descriptions are sparse, and critical metadata is missing. The incomplete source code (CallToolRequestSchema handler cuts off mid-execution) prevents full validation of runtime behavior. No error handling guidance is visible for LLM recovery. Output schemas are not documented. The server exposes Twitter API credentials via environment variables correctly, but parameter validation logic is incomplete.
Create a thread on X (formerly Twitter)
List X (formerly Twitter) posts
Post a message to X (formerly Twitter)
Output schemas not documented. Tools do not specify what they return, fields, types, structure. LLMs cannot plan downstream calls or extract chaining IDs (e.g., thread_id from create_x_thread to use in post_to_x). Baseline: 100% of A+ tools have documented return types.
Descriptions are too short and lack context. 'List X (formerly Twitter) posts' (32 chars) does not explain when to call this vs other tools, what structure is returned, or any prerequisites. Baseline: avg tool description 194 chars (p10=34, p90=392). Most of these are below guidance.
Parameter descriptions lack actionable constraints. 'limit' has no min/max bounds (e.g., '1-100'). 'content' has no length limits or format rules. 'threadId' does not explain how to obtain one or what format it expects. LLMs cannot validate their own inputs against unstated constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No error handling guidance visible. Source code for CallToolRequestSchema is incomplete (cuts off at 'this.socialMediaPosts.filter(post => post.threadId === threa'), so error recovery patterns cannot be verified. LLMs cannot know whether to retry, ask the user, or give up on errors.
No pagination support visible. list_x_posts accepts 'limit' but no offset/cursor mechanism is documented. If a user has hundreds of posts, the tool cannot paginate. Baseline: tools returning lists must accept page/offset and limit, return total count or next_cursor.
No tool annotations. post_to_x and create_x_thread are WRITE operations (destructive) but lack destructiveHint annotation. list_x_posts is read-only but lacks readOnlyHint. These annotations help LLMs reason about side effects and safety. Pattern: tool-annotations (current spec 2026-07-28).
threadId parameter design is problematic. Parameter requires an opaque ID that users may not have. No guidance on how to obtain a thread_id or whether to use human-readable names instead. Baseline pattern: accept human-friendly identifiers (names, emails) alongside system IDs.