Skip to main content
Glama
Sign In
x-mcp

x-mcp

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

X diagnostics

x_meta
Read-onlyIdempotent

Diagnose X API credentials, inspect endpoint rate limits and cache behavior, and track billed post usage to troubleshoot authentication or quota issues.

Instructions

Check credentials, observed rate limits and billed API usage.

Actions (pass "action" plus that action's parameters):

  • auth_status: Diagnose credentials: which auth modes are configured, whether a user session can post/DM, token expiry and scopes, plus the effective server flags (read-only, dry-run, cache, API base).

  • rate_limits: Shows the last rate-limit window X reported for each endpoint (remaining requests and reset time), the in-memory cache hit/miss counters, and whether the server waits or fails when a buck…

  • usage: Current billing-period post consumption for the X project: the cap, how many posts have been consumed, and daily usage.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "x_meta"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesAction to perform. One of: auth_status, rate_limits, usage.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, so the bar is lower, and the description still adds real substance: it discloses that auth_status exposes effective server flags (read-only, dry-run, cache, API base), that rate_limits surfaces in-memory cache hit/miss counters, and that usage reports cap-versus-consumed. It does not say whether any credential material is redacted or whether these calls themselves count against rate limits, which are the remaining behavioral unknowns for a diagnostics tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A one-line purpose statement followed by a bulleted action breakdown is well front-loaded and easy to scan. The rate_limits entry is cut off mid-word ('whether the server waits or fails when a buck…'), which leaves an incomplete sentence and costs it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing return values, and it does so for all three actions. The only shortfall is the truncated rate_limits explanation, which leaves the wait-versus-fail behavior undefined for a tool whose whole purpose is reporting that state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum already lists the three valid values, so the baseline is 3. The description earns above baseline by explaining what each enum value actually returns, turning bare action names into meaningful choices for the caller.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb and three concrete resources ('Check credentials, observed rate limits and billed API usage'), and the action list enumerates exactly what each mode reports. Nothing here overlaps with the content-oriented siblings (x_posts, x_timelines, x_dms), so an agent can tell this is the diagnostics tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each action is framed by its diagnostic purpose ('Diagnose credentials', 'Shows the last rate-limit window', 'Current billing-period post consumption'), which gives clear implicit routing between the three modes. It stops short of explicit triggers such as 'use when a post fails with 401' or 'use before bulk posting to check quota', so it is clear context rather than full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools