x-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Every tool targets a distinct resource and action. For example, x_get_user_profile vs x_get_my_profile clearly separate public vs authenticated profiles, and x_get_user_posts vs x_get_my_timeline distinguish a user's own posts from the home feed. No two tools have overlapping or ambiguous purposes.
Naming Consistency5/5
All tools follow a consistent x_ prefix with an action_noun pattern. Actions (get, search, add, remove, like, unlike, create, update, delete) are used uniformly, and the resource nouns are clear. The consistent style makes it easy to predict tool names.
Tool Count3/5
With 22 tools, the set falls into the 16-25 range, which feels heavy. While each tool serves a distinct purpose and covers many X features, the count is above the typical well-scoped 3-15 range, making it borderline. The abundance of list-related tools (7) contributes to the heaviness.
Completeness2/5
The server covers read operations, bookmarks, likes, and full list management, but it lacks core X actions like creating posts, replying, retweeting, and following/unfollowing users. This is a significant gap that would prevent agents from performing fundamental social media interactions, limiting the server's usefulness.
Average 4/5 across 22 of 22 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already provide; it doesn't disclose idempotency behavior, authentication needs, or error handling. Annotations already indicate a non-read-only, non-destructive, idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words.
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?
For a simple mutation with only two fully-described parameters and supportive annotations, the description provides enough information for correct selection and invocation, though it omits details about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described; the description merely restates the parameters without adding extra meaning, so it meets the baseline but doesn't exceed it.
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 description uses a specific verb ('Add') and identifies the resource ('a user to a list') and key inputs ('username and list ID'), clearly distinguishing this from sibling tools like remove_list_member and create_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as remove_list_member or other list operations. The description simply states the function without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is a straightforward read operation and matches the annotations (readOnlyHint, idempotentHint, destructiveHint=false). However, it provides no additional behavioral context beyond what the annotations already convey, such as pagination behavior or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence with no redundant information. It is front-loaded with the action and target, and every word contributes meaning.
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?
The tool is relatively simple with one required parameter and no output schema. The description conveys the core purpose and the annotations cover safety and idempotency. It could specify what a 'member' includes or the return format, but given the simple context, the description is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters, achieving 100% coverage. The description adds no parameter-specific meaning, so the baseline of 3 is appropriate because the schema already handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'members of a specific list', specifying the ID parameter. It is unambiguous and likely understood in context, but does not explicitly differentiate from sibling tools like x_get_list or x_get_list_posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It only describes the basic operation without mentioning context or exclusions, leaving the agent to infer when this tool is appropriate relative to similar list-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that the response includes post text, engagement metrics, and timestamps, which is useful for setting expectations. However, it does not mention any additional behavioral details such as pagination or rate limits, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function, and contains no redundant information. Every word contributes to clarity and expectations.
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?
For a simple read-only tool with two well-documented parameters and no output schema, the description adequately covers the return values (post text, engagement metrics, timestamps). It could mention defaults like ordering, but this is a minor gap; overall sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (limit, response_format) fully documented. The description does not add any meaning beyond the schema, so the baseline score of 3 is appropriate.
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 description clearly states it fetches posts liked by the authenticated user, using a specific verb and resource. It distinguishes this from sibling tools like x_get_my_bookmarks (bookmarks) and x_get_my_timeline (timeline) by focusing on 'likes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like x_get_my_bookmarks or x_get_user_posts. The description implies its use for liked posts but does not provide comparative or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds minimal extra context by clarifying that the action is performed on behalf of the authenticated user and that the post is referenced by ID. It does not disclose side effects, error cases, or rate limits, so it provides only marginal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 12 words that immediately states the action ('Like a post') and the key qualifier ('by its ID'). It is front-loaded and contains no filler or redundant phrasing, earning its place with every word.
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?
For a simple one-parameter mutation with well-populated annotations, the description covers the essential information: what to do, what input to provide, and who is affected (the authenticated user). However, it does not mention return behavior or edge cases (e.g., already liked posts), and since there is no output schema, a bit more context about the response could be beneficial. Still, the tool is simple enough that the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage of the single parameter tweet_id with the description 'The ID of the post'. The description's phrase 'by its ID' reinforces this but adds no additional detail about the format, source, or constraints of the ID, so the schema carries the documentation burden and the description offers no further semantic enrichment.
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 description clearly states the action ('Like a post'), the resource (a post identified by its ID), and the acting principal ('on behalf of the authenticated user'). This is specific and distinguishes it from the sibling tool x_unlike_post, which performs the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It merely states what it does without mentioning scenarios, prerequisites, or exclusions. There is no reference to the sibling x_unlike_post for the opposite action, leaving the agent without comparative usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds the requirement to provide at least one field. But it does not disclose authentication needs, error cases (e.g., non-existent list), or whether the response returns the updated resource. These gaps leave the agent without key behavioral context beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and the key invocation constraint. It is concise, with no filler or redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (4 parameters, all documented) and the description covers the primary purpose and a critical usage rule. However, with no output schema, the agent is left uninformed about return values or possible error responses, which limits completeness for invoking the tool confidently in all scenarios.
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 description coverage is 100%, so the baseline is 3. The description adds the rule 'Provide at least one field to change,' which clarifies that list_id alone is insufficient and that at least one updatable field must be supplied—a constraint not enforced by the schema itself.
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 description clearly states the verb ('Update') and the resource ('an existing list'), and enumerates the specific fields affected (name, description, privacy). This distinguishes it from sibling tools such as x_create_list and x_delete_list, and from member-management tools like x_add_list_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating list metadata and explicitly instructs 'Provide at least one field to change,' which guides invocation. However, it does not explicitly contrast with alternatives (e.g., when to use x_add_list_member for membership changes), so the guidance is implicit rather than fully exclusions-based.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide key behavioral traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true). The description adds the 'authenticated user' prerequisite, which is useful context, but does not disclose additional side effects or error behavior. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded with the action and target, making it immediately clear.
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?
For a simple single-parameter tool, the description is complete: it names the resource, the authentication context, and the input method. Annotations cover safety and idempotency, and there is no output schema to explain. Minor omission is explicit error handling, but not necessary for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with a clear description of tweet_id ('The ID of the post'). The description's 'by its ID' aligns with the schema but does not add new meaning, so it relies on the schema for parameter semantics.
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 description clearly states the action ('Add') and the resource ('post to the authenticated user's bookmarks') with a specific method ('by its ID'). It distinguishes from siblings like x_remove_bookmark (removal) and x_get_my_bookmarks (listing), leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb and resource: bookmarking a post when the user wants to save it. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites beyond the implied authentication requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is clear. The description adds the specific operation but does not provide extra context such as permission requirements, side effects, or behavior when the user is not a member. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that front-loads the action and the two necessary identifiers. Every word is useful, and there is no unnecessary filler or repetition.
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?
For a simple 2-parameter tool with complete schema coverage and rich annotations covering safety and idempotency, this description is adequate. It does not need to explain return values since there is no output schema, and it conveys the core purpose clearly. It could mention permission or failure behavior, but those are not critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (list_id and username) with descriptions and validation rules. The description merely repeats the parameter names without adding additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate given 100% schema coverage.
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 description clearly states a specific action ('Remove a user from a list') and the key resource (list member), immediately distinguishing it from sibling tools like x_add_list_member and x_delete_list. It also identifies the two required identifiers, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case through its action verb, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. There is no reference to sibling tools or scenarios where a different tool should be used, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds the important context that deletion is permanent and 'cannot be undone'. It does not detail authorization needs or side effects, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, front-loaded with the action and result, with no filler or repetition.
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?
For a simple one-parameter destructive tool, the description, combined with the schema and annotations, is largely sufficient: it states what is deleted, how it is identified, and that the action is irreversible. It lacks explicit notes on return behavior, but given the low complexity and strong annotations, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter list_id, described as 'The ID of the list', and the description merely repeats that the operation is by list ID. No additional format, source, or usage detail is added beyond the schema.
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 description uses the specific verb 'delete' with the resource 'list' and the method 'by its ID', clearly distinguishing it from sibling tools like x_remove_list_member or x_update_list. It also signals permanence with 'Permanently delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when deleting a whole list by ID) but does not explicitly contrast it with alternatives such as x_remove_list_member or x_update_list. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the bar is lower. The description adds value by specifying the return fields (usernames, bios, follower counts), which is beyond the annotations and helps set expectations for output. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action ('Get a list of users who follow a specified account') followed by return value summary. No wasted words.
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?
For a simple read-only tool with complete schema and annotations, the description is adequate. It covers the main purpose and return fields, though it does not mention pagination behavior or the response_format parameter in prose (but these are in the schema). Overall complete enough for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters documented (username, limit, response_format). The description does not add additional parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
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 description clearly states the tool fetches followers of a specified account, using a specific verb ('Get') and resource ('list of users who follow a specified account'). It distinguishes from sibling tool x_get_following by focusing on followers rather than following.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a user's followers) but provides no explicit alternatives or exclusions. It does not mention x_get_following for the opposite relationship, so the agent must infer from the purpose and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation safe (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds return-value details ('usernames, bios, and follower counts') but provides no additional behavioral context like pagination, rate limits, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. Every word contributes to understanding, with no repetition or fluff.
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?
For a simple read-only list tool with clear schema and annotations, the description is adequate: it states the operation and return content. It does not explicitly disambiguate from x_get_followers, but the wording 'account follows' is unambiguous enough for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (username, limit, response_format) already described. The description adds no further parameter semantics beyond mentioning a 'specified account,' which maps naturally to the username parameter.
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 description uses a specific verb ('Get') and resource ('list of users that a specified account follows'), clearly distinguishing it from the sibling tool x_get_followers which would be users following the account. It also notes the returned fields (usernames, bios, follower counts).
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?
The description clearly states what the tool does ('users that a specified account follows'), giving the context for when to use it. However, it does not explicitly name alternatives or exclusions, such as 'use x_get_followers for users following the account.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds only the trivial detail that posts are 'recent', but does not disclose pagination or other behavioral nuances beyond what the schema (limit) already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. Every word earns its place, delivering the essential action, resource, and scope.
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?
The tool is simple, has good annotations, and the schema covers parameters and output format (via response_format). The description adequately covers the main use case; lack of output schema is mitigated by the response_format enum and the nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are self-explanatory. The tool description adds no extra meaning to parameters, so a baseline score of 3 is appropriate when the schema handles parameter documentation.
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 description uses a specific verb ('get') and resource ('recent posts from a specific list'), clearly distinguishing it from sibling tools like x_get_list (which likely returns list metadata) and x_get_list_members. The scope is tightly defined by 'by its ID'.
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?
The context is clear: use this tool when you need posts from a specific list. It does not explicitly name alternatives or emphasize when not to use it, but the purpose statement itself provides sufficient context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/destructive safety. The description adds meaningful behavioral context by stating that retweets and replies are excluded, which affects the expected result set. It does not mention pagination or error behavior, but the bar is lower given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, resource, and key filter in under 15 words, making it highly concise and structured.
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?
For a simple read-only tool with complete schema coverage and annotations, the description sufficiently covers the main scope and exclusions. It lacks explicit mention of ordering or error handling, but these are not required given the tool's simplicity and the absence of an output schema obligation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter documentation. The description adds no additional parameter-level detail beyond what the schema already provides, so the baseline of 3 applies.
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 description uses a specific verb ('Fetch') with a clear resource ('posts from a user's timeline') and adds explicit exclusions ('Excludes retweets and replies'). This clearly distinguishes it from sibling tools like x_get_my_timeline (which is likely for the authenticated user's home timeline) and x_search_posts (which searches across posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a user's posts by username, but does not explicitly state when to use it over alternatives. No exclusions or alternative tool references are provided, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, and the description does not contradict them. The description adds minimal context by specifying 'authenticated user's bookmarks' and 'by its ID,' but it does not disclose additional behavioral details beyond what annotations already cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no filler. Every word contributes to the meaning.
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?
For a simple one-param destructive tool with strong annotations, the description is adequate. It states the action, scope, and input method. It doesn't explain edge cases or return values, but with no output schema and idempotentHint present, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes tweet_id as 'The ID of the post' with 100% coverage. The description's phrase 'by its ID' adds no new semantic value beyond the schema, so the baseline of 3 applies.
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 description clearly states the action (remove), the resource (a post from bookmarks), the ownership scope (authenticated user's bookmarks), and the method (by ID). It distinguishes this from the sibling x_add_bookmark and x_get_my_bookmarks, making the tool's purpose unambiguous.
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?
The description provides clear context: use this when you need to remove a specific bookmark belonging to the authenticated user. It does not explicitly name alternatives or exclusions, but the context is sufficient and aligns with the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description's 'Create' aligns with that. However, the description adds no extra behavioral context such as side effects, auth requirements, or error conditions, which is acceptable given the simplicity but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys all necessary information without wasted words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with only 3 parameters and no nested objects or output schema. The description plus schema fully specify what the tool does. Given the low complexity and rich annotations, additional information is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description redundantly mentions 'name, optional description, and privacy setting' but does not add meaning beyond the schema. Baseline 3 applies.
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 description uses a specific verb 'Create' and resource 'X list', clearly distinguishing it from sibling tools like x_update_list and x_delete_list. It also mentions the key parameters (name, description, privacy), making the tool's purpose unmistakable.
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?
The description clearly implies the tool is for creating new lists, which is distinct from updating or deleting. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context by specifying that it returns post text, engagement metrics, and timestamps, and it notes the requirement of an authenticated user. This provides behavioral insight beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, covering the core action and the return content without any filler. Every word serves a purpose, and it is front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented optional parameters and no output schema, the description is complete: it states what the tool does, who it applies to (authenticated user), and what the response contains. Annotations cover safety hints, and the schema covers parameter details, so the description fills the remaining gap of return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'limit' and 'response_format' fully documented. The description adds no additional parameter-specific semantics beyond the schema, but it also does not need to since the schema already covers the meaning and defaults of each parameter. Baseline 3 is appropriate.
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 description clearly states the tool fetches posts bookmarked by the authenticated user, using a specific verb ('Fetch') and resource ('posts bookmarked'). It distinguishes from siblings like x_get_my_timeline or x_get_user_posts by explicitly focusing on bookmarks, and the title matches the functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when-to-use or alternative guidance. However, the clear name and description imply that this is the tool for retrieving the authenticated user's bookmarks, distinguishing it from related like-like or timeline tools. There is no explicit exclusions or alternative references, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the returned fields (bio, metrics, account info) but does not disclose additional behavioral details such as auth requirements, rate limits, or response format specifics. This matches the baseline for annotation-covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and content in an efficient manner. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no required parameters and rich annotations, the description sufficiently covers what the tool does and what it returns (bio, metrics, account info). The sibling tool context helps with differentiation, and no output schema exists, so the description's level of detail is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the only parameter (response_format) fully described in the schema. The description does not add parameter-specific meaning, but the baseline of 3 applies because the schema carries the semantic load.
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 description uses a specific verb ('Get') and resource ('authenticated user's X profile') and specifies the content ('bio, metrics, and account info'). It clearly distinguishes from the sibling tool x_get_user_profile by emphasizing the authenticated user's own profile.
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?
The phrase 'authenticated user's' provides clear context that this tool is for retrieving the caller's own profile, inherently distinguishing it from x_get_user_profile. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific return fields, which is useful but not a distinct behavioral trait beyond what annotations communicate. No additional side effects, rate limits, or auth requirements are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 17 words, front-loaded with the action verb 'Fetch.' It efficiently covers purpose, scope, and return fields with zero waste. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only profile fetcher with 2 well-schema'd parameters and no output schema, the description tells the agent exactly what the tool does and what it returns. The annotations cover safety. No significant gaps in guidance for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters (username and response_format) have descriptions in the schema. The description itself adds no parameter-level detail, so baseline 3 applies. The schema already documents the username pattern, max length, and response format enum.
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 description clearly states 'Fetch an X user profile by username' – a specific verb, resource, and identification method. It lists the returned fields (bio, follower/following counts, post count, creation date), and the username-based identification distinguishes it from siblings like x_get_my_profile.
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?
The description provides clear context: use this when you have a username for an X profile. It does not name alternatives or exclusions, but the 'by username' phrasing implies the appropriate scenario. Sibling x_get_my_profile exists, but the tool description itself is unambiguous about when it applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only/idempotent. The description adds return-value details (name, description, member/follower counts, privacy), which helps set expectations beyond the safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence stating purpose and return contents; no filler or repeated schema. It is front-loaded and efficient.
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?
For a simple read-only list endpoint, it covers purpose, scope, and return fields. It lacks pagination or ownership caveats, but these are not essential given sibling context and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, response_format, is fully documented in the schema with enum and default, so the description adds little parameter semantics. Baseline 3 applies because schema coverage is 100%.
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?
Description states 'Get lists owned by the authenticated user' – a specific verb and resource with clear scope. The mention of returned fields distinguishes it from sibling tools like x_get_list or x_get_list_posts.
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?
Clear context: it is for lists owned by the calling user, not lists generally or followed lists. No explicit alternatives or exclusions are named, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description does not need to repeat safety traits. It adds meaningful behavioral context by revealing the 7-day time window and the supported query syntax (keywords, hashtags, operators), which goes beyond the generic search intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. Every word earns its place, with no redundant or filler content.
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?
The tool has a modest complexity (3 params, no nested objects) and the annotations cover safety. The description adequately conveys the search scope and time window. While it doesn't describe return values, the response_format parameter hints at output shapes, and the tool is simple enough that a full return specification is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all three parameters. The description adds no new parameter-specific meaning beyond what the schema states; it merely echoes the query capabilities already listed in the schema's query parameter description.
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 description clearly states the tool searches for recent posts (last 7 days) matching a query, using a specific verb ('search') and resource ('posts'). It distinguishes itself from sibling tools like x_get_user_posts or x_get_my_timeline by being a general search across posts rather than a user-specific or timeline-based retrieval.
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?
The description implies usage context by noting the 7-day recency window and support for keywords, hashtags, and X search operators. It doesn't explicitly name alternatives or exclusions, but since there is no other general search tool among siblings, the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that the tool is destructive and idempotent. The description adds the behavioral context that the action is performed 'on behalf of the authenticated user', which is not captured by the annotations and clarifies whose like is removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It front-loads the action and includes all necessary context without being verbose.
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?
This is a simple one-parameter mutation with no output schema. The description covers the purpose, the scope (authenticated user), and how the post is identified. Error conditions are not described, but they are not essential for a tool with this level of simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the tweet_id parameter. The description's 'by its ID' simply aligns with the schema without adding new meaning, so the baseline of 3 is appropriate.
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 description uses a specific verb 'Remove' and identifies the exact resource ('a like from a post') and the actor ('on behalf of the authenticated user'). This clearly distinguishes it from sibling tools like x_like_post, which adds a like.
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?
The description provides clear context: it removes a like for the authenticated user, which implies when to use it. However, it does not explicitly mention alternatives or exclusions, such as 'for adding a like use x_like_post', so it doesn't reach the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows it's safe. The description adds the return field set (name, description, member/follower counts, privacy), which provides useful behavioral context about the response. It doesn't describe errors or auth, but for a simple read-only get, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence front-loads the action and resource, followed by return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, read-only annotations, no output schema). The description lists the return fields and the annotations cover safety. It's complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in the schema. The description only implicitly references list_id and doesn't add details about response_format beyond the schema, so the baseline 3 is appropriate.
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 description uses 'Get details of a specific list by its ID' which clearly identifies the verb and resource. It distinguishes from sibling tools like x_get_list_posts (posts in a list) and x_get_my_lists (all user's lists) by specifying 'specific list' and enumerating the returned metadata fields.
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?
The description implies usage when you need a single list's metadata by ID, but doesn't explicitly mention alternatives or exclusions. The context is clear enough to select it correctly, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful behavioral context by specifying reverse chronological ordering and that it includes posts from followed accounts, going beyond the annotation baseline. However, it does not cover pagination behavior beyond the schema's limit parameter or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences with no redundant information. Every word adds value, efficiently conveying the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the clear schema for its two optional parameters, and annotations indicating safe read-only behavior, the description is sufficiently complete for an agent to select and invoke the tool correctly. It states the key distinguishing feature (home timeline vs. user posts) and the ordering, which is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema provides for 'limit' and 'response_format', so no extra value is added.
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 description clearly identifies the tool as retrieving the authenticated user's home timeline in reverse chronological order, with the specific scope of posts from followed accounts. This distinguishes it from sibling tools like x_get_user_posts (which would fetch a specific user's posts) and x_get_my_bookmarks or x_get_my_likes.
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?
The description provides clear context for when to use this tool—whenever the home timeline (aggregated posts from followed accounts) is needed. However, it does not explicitly exclude alternatives or mention when to use other tools like x_get_user_posts for a single user's posts, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![x-mcp MCP server](https://glama.ai/mcp/servers/namank42/x-mcp/badges/card.svg)](https://glama.ai/mcp/servers/namank42/x-mcp)

Score Badge

Copy to your README.md:

[![x-mcp MCP server](https://glama.ai/mcp/servers/namank42/x-mcp/badges/score.svg)](https://glama.ai/mcp/servers/namank42/x-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/namank42/x-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server