x-ai-mcp

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify authentication needs (e.g., whether accessing another user's likes requires permissions), rate limits, pagination, or error handling. For a tool with no annotation coverage, this is a significant gap in transparency about how it behaves beyond basic functionality.

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

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

The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args' section with bullet-like formatting. Every sentence adds value, with no redundant information. However, the formatting could be slightly more polished (e.g., using markdown lists), and it's brief but not overly terse, earning a high score for efficiency.

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

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

Given that there is an output schema (which handles return values), no annotations, and low schema description coverage (0%), the description does a decent job by explaining the tool's purpose and parameters. However, it lacks details on behavioral aspects like authentication, rate limits, or error handling, which are important for a tool interacting with an external API like X. This makes it minimally adequate but with clear gaps in completeness.

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

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

The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'username' can be a username or user ID with a default to the current account, and 'count' specifies the number of likes with a range (1-100) and default (20). This compensates well for the schema's lack of descriptions, providing clear context for both parameters, though it doesn't cover all possible edge cases (e.g., invalid usernames).

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

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

The description clearly states the tool's purpose: 'Get liked tweets for yourself or another user.' It specifies the verb ('Get') and resource ('liked tweets'), and distinguishes it from siblings like x_like_tweet (which creates likes) and x_user_tweets (which gets user's own tweets). However, it doesn't explicitly differentiate from x_bookmarks (which retrieves saved tweets) or other retrieval tools, keeping it at a 4 rather than a 5.

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

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

The description implies usage by mentioning 'yourself or another user' and providing default values, suggesting it's for retrieving liked tweets. However, it lacks explicit guidance on when to use this tool versus alternatives like x_user_tweets (for user's tweets) or x_bookmarks (for saved tweets), and doesn't specify prerequisites or exclusions. This leaves usage context somewhat implied but not fully articulated.

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