Loading ToolBench

Reading the current corpus…

x-mcp MCP server · F · ToolBench

x-mcp

Safety-first MCP server exposing the X (Twitter) API v2 as typed, policy-gated tools, with a two-axis policy model and 2026 pay-per-use cost controls.

2025-06-18+STDIO3 tools

39/100

Definition Quality32

Protocol Readiness47

Supportability45

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging, Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Server defines 3 tools with explicit Zod schemas and policy-gated architecture. Tool names follow verb_noun pattern (x_auth_status, x_post_get, x_usage_get). Descriptions are present but brief (20-50 chars). Schemas are declared in tooldef.ts but actual parameter definitions not visible in provided code excerpt, only type imports shown. Error handling framework exists (XError mapping, policy validation) but recovery guidance not evident in tool descriptions. Security model is strong (OAuth scopes declared, policy matrix enforced, no secrets in params). Composition is clean (single responsibility per tool). Main gaps: parameter descriptions not visible, output schemas not documented in descriptions, no pagination/limit guidance in tool descriptions.

Tools (3)

x_auth_statusread onlyauth43/100

Confirm the auth mode, granted scopes, and the policy matrix

x_post_getread onlyauthsource verified43/100

Retrieve a post by ID or URL

x_usage_getread onlyauth38/100

Get usage statistics (conditional tool)

Issues (5)

HIGHtool-description ↗

Tool descriptions are under 50 characters and lack context for LLM selection. 'Confirm the auth mode, granted scopes, and the policy matrix' does not explain WHEN to call this tool or what the output enables.

x_auth_statusx_post_getx_usage_get

HIGHconstrained-input ↗

Parameter schemas and descriptions not visible in provided code. Tooldef.ts imports Zod types but actual parameter definitions (required fields, types, constraints, descriptions) are not shown. Cannot verify if parameters have descriptions or if enums/constraints are declared.

x_auth_statusx_post_getx_usage_get

HIGHpaginated-result ↗

Output schemas not documented in tool descriptions. LLMs need to know what fields to expect (e.g., does x_post_get return post_id, author_id, created_at, engagement_metrics?). No pagination guidance visible for tools that may return lists.

x_post_getx_usage_get

Recommendations

Expand tool descriptions to 100-200 characters. Example: 'x_post_get: Retrieve a post by ID or URL. Returns post content, author info, engagement metrics, and creation timestamp. Use this to fetch full post details before replying or analyzing engagement.'
Document output schemas in tool descriptions or in a separate schema field. Specify which fields are always present vs. conditional, and include example field names (post_id, author_id, created_at, public_metrics).
Add parameter descriptions to all Zod schemas. For each parameter, state: what it controls, valid values/ranges, format (e.g., 'post_id: X API post ID (numeric string, e.g. "1234567890")'), and whether it's required.
Add recovery guidance to tool descriptions for policy-gated tools. Example: 'If denied with policy error, check X_MCP_AVAILABILITY env var and ensure required OAuth scopes are granted.'
Document the condition for x_usage_get availability. State explicitly: 'Available only when X_MCP_AVAILABILITY includes "premium-user" or higher. Returns usage stats for the current billing period.'

Spec posture evidence

Inferred effective spec: 2025-06-18+.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

39/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	39	2025-06-18+	v2