get_tweet_tweetId_favoritesReceive all likes for a tweet. Group: Tweet. Billing per call: 1 Credits.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | The default count is 20. You can specify a custom one here. | |
| cursor | No | At the end of the entries array you'll find two objects with the type TimelineTimelineCursor. There is one cursor to go up (Top) and one for going down (bottom) the list. | |
| tweetId | Yes |
Changes observed during successful MCP inspections.
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 disclosing behavioral traits. It only mentions billing credits and grouping, not what happens with the returned data, rate limits, or pagination behavior beyond the cursor parameter. It doesn't contradict annotations (none exist), but it falls short of disclosing key behaviors.
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 short but front-loaded with the primary action. However, it includes extraneous billing/group metadata that is likely available elsewhere, and it omits essential parameter context. It is concise but not optimally structured for agent usefulness.
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?
With no annotations or output schema, the description should provide more context about expected results, pagination details, and any quirks. It only states the basic action and billing. For a 3-parameter tool, this is insufficient for an agent to fully understand behavior.
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?
Schema description coverage is 67%, covering 'count' and 'cursor' but not 'tweetId'. The description adds no extra meaning beyond the schema, and the missing tweetId parameter requires inference from the tool name. This is acceptable given moderate coverage, but could improve by explaining tweetId's role.
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 retrieves all likes for a tweet, which is a specific verb+resource. It is distinguishable from sibling tools like get_tweet_tweetId_retweets and get_user_userId_likes, though it doesn't explicitly contrast them.
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 contexts (tweet-related likes) but provides no explicit guidance on when to use this tool versus alternatives. It lacks exclusions or alternative recommendations, but the purpose is clear enough that an agent can infer basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.