Twitter241 MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation1/5
Multiple tools appear to do the same thing (e.g., get_tweet_details and get_tweet_details_v2, get_users_by_ids and get_users_by_ids_v2, search_twitter and search_twitter_v2), with no clear distinction between versions. The naming of get_list vs get_list_details vs get_list_timeline also adds confusion, making it difficult for an agent to reliably select the correct tool.
Naming Consistency2/5
Most tools follow a get_verb_noun pattern, but there are notable exceptions like autocomplete, job_details, space_details, and fetch_popular_community. The use of v2 suffixes is inconsistent, and some names are vague (e.g., get_about_account, get_list), so the pattern is not predictable across the set.
Tool Count2/5
With 47 tools, the server is heavily bloated, especially given the redundant v2 pairs. This exceeds the threshold for a well-scoped tool set, and many tools could be consolidated or removed without losing functionality.
Completeness3/5
The server covers a broad range of read-only operations for Twitter data (users, tweets, communities, lists, trends, jobs, spaces), which is fairly complete for a retrieval-focused API. However, there are no write operations (create, update, delete) and some obvious gaps like user mentions or tweet posting, but these may be out of scope for the intended use.
Average 2.5/5 across 47 of 47 tools scored. Lowest: 1.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 is passing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It reveals nothing about what happens when called, such as whether it returns profile metadata, requires authentication, or has side effects. The description is a pure tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified, not genuinely concise. The single sentence 'Get About Account' merely repeats the title and fails to earn its place by adding any informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the tool needs at least a basic explanation of what 'About Account' means and what it returns. With multiple sibling tools that likely overlap, the complete lack of contextual information makes this description wholly inadequate.
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% because the username parameter has a description (example value: MrBeast). According to the rubric, baseline is 3 when coverage is high, even though the tool description adds no parameter meaning beyond the schema. The example value is minimal but technically present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get About Account' is a direct restatement of the tool name, offering no specific verb+resource clarity or differentiation from siblings like get_user_by_username or get_user_tweets. It fails to state what 'About Account' contains or what kind of data is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools that fetch user or account data. The description gives no context about the appropriate scenario, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It provides none: no mention of return format, side effects, limits, or prerequisites. The description is just a restatement of the name and offers zero transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (four words), but this is under-specification, not conciseness. It contains no useful information and fails to even hint at the tool's purpose beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is completely inadequate. It does not explain what trends are returned, how the location is specified, what the response looks like, or any constraints. The tool cannot be effectively used based solely on this description.
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 descriptions for both parameters. The woeid description usefully points to the Get Available Trends Locations endpoint, and exclude explains its effect. However, these descriptions are minimal and the tool description itself adds no parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Trends By Location' is a direct tautology of the tool name. It provides no additional detail about what trends are, what 'by location' means, or how it differs from sibling tools like get_available_trends_locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The parameter description for woeid mentions it can be gotten from the Get Available Trends Locations endpoint, but this is not framed as usage guidance and no explicit when/when-not is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description carries the full burden of behavioral disclosure. It says nothing about what the tool returns, whether it is a read operation, any required permissions, rate limits, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It merely repeats the tool name and provides no useful information, which is not appropriate for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, a description could easily explain that this tool fetches user details by comma-separated IDs. The provided description is completely inadequate, offering no functional context or relationship to sibling tools.
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 has one required parameter 'users' with a description providing example values, achieving 100% schema description coverage. The tool description adds no additional semantic meaning, but the high coverage warrants the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Users By IDs V2' is a tautology, restating the tool name without adding any specific verb, resource, or behavior. It does not distinguish from the sibling tool 'get_users_by_ids', leaving the v2 suffix unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'get_users_by_ids'. No context about suitable scenarios, limitations, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits such as authentication requirements, pagination, rate limits, or output format. All it says is 'Get User Likes By ID', which reveals none of these details. There is no mention of pagination (even though a cursor parameter exists) or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is not concisely effective—it is an incomplete sentence ('Get User Likes By ID You can get the user(rest_id) query from...') that trails off without adding any value. The structure is broken and fails to deliver a complete thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, absence of an output schema, and the presence of a cursor parameter that is not explained, the description is severely incomplete. It does not provide enough context for an agent to understand what results to expect, how pagination works, or any behavioral nuances. The tool is ostensibly simple, but the description still leaves critical gaps.
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 description coverage is 100% for all three parameters (user, count, cursor), each with an example value, so the schema already carries the parameter meaning. The description adds nothing beyond what the schema provides, which aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'get_user_likes' and the opening phrase 'Get User Likes By ID' provide a basic sense of the operation, but the description is incomplete and does not specify what 'likes' refers to (e.g., liked tweets) or how it differs from the many other user-related tools in the sibling list. It reads as a vague fragment rather than a complete purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The only additional hint, 'You can get the user(rest_id) query from...', is truncated and offers no actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description discloses nothing about the tool's behavior. It does not mention return format, pagination behavior, required permissions, or any side effects. The agent gains no insight beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, which is not conciseness but under-specification. It omits essential details and does not earn its place as a meaningful explanation. A concise description can still be informative; this one is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only a vague three-word description, the tool is severely under-specified. There is no explanation of what 'popular community' means, how the parameters interact, or what the response looks like. This is inadequate for safe 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% since every parameter has a description. However, these descriptions are minimal (e.g., 'Example value: 20', 'Get this value from GET /community-topics'). The tool description itself adds nothing 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch Popular Community' essentially restates the tool name without adding specificity. It does not clarify whether it fetches a single popular community, a list of popular communities, or popular content within a community, nor does it distinguish itself from siblings like get_community_details or get_community_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided. The agent is left without any decision framework for choosing this tool over the many community-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention pagination via cursor, return format, rate limits, or that it likely returns tweets with media. The broken sentence 'You can get the user(rest_id) query from ...' hints at an input source but is incomplete and not useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not concise in a useful way; it is truncated mid-sentence ('...from "') and contains a double space. This is under-specification rather than effective brevity. Every sentence should earn its place, but here the content is incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a 3-parameter schema, the description must explain what the tool returns and any behavioral details. It does not explain the return value, pagination, or even what 'media' means. This is inadequate for an agent to correctly invoke 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% (each parameter has a description, albeit just example values). The description adds almost no semantic meaning beyond the schema, but the broken hint about rest_id does touch on the 'user' parameter. Since the schema already lists parameter names and examples, the baseline of 3 is appropriate despite the weak description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool name ('Get User Media By ID') without clarifying what 'media' means in this context. It does not specify that it likely retrieves tweets with media attachments, nor does it distinguish from sibling tools like get_user_tweets or get_user_likes. The truncated fragment about 'user(rest_id) query' adds confusion rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention scenarios such as 'use this to fetch media tweets' or contrast with get_user_tweets or get_user_likes. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 fails to mention any side effects, required permissions, rate limits, or return format, and offers no insight into how the search behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified; it is not a model of conciseness because it conveys no useful information beyond the name. This is under-specification rather than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is severely inadequate. It does not explain the search's purpose, how filters combine, what the response contains, or how to use the tool effectively.
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 schema provides example values and some enum-like constraints, but the tool description adds no additional parameter semantics beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Jobs' is a tautology that merely restates the tool name, providing no additional specificity about the tool's scope or behavior. It does not differentiate from sibling tools like search_job_locations or job_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_job_locations or search_twitter. The description gives no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It says 'Explore' but does not state whether this is a read operation, whether it returns a paginated list, or any side effects. The tool's behavior is completely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Explore Community Timeline' is extremely short but under-specified. It is not concise in a useful way; it omits essential information that should be front-loaded. The description would be acceptable only if it were a title, but it fails as a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has two parameters, no output schema, no annotations, and many sibling tools. The description provides virtually no context about return values, pagination behavior, or relationship to other community endpoints. It is far too incomplete for an agent to invoke it 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 coverage is 100% (both parameters have description fields), so the baseline is 3. However, the descriptions are only example values ('4', empty) and the tool description adds no meaning beyond the parameter names cursor and topicId. While the description doesn't help, the schema technically covers the fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Explore Community Timeline' merely restates the tool's name in a different form, acting as a tautology. It doesn't specify what the timeline contains (e.g., posts, tweets) or how it differs from siblings like get_community_tweets. This lacks clear verb+resource+scope.
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 on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusion criteria. The description gives no situational signals, making it impossible for an agent to choose this over sibling timeline tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It says nothing about side effects, permissions, rate limits, or return format. The name implies a read operation, but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise or well-structured. It contains extra spaces, a redundant 'By ID', and is clearly truncated mid-sentence. It fails to deliver a complete, self-contained explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no annotations, no output schema, and a broken description. It provides almost no context for an agent to understand the tool's purpose, inputs, or behavior, making it inadequate for correct 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%, but the descriptions are merely example values (e.g., '377228272', '20'), not meaningful semantics. The tool description adds no real parameter meaning, so it does not exceed the baseline set by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Get Organization Affiliates By ID' gives a clear verb and resource, but the description is fragmented and incomplete, ending mid-sentence. It does not effectively distinguish from siblings, though no sibling is obviously related to organization affiliates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The truncated hint about obtaining the user(rest_id) query is the only contextual clue, but it is incomplete and does not explain use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the name and gives a vague '(Rest IDs)' qualifier. There is no information about authentication, rate limits, return format, or any side effects. This offers essentially no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it is under-specified. It is essentially a title rather than a helpful description. It fails to provide any detail that would help an agent understand the tool's behavior or parameters, so it is not appropriately sized for the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only source of behavioral and usage context. It does not explain what 'Users By IDs' means, how the IDs are formatted, what the return value is, or how it relates to sibling tools. This is wholly inadequate for reliable tool selection.
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 one parameter 'users' with a description example '2455740283,44196397', so schema description coverage is 100%. The tool description adds no extra meaning, but per the rubric, a high schema coverage baseline yields a score of 3 even without parameter info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Users By IDs (Rest IDs)' essentially restates the tool name. It mentions the verb 'Get' and resource 'Users', but adds no meaningful distinction. The parenthetical 'Rest IDs' hints at the ID type but is vague. It does not differentiate from the sibling tool 'get_users_by_ids_v2'.
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. There is no mention of use cases, exclusions, or comparisons to sibling tools like 'get_users_by_ids_v2'. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 behavior. It discloses nothing beyond the tool name—no mention of pagination via cursor, required count, result format, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not effectively concise—it is under-specified. It consists of only the string 'Search community', which restates the tool name and provides no informative content, so the single sentence fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description should explain what searching a community means, how the query and count are used, and how cursor pagination works. The current description is completely inadequate for an agent to use this tool 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?
The schema has 100% description coverage for all three parameters, so the baseline is 3. Although the parameter descriptions are only example values and add little semantic meaning, the schema at least documents the parameter names and required status, and the description adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search community' is a near-verbatim restatement of the tool name and provides no additional specificity about what is being searched, what kinds of communities are included, or what the result represents. It does not distinguish the tool from sibling tools like search_twitter, search_lists, or search_jobs.
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 gives no indication of when to use this tool versus the many sibling search-related tools. There is no mention of intended use cases, limitations, or alternatives, leaving the agent with no guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Get', implying a read operation, and provides no information about output format, rate limits, authentication, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification, not conciseness. It does not earn its place as it merely restates the tool name with no additional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and no output schema, the description should explain what 'details' includes or clarify the multi-tweet behavior. It remains vague and incomplete, especially with so many sibling tools that overlap in functionality.
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 fully covers the single parameter tweetIds with an example of comma-separated IDs, so the description does not need to add much. The parameter name is self-explanatory, and the example clarifies the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a sentence-form restatement of the tool name, adding no new information. It fails to distinguish this tool from siblings like get_tweet_details or get_tweet_details_v2, which also fetch tweet details.
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 usage guidance is provided. There is no indication of when to use this tool versus the many sibling tools for similar purposes, nor any mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention pagination (despite a cursor parameter), rate limits, authentication needs, or what happens on errors. The only behavioral hint is the action 'Get', but that is already implied by the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be seen as concise, but it is incomplete and ends abruptly mid-sentence. The structure lacks front-loaded key information beyond the first phrase, and the trailing fragment is not just wasteful but confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide complete behavioral context. It only states the core function and a broken hint about the query parameter. This is severely inadequate for a tool with three parameters and a pagination cursor, especially in a large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides example values but no semantic explanations. The description adds the context that the 'user' parameter is a 'rest_id', which is marginally useful, but the sentence is cut off. Given the high schema coverage (100%) at a shallow level, the description should have elaborated on how to construct the query, but fails to do so meaningfully.
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?
The description starts with 'Get User Verified Followers By ID', which is a specific verb+resource that clearly indicates the tool's function. It distinguishes from sibling tools like get_user_followers and get_user_followers_ids by explicitly noting 'Verified', though it does not elaborate on how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The truncated sentence about obtaining the user(rest_id) query provides no usable context for selecting this tool over siblings, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves community details, without specifying what data is returned, any authentication requirements, rate limits, or potential side effects. The description adds no behavioral context beyond the tool's name.
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 zero wasted words. It is efficiently structured, though this brevity comes at the cost of substantive content, which is more appropriately penalized under other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no output schema), the description still falls short. It does not explain what 'details' means or what the response contains, and it doesn't help differentiate from the many similar get_community_* tools. The description is too minimal to provide adequate contextual completeness.
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 fully describes the single parameter `communityId` with an example value, achieving 100% schema description coverage. The description adds no new semantic information about the parameter beyond what is already present in the schema, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Community Details by Community ID' is essentially a restatement of the tool name, with no additional specification of what 'details' entails. It fails to distinguish from sibling tools like get_community_about or get_community_timeline, making the purpose vague beyond the literal 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?
There is no guidance on when to use this tool versus the many other community-related tools. The description provides no context about what makes this the right choice, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only implies a read operation but gives no information about return format, pagination, data scope, or potential side effects. No meaningful behavioral traits are disclosed beyond the word 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which contributes to conciseness, but it is under-specified. The single phrase adds little value beyond the tool name and does not earn its place as a meaningful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling community tools and the absence of an output schema, the description is severely incomplete. It leaves the agent uncertain about what 'topics' refers to, what data is returned, and how this endpoint relates to other community functions.
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?
The tool has zero parameters, and the schema is empty. The description adds no parameter-level detail, but there is nothing to describe. The zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Get Community Topics' identifies a getter resource but does not define what a 'topic' is or how it differs from sibling tools like get_community_tweets or get_community_timeline. It is clear at a surface level but lacks the specificity needed to distinguish it from similar community-related getters.
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 on when to use this tool versus the many related community tools (details, tweets, timeline, members, etc.). There are no stated exclusions, alternatives, or contextual hints for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does, not how it behaves—no mention of pagination via cursor, response format, rate limits, or authentication requirements. This is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient but under-specified for a tool with three parameters and no additional context. It is not verbose, but it fails to include necessary details, making it less than ideal in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and no annotations. The description is very brief, leaving unclear what the output looks like, how pagination works, and when to use this over the v2 variant. It is incomplete 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%, so the baseline is 3. The description adds minimal semantics beyond the schema—it only implies the tool is keyed by Post ID. It does not explain the role of cursor or relationships between parameters, but the schema already documents each parameter.
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?
The description clearly states the action (Get), the resource (Post Comments), and the key parameter (Post ID). It does not distinguish from the sibling tool get_post_comments_v2, so it loses a point for lack of differentiation.
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 on when to use this tool versus alternatives like get_post_comments_v2. The description lacks any context about selection criteria or exclusions, leaving the agent without directional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides no information about pagination, rate limits, response shape, or ordering. The only extra detail is a truncated hint about the user ID source, which is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. The trailing sentence appears truncated ('from "'), making it feel broken and unpolished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should explain what the tool returns (e.g., list of reply tweet objects) and any relevant filtering or pagination. It does neither, leaving the tool underspecified for an agent.
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 covers all 3 parameters at 100% coverage, so the baseline is 3. The description adds minor context by indicating the 'user' parameter is a rest_id, but the hint is incomplete and adds little beyond the schema's example value.
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?
The description clearly identifies the verb 'Get' and resource 'User Replies' with a 'By ID' qualifier, making the basic purpose understandable. However, it doesn't distinguish this v2 tool from its sibling 'get_user_replies' and the trailing hint is cut off.
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 like get_user_replies or get_user_tweets. The description gives no context about appropriate use cases or scheduling.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Suggest Job Locations' without explaining whether the tool returns a list, how the query is matched, case sensitivity, sorting, pagination, or any other behavioral traits. This is insufficient for an agent to know what to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short ('Suggest Job Locations'), which is concise, but this is under-specification rather than effective conciseness. It lacks the necessary details to be useful and does not earn its place as an adequate tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is still incomplete. It does not explain the format or nature of suggestions, how to use the query parameter, or how this tool relates to sibling tools like search_jobs. With no annotations or output schema, the description needs to provide more context than it does.
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 covers the 'query' parameter with an example value 'CA', and the tool description does not add any extra meaning. Since schema description coverage is 100%, the baseline of 3 is appropriate; the description does not enhance the schema's parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Suggest Job Locations' uses a verb ('Suggest') and a resource ('Job Locations'), but it is vague about what 'suggest' means and how it differs from sibling tools such as search_jobs or get_available_trends_locations. The tool name 'search_job_locations' is more specific than the description, indicating a lack of clear scope.
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 about when to use this tool or how it relates to alternatives. There is no mention of autocomplete use cases, integration with search_jobs, or exclusion criteria for other location-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The two-word description discloses no behavior, such as what is searched, how results are returned, or any side effects. This is a significant lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It essentially restates the tool name and provides no additional information. This is not effective conciseness but rather minimalism that sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema, but the description fails to explain what a list is, what the search returns, or any constraints. The sibling tools provide some context, but the description is inadequate on its own.
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 'query' parameter with an example value, so the baseline is 3. The description adds no additional meaning beyond the schema, but it does not need to compensate given the high schema coverage.
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?
The description 'Search lists' clearly states the action 'search' and the resource 'lists', which distinguishes it from sibling tools like get_list_details or search_twitter. However, it is minimal and does not specify what type of lists or any search parameters beyond 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any context, exclusions, or alternative tools, leaving the agent without clear direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details about authentication, rate limits, pagination, or response format. It simply states what the tool searches, without revealing how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short fragment, which is concise, but it is under-specified rather than appropriately sized. It lacks necessary detail for a tool with four parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a vague parameter list, this tool requires a much more descriptive explanation. The single phrase leaves out pagination, return structure, and any operational context.
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 has 100% coverage because every parameter has an 'Example value' field, but those examples are sparse (e.g., empty strings). The description hints at possible values for 'type' by listing categories, but does not explicitly map them to parameters, adding only marginal value.
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?
The description clearly identifies a search tool for Twitter with specific categories (Top, Latest, Videos, Photos, People). It uses a specific verb and resource, but does not differentiate from the sibling tool 'search_twitter'.
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 offers no guidance on when to use this tool versus alternatives like search_twitter or other search-related tools. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It merely states the tool's purpose without disclosing behavior such as the format of suggestions, whether it performs network requests, or any side effects. The description adds no transparency beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (five words) and front-loaded, but it is incomplete as a sentence and contains a typo. While conciseness is a positive, it sacrifices clarity and completeness, making it minimally acceptable rather than well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should at least explain what the tool returns (e.g., a list of suggestions) and how the input is used. The current fragment leaves the agent to guess the expected behavior, making it incomplete in context.
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 a single parameter 'value' with an example ('MrB'), providing some semantics. Schema description coverage is 100%, so the baseline is 3. The tool description does not add any additional meaning about how the parameter affects autocomplete behavior, but the example gives a hint.
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?
The description 'Twitter Seach Query Autocomplete' clearly identifies the tool's purpose: providing autocomplete suggestions for Twitter search queries. It distinguishes itself from sibling tools like search_twitter by focusing on the autocomplete step rather than executing searches. However, it is a noun phrase rather than a full sentence with a verb, and contains a typo ('Seach').
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 on when to use this tool versus alternatives. The description does not mention context, preconditions, or how it relates to other search tools. Without explicit usage instructions, the agent must infer the appropriate scenario.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action and resource, with no mention of pagination, output format, rate limits, or side effects. The vague phrase 'V2' hints at a version difference but gives no behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short phrase that essentially restates the tool name. While it is concise, it is under-specified rather than effectively condensed, providing no additional structure or front-loaded value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is severely incomplete. It fails to mention pagination (cursor, count), sorting (rankingMode), response format, or differences from 'get_post_comments'. The description is insufficient for an agent to use the tool 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% per context signals, so the baseline is 3. The schema provides example values for pid, count, cursor, and an enum for rankingMode. The description itself adds no parameter meaning, but the schema already carries the weight.
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?
The description 'Get Post Comments By Post ID V2' clearly states the action (get) and resource (post comments) with an identifier (post ID). However, it does not distinguish itself from the sibling tool 'get_post_comments', so it lacks sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as 'get_post_comments' or other comment-related tools. The description provides no context, prerequisites, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a one-line description, the tool's behavior is not disclosed. It doesn't mention what 'details' include, whether data is returned as a single object, pagination, or any side effects. The description carries the full burden and fails to provide meaningful transparency.
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?
The description is a single concise sentence with clear structure, front-loading the action and parameter. It is efficient but may be slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 description is too sparse. There is no output schema, and the description doesn't explain what fields or data structure are returned, error conditions, or any prerequisites other than listId. It leaves too many gaps for a user to understand the full context.
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 covers 100% of parameter semantics, with the listId description providing clear guidance on how to obtain the value from lists[x].object_id in the search-lists endpoint. The description adds no extra 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves list details by listId, a specific verb and resource. However, the presence of sibling tool 'get_list' with a similar purpose means it doesn't differentiate from alternatives.
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 on when to use this tool versus alternatives like get_list, get_list_timeline, or search_lists. The description simply states the action without any contextual usage information.
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?
With no annotations, the description must carry the behavioral disclosure burden, but it fails to mention the return format (full user objects vs IDs), pagination via cursor, authentication requirements, or any rate limits. The truncated rest_id instruction does not disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but ends with an unfinished sentence ('from "'), which is a structural failure. This is not concise communication but rather an incomplete thought that harms comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 output schema and no annotations, the description should at least explain what the tool returns and how pagination works. It also needs to clarify how it differs from get_user_followers_ids, but instead leaves significant gaps due to truncation.
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 descriptions are only example values (100% coverage), so baseline is 3. The description adds a marginally useful hint about 'user(rest_id)' but is incomplete, and count/cursor semantics remain unexplained except by examples.
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?
The description states 'Get User Followers By ID', which clearly identifies the action and resource. However, it does not distinguish this from sibling tools like get_user_followers_ids or get_user_verified_followers, and the truncated sentence about rest_id adds ambiguity rather than clarity.
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 on when to use this tool versus alternatives. The partial sentence 'You can get the user(rest_id) query from' seems to be a prerequisite hint but is cut off and does not address tool selection.
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?
No annotations are provided, so the description bears the full burden. It only implies a read operation via 'Get' but does not disclose pagination (cursor), response format, rate limits, or whether followings are returned as user objects or IDs. This is insufficient for a tool with similar siblings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured. It contains a malformed second sentence that ends abruptly with a quote, likely due to truncation. This disrupts readability and makes it seem incomplete rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must explain return values and behavior, but it does not. It fails to clarify what 'followings' contains, whether pagination is used, or how it differs from get_user_following_ids. The tool is ambiguous in the context of many sibling tools.
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 baseline is 3. The description adds a minor semantic hint that 'user' is the rest_id, but it does not explain 'count' or 'cursor'. The schema examples ('Example value: 2455740283') are not explanatory, but the high coverage keeps the score at baseline.
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?
The description states 'Get User Followings By ID' which clearly identifies the action (get) and resource (user followings) with an input identifier. However, it does not specify whether the return includes full user objects or just IDs, and it does not differentiate from sibling tools like get_user_following_ids. The truncated second sentence further reduces clarity.
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. The incomplete phrase 'You can get the user(rest_id) query from' hints at obtaining the input but does not explain tool selection. There are no explicit exclusions or alternative tool references.
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?
With no annotations provided, the description must disclose behavioral traits, but it only states the action and a truncated note about the user ID source. It does not mention that this is a read-only operation, pagination behavior, rate limits, or any side effects. The incomplete sentence further reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but appears truncated, ending with an opening quote and incomplete clause. It lacks proper structure and leaves a dangling reference, which harms clarity. While brevity is positive, this is under-specification rather than intentional conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and a sibling v2 variant, the description is incomplete. It fails to explain pagination via cursor, count semantics, or what constitutes a reply in this context. The missing differentiation from get_user_replies_v2 is a significant gap for an agent selecting the correct 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?
The schema has 100% coverage with each parameter having an 'Example value' description, which meets the baseline for high coverage. The description adds a small semantic cue by referring to 'user(rest_id)', clarifying that the user parameter expects a rest_id. However, count and cursor are left unexplained beyond their example values, so the description only partially compensates for the schema's lack of rich semantic detail.
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?
The description opens with 'Get User Replies By ID', which clearly states the action (get) and resource (user replies) with a specific identifier (ID). This makes the tool's purpose immediately understandable. However, it does not distinguish itself from the sibling tool get_user_replies_v2, which appears to serve the same purpose with a different version; thus it lacks sibling differentiation.
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 explicit guidance on when to use this tool versus alternatives. The fragment 'You can get the user(rest_id) query from' implies a prerequisite but is incomplete and does not clarify use cases, exclusions, or comparisons to siblings like get_user_replies_v2 or get_user_tweets. This is effectively no usable guidance.
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?
With no annotations, the description fails to disclose important behavioral details such as authentication requirements, response format, pagination behavior with cursor, or rate limits. The only added context is the note that the user parameter takes a rest_id, which is already partially indicated by the parameter name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, which is good, but it appears truncated (ending with 'from "'), resulting in an incomplete thought. It is not well-structured and the double space and unclear quotation marks detract from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and minimal annotations, so the description should explain what the tool returns and how the parameters work. It fails to mention return value structure, pagination, or any prerequisites beyond the vague rest_id hint. For a 3-parameter tool with no other documentation, this is insufficient.
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 provides only example values, not true semantic descriptions, despite high coverage. The description adds a small clarification that the user parameter expects a 'rest_id', but does not explain count or cursor parameters (e.g., that cursor is used for pagination). Given the high coverage metric but shallow schema descriptions, the description offers minimal supplementary meaning.
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?
The description clearly states the action 'Get' and resource 'User Tweets' with a method 'By ID', distinguishing it from sibling tools that handle other user resources or tweet details. However, the phrasing is slightly ambiguous about whether the ID refers to the user or the tweet, though the subsequent hint about 'user(rest_id)' clarifies it refers to the user.
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 on when to use this tool versus alternatives like get_user_replies or get_tweet_details. The description only gives a truncated hint about obtaining the user rest_id, without exclusions or alternative recommendations.
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?
No annotations are provided, so the description must carry the full burden. It only says 'Get', which implies read-only, but offers no details about return format, content of 'About', permissions, or error behavior. This is insufficient for a tool with no structured safety metadata.
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 one short sentence that is front-loaded with the verb and resource. There is zero wasted text, making it appropriately concise for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and many sibling tools, the description is too sparse. It does not clarify what 'About' contains, how it differs from 'details', or what the response looks like. The lack of behavioral and comparative context leaves the agent under-informed.
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 single parameter communityId is fully described in the schema with a type and example value (100% coverage). The description adds no extra meaning beyond restating that the tool operates by community ID, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get Community About' and specifies the input key 'by Community Id'. It is a specific verb+resource, but it does not distinguish from sibling tools like get_community_details, which may overlap in function.
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?
There is no guidance on when to use this tool versus alternatives such as get_community_details or get_community_timeline. No context or exclusions are provided.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get Community Members' and does not mention pagination (despite the cursor parameter), rate limits, required permissions, return format, or any side effects. The 'get' implies read-only, but this is not explicit.
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 that is front-loaded with the core action and target parameter. There is no wasted wording, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. It does not explain pagination (cursor), potential return structure, or usage context. For a list-returning tool with a cursor parameter, the description is insufficiently complete.
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% (both parameters have descriptions), so the baseline is 3. The tool description mentions communityId but not cursor, and the schema descriptions are only example values, adding minimal semantic meaning. No additional parameter context is provided in the description.
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?
The description clearly states the tool retrieves community members using a community ID, with a specific verb and resource. However, it does not explicitly distinguish this from sibling tools like get_community_moderators or get_community_timeline, which also retrieve community-related data.
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. Given the many community-related sibling tools, an agent would not know if this is the right choice for fetching members vs. moderators or other community data.
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?
With no annotations, the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but it does not mention pagination behavior, sorting defaults, required authentication, rate limits, or what data is returned. This is minimal disclosure at best.
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 words. It is appropriately concise for the limited information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and absence of an output schema, the description should compensate by explaining the tool's behavior in more detail. It does not clarify how searchType and rankingMode affect results, how cursor-based pagination works, or what the returned data looks like, leaving the tool under-specified for an agent.
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 for all 5 parameters, each with at least an example or allowed values (e.g., 'Default or Media' for searchType, 'Relevance or Recency or Likes' for rankingMode). The description adds no extra semantic meaning beyond naming communityId, 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.
Purpose4/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 ('Community Tweets') and identifies the key input ('by Community ID'), so it clearly states what the tool does. However, it does not distinguish itself from the similar sibling tool 'get_community_timeline', so it falls short of a perfect 5.
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 the many community-related siblings, nor any exclusions or alternatives. It simply repeats the operation without contextualizing its appropriate use.
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?
No annotations are present, so the description carries the full burden. It only says 'Get', implying a read operation, but discloses no behavioral traits such as return format, pagination, authentication, or rate limits.
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?
The description is a single, concise phrase with no fluff. While not over-long, it lacks additional structure or context, which is a slight limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description should clarify what 'highlights' are and what response to expect. It does neither, leaving an incomplete understanding for the agent.
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 a baseline of 3 applies. The description adds minor clarity by suggesting the user parameter is an ID ('by ID'), but it does not explain the count or cursor parameters beyond their examples.
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?
The description clearly identifies the action (get) and resource (user highlights) with a scope (by ID). It distinguishes from sibling tools like get_user_tweets by specifying 'highlights', though it doesn't elaborate on what highlights are.
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 on when to use this tool versus alternatives. With many sibling get_user_* tools, an agent could confuse highlights with other user data. The description gives no exclusions or alternative tool references.
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?
No annotations are provided, and the description does not disclose behavioral traits beyond the obvious read operation. It doesn't mention pagination via the cursor parameter, the shape of the returned timeline, or any rate-limit/auth requirements.
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 that is front-loaded with the key verb and resource. It is minimally sized and contains no fluff, though it sacrifices explanatory depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must carry the burden of explaining return values and usage context. It fails to do so—no mention of what the timeline contains, how cursor pagination works, or expected output format.
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 full descriptions for both parameters, including the source of listId and the cursor parameter. The description adds no additional semantic meaning beyond naming listId in the summary, so it does not exceed the schema's coverage.
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?
The description uses a specific verb ('Get') and resource ('list timeline') and names the required parameter ('by listId'). It clearly identifies the tool's function, though it does not explicitly differentiate from sibling tools like get_list_details or get_list_members.
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. It only states what it does, without any context on prerequisites, exclusions, or comparisons to sibling get_* tools.
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?
No annotations are provided, and the description discloses no behavioral details such as read-only status, pagination through the cursor parameter, or the shape of the response. The only information is the action itself, which is already implied by the tool name.
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?
The description is a single sentence with no filler, making it easy to parse. However, it is so terse that it omits necessary context, but that is more a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what the tool returns or any pagination behavior, but it only restates the tool's purpose. The presence of a cursor parameter suggests pagination, yet no guidance is given.
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 has descriptions for all parameters, but they only contain example values, not semantic meaning. The tool description adds that 'pid' is the post ID, but 'count' and 'cursor' remain under-specified.
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?
The description uses the verb 'Get' and specifies the resource 'Post Retweets' and access path 'By Post ID', making the core action clear. However, it does not explicitly differentiate from sibling tools like get_post_quotes or get_post_likes, though the term 'retweets' is distinct.
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 over alternatives such as get_post_quotes or get_post_likes. No context, prerequisites, or selection criteria are given, leaving the agent without a basis for tool choice.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning what data the details include, whether the operation is read-only, any authentication requirements, or rate limits. This is similar to the 'update_drive' example that scored 2 for lacking critical behavioral context.
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?
The description is a single, concise sentence that is front-loaded and free of unnecessary words. It earns its place by stating the core action, though it could be enhanced with additional relevant details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is minimal. With no output schema and no annotations, it fails to convey what 'details' means in practice or how this v2 differs from the sibling 'get_tweet_details'. This is incomplete for an agent to fully understand the tool's behavior and output.
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 provides a parameter 'pid' with only an example value, which is not semantically informative. The description's phrase 'By Tweet ID' clarifies that 'pid' is the tweet ID, adding meaning beyond the schema. Since the description covers the intent of the sole parameter, a baseline score of 3 is appropriate.
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?
The description 'Get Tweet Details By Tweet ID' uses a specific verb and resource, clearly indicating a single-tweet lookup by ID. However, it does not distinguish itself from the sibling tool 'get_tweet_details', which likely serves a similar purpose, so it falls short of a 5.
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 on when to use this tool versus alternatives such as 'get_tweet_details' or 'get_tweets_details_by_ids'. The description implies usage (provide a tweet ID) but lacks explicit context, exclusions, or alternative recommendations.
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?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the basic action and offers no details on what is returned, whether authentication is required, case-sensitivity, error handling, or any side effects. For a read operation, some context is expected, but even the return format is not hinted at.
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?
The description is a single sentence with no wasted words, making it extremely concise and front-loaded. However, it is so brief that it borders on under-specification—it essentially restates the tool name without additional structure or context.
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?
For a simple getter with one fully-documented parameter, the description is minimally viable. However, the lack of output schema and annotations means the description should provide more context about what the user object includes or any caveats. It is enough for a basic lookup but lacks completeness in a broader toolbox context.
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 description covers 100% of parameters, providing an example value ('MrBeast') that clarifies the expected format. The description itself adds no parameter information, but since the schema is complete, the baseline of 3 is appropriate.
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?
The description clearly states the action ('Gets') and the resource ('a user by username'), which aligns with the tool name. It is specific enough to distinguish from siblings that operate on user-related data like tweets or followers, though it doesn't explicitly differentiate from other user-lookup tools such as get_users_by_ids.
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 doesn't mention whether to prefer this over get_users_by_ids, or any context about use cases, prerequisites, or conditions. This is a clear gap given the large number of sibling tools.
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?
No annotations are provided, so the description carries the full burden. 'Get' implies read-only, but the description does not disclose auth requirements, rate limits, pagination, response format, or any other behavioral traits. This is insufficient for a tool with no 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it is essentially a restatement of the tool name. It under-specifies the tool's purpose and lacks any structural cues (e.g., paragraph breaks, extra context), making it minimal rather than appropriately sized.
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?
This is a simple one-parameter get-by-id tool with a complete schema description. However, there is no output schema, and the description does not explain what job details are returned, potential error conditions, or any edge cases. For a low-complexity tool, the description is adequate but not fully complete.
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 the param description for jobId provides valuable context ('Get this value from "rest_id" returned from GET /jobs-search Endpoint'). The tool description itself adds no parameter semantics, but the schema does the heavy lifting, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Job Details' clearly specifies a verb (Get) and a resource (Job Details), distinguishing it from sibling tools for tweets, users, communities, and lists. However, it restates the tool name almost exactly and provides no additional specifics about what details are included.
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 gives no guidance on when to use this tool compared to alternatives like search_jobs or get_tweet_details. The only contextual hint (how to obtain jobId from the /jobs-search endpoint) appears in the schema parameter description, not in the tool description itself.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, authentication requirements, rate limits, or the expected return format. For a read operation, it should at least imply that it is a read, but even basic context is missing.
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 phrase with no redundant words. Every token contributes to conveying the action and target, making it an exemplary concise description for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what 'details' are returned. It also does not define what 'Space' means in a domain with many getter tools. The description is too sparse to give an agent confidence about the tool's functionality and return value, especially without any annotation support.
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 'id' parameter, but the schema description only provides an example (1djGXrBwYEjxZ). The description's 'By ID' confirms that the parameter is the identifier, adding minimal semantic value beyond the schema. Since schema coverage is high, a baseline of 3 is appropriate.
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?
The description 'Get Space Details By ID' clearly states the verb (Get), the resource (Space Details), and the method (By ID). It is distinct from sibling tools like get_tweet_details or get_community_details because it targets a different resource type, though it does not explicitly say 'Space' refers to a Twitter Space.
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 does not mention any conditions, prerequisites, or exclusions, and there are no references to similar tools. For a getter with many siblings, this lack of usage context is a clear gap.
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?
With no annotations, the description must disclose behavior. It only states the read operation and does not mention pagination, response format, rate limits, or any side effects. This is minimal coverage for a tool with no annotation support.
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?
The description is a single, front-loaded sentence with no redundant words, but it has a minor spacing typo. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, so the description must be self-sufficient. It does not explain what the response contains, how cursor pagination works, or any usage constraints. This is insufficient for reliable agent selection.
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 covers all three parameters with example values, so the baseline is 3. The description adds no meaning beyond indicating that listId identifies the list; it does not explain count or cursor 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 tool retrieves list followers using a list ID. It uses a specific verb ('Get') and identifies the resource ('List Followers'), distinguishing it from sibling tools like get_list_members or get_list_details.
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?
There is no guidance on when to use this tool versus alternatives such as get_list_members or get_user_followers. No context about selection criteria is provided.
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?
With no annotations, the description must carry the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state return format, pagination, cursor usage, or any permissions/rate limits, leaving significant behavioral aspects undisclosed.
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?
The description is a single, front-loaded sentence with no wasted words. However, it is somewhat under-specified, lacking important contextual details about the parameters, so it does not reach the highest tier of helpful conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns and how parameters like count and cursor affect results. It does neither, leaving critical context missing for a tool with pagination support.
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 the baseline is 3. The description only clarifies that the operation is keyed by post ID; it adds no meaning for count or cursor beyond the schema's example values, which are minimal.
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 unambiguously identifies the action (get), resource (post likes), and key (post ID). It distinguishes itself from sibling tools like get_post_retweets or get_post_comments, which handle different post engagement types.
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 for when to use this tool versus alternatives. While the name implies use with a post ID, it does not mention contexts, prerequisites, or exclusions relative to sibling tools like get_user_likes or get_post_retweets.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get', which implies a read operation, but offers no details about rate limits, authentication requirements, what specific fields are returned, or any edge cases. This is minimal transparency for a tool that presumably accesses external data.
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, 'Get Tweet Details By Tweet ID', front-loaded with the verb and object. Every word earns its place, with no filler or redundant phrasing. It is highly efficient.
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 with one parameter and no output schema, but the existence of sibling tools with very similar names ('get_tweet_details_v2', 'get_tweets_details_by_ids') creates a need for contextual distinction that the description fails to provide. It also omits any indication of response structure or limitations. For a straightforward getter, this is minimally viable but incomplete.
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 full coverage (100%) for the single parameter 'pid' with an example value, so the schema already explains the parameter. The description only restates 'By Tweet ID' without adding additional meaning or context, so it adds no value beyond the schema. Baseline score of 3 applies here.
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?
The description 'Get Tweet Details By Tweet ID' uses a specific verb ('Get') and identifies the resource ('Tweet Details') and the identifier type ('Tweet ID'). It clearly states the tool's function, but it does not differentiate from the sibling tool 'get_tweet_details_v2' or 'get_tweets_details_by_ids', so it lacks distinguishing context.
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 instead of alternatives. It does not mention any exclusions, prerequisites, or compare to the similar sibling tools like 'get_tweet_details_v2' or the plural 'get_tweets_details_by_ids'. This absence leaves the agent guessing about selection criteria.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action and resource, offering no details about pagination, ordering, rate limits, or response structure. The read-only nature is implied by 'GET' but not explicitly confirmed.
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?
The description is a single, tightly worded phrase with no unnecessary words. It is appropriately brief for the simple purpose, though it could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward but involves pagination (cursor) and a count limit. The description does not explain how to iterate, what the response contains, or any edge cases. With no annotations and no output schema, the description leaves significant gaps for an agent trying to invoke the tool 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% because each parameter has a description, though some are minimal (e.g., cursor has only an empty example). The description itself adds no additional parameter meaning beyond the schema. The baseline of 3 applies since the schema handles basic documentation, but no extra clarity is provided.
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 'GET Following IDs by Username' clearly states the resource (following IDs) and the key input (username). It distinguishes from sibling tools like get_user_followers_ids and get_user_followings, indicating a specific purpose of retrieving only the IDs of accounts a user follows.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it returns only IDs and not full user objects, nor does it reference pagination or count limits beyond the schema. No exclusions or alternative recommendations are provided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's name and offers no additional information about output format, data source, pagination, or any quirks. Since this is a read-only lookup, the lack of detail is concerning but not misleading.
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, short sentence that is concise and front-loaded. Every word is necessary and there is no redundancy. It is an ideal length for a tool with no parameters.
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?
For a tool with no parameters, the description is minimally viable, but it is incomplete because there is no output schema and no explanation of what 'locations' means or how the return data will be structured. Users are left to guess whether the result is a list of WOEIDs, names, or objects.
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?
This tool has zero parameters, so the baseline score is 4. The schema is empty and there is nothing to explain. The description does not need to add parameter semantics, and it does not attempt to.
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?
The description clearly states the tool's purpose with a specific verb and resource ('Get Available Trends Locations'). However, it does not differentiate this tool from the sibling tool get_trends_by_location, which could be confused for a similar operation. The name and description are nearly identical.
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?
There is no guidance on when to use this tool versus alternatives. No mention of related tools like get_trends_by_location, and no context suggesting that this tool should be called first to obtain location IDs. The description simply states the function without any 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that members are fetched by list ID, with no mention of pagination, return format, whether members are user objects or IDs, or any authorization requirements. The description adds little beyond what the tool name 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?
The description is a single, front-loaded sentence with no filler. It is appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, leaving the description responsible for explaining behavior. It does not describe return values, pagination, or how members are represented. With a large sibling set, the description is too minimal to fully orient the agent.
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 has descriptions for all 3 parameters, though they are just example values. The description clarifies that listId identifies the list whose members are fetched. However, count and cursor pagination semantics are not explained in the description, but the high schema coverage sets a baseline of 3.
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 (Get), the resource (List Members), and the key identifier (List ID). This distinguishes it from sibling tools like get_list_details (list info) and get_list_timeline (tweets in the 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 on when to use this tool versus alternatives like get_list_details or get_list_timeline. The description does not specify the relationship between list members, list details, and list timeline, leaving the agent to infer. There are no exclusions or alternative recommendations.
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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does not mention pagination via cursor, count limits, output shape, or read-only guarantees, offering only the generic word 'Get'.
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 redundant words or filler. It is concise and every word contributes to stating the core purpose, even though it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should compensate by explaining return format, pagination behavior, or typical usage, but it does none of these. The tool has three parameters, yet the description only hints at the ID, leaving the overall contract underspecified.
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 has 100% coverage with example values, so the baseline is 3. However, the description adds no extra meaning for 'pid', 'count', or 'cursor'; it merely echoes 'By Post ID' for the pid parameter while leaving the other parameters functionally unexplained.
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 phrase 'Get Post Quotes By Post ID' clearly specifies a verb ('Get'), a resource ('Post Quotes'), and the input identifier, making the operation unambiguous. It also distinguishes itself from sibling tools like get_post_retweets, get_post_comments, and get_post_likes by naming 'Quotes'.
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, nor does it mention any exclusions or preferred contexts. It simply states what the tool does, leaving the agent without decision support.
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?
No annotations are provided, and the description does not disclose behavioral traits such as pagination via cursor, authentication requirements, rate limits, or return format. The schema mentions count max 5000 but the description adds no behavioral context.
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 phrase, front-loaded with the key action and resource. It is free of filler and easy to parse, earning its place as a minimal yet clear summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must carry more weight. With only the phrase 'GET Followers IDs by Username,' critical context is missing: how pagination works, whether the response contains an array of IDs or an object, any prerequisites (e.g., user must be public), and how to handle errors. The description is inadequate for an agent to invoke the tool correctly beyond basic parameter filling.
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 covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds minimal semantic value beyond saying 'by Username,' which is already evident from the parameter naming. No additional details about count or cursor semantics are provided in the 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 retrieves follower IDs for a given username, using the HTTP verb 'GET'. It distinguishes from sibling tools like get_user_followers (which likely returns full user objects) and get_user_following_ids (which targets following, not followers).
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 on when to use this tool versus alternatives. The description simply states the function without context, exclusions, or alternative suggestions. Sibling tools exist but are not referenced.
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?
With no annotations, the description carries the full burden. It discloses the search categories but does not mention authentication requirements, pagination behavior, rate limits, or whether results are read-only. The behavior beyond the search action is largely undisclosed.
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 redundant wording. It efficiently communicates the core purpose and search categories.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is too sparse. It fails to explain how to use parameters, what results look like, or how pagination works, leaving significant gaps for an AI agent.
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 descriptions are only example values, so the baseline for 100% coverage is 3. The description adds some meaning by listing possible search types that likely map to the 'type' parameter, but it does not explain 'count', 'query', or 'cursor' beyond their names.
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?
The description clearly states it searches Twitter and lists the specific search categories (Top, Latest, Videos, Photos, People), which is a specific verb+resource with useful modifiers. It distinguishes from most sibling search tools (search_community, search_lists), though it does not differentiate from search_twitter_v2.
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 searching Twitter, but provides no explicit guidance on when to use this tool versus search_twitter_v2 or other search-related tools. There are no alternatives or exclusions mentioned, so usage context is only implied.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the purpose without mentioning pagination, authentication requirements, return format, or any side effects. This leaves the agent without knowledge of cursor-based pagination 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, front-loaded sentence that states the action and key identifier with no wasted words. It is as concise as possible while conveying the core purpose.
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 tool with only two parameters (one required) and no output schema, the description covers the essential selection and invocation information. However, the cursor parameter is not described, and pagination behavior is omitted, leaving some gaps. Still, it is adequate for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the schema descriptions are merely examples (e.g., 'Example value: 1601841656147345410') and do not explain semantics. The description mentions communityId but says nothing about the cursor parameter, which is likely for pagination. The agent gets no added meaning beyond the parameter names.
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 ('Community Moderators') with the key identifier ('by Community ID'), clearly distinguishing it from sibling tools like get_community_members and get_community_details. It unambiguously states what the tool does.
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 'by Community ID' implies the tool is for retrieving moderators for a specific community, providing clear context for when to use it. However, it does not explicitly mention when not to use it or name alternatives such as get_community_members, which could be confused for this purpose.
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:

[![bach-twitter241 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-twitter241/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-twitter241)

Score Badge

Copy to your README.md:

[![bach-twitter241 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-twitter241/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bach-twitter241)

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/BACH-AI-Tools/bach-twitter241'

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