Server Quality Checklist

Tool Scores

• searchRecentC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions the 7-day time constraint, which is useful behavioral context. However, it doesn't disclose other important traits: whether this is a read-only operation, rate limits, authentication requirements, pagination behavior (implied by 'next_token' but not explained), or what format results return. For a search tool with 10 parameters, this is inadequate behavioral disclosure.

  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, efficient sentence that states the core functionality. There's zero waste or redundancy. It's appropriately sized for a tool with good schema documentation.

  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 search tool with 10 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'posts' refers to (tweets?), what the search scope includes, how results are returned, or any limitations. The 7-day constraint is mentioned, but other critical context about behavior and results is missing.

  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 all parameters are documented in the schema. The description adds minimal value beyond the schema - it only implies that 'recent' means 'last 7 days' which relates to time parameters but doesn't provide additional semantic context about individual parameters. Baseline 3 is appropriate when schema does the heavy lifting.

  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 'Search recent posts (last 7 days)' clearly states the action (search) and resource (posts) with a time constraint. However, it doesn't distinguish this tool from its sibling 'searchAll' which presumably searches all posts without the 7-day limitation. The purpose is understandable but 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 guidance on when to use this tool versus alternatives like 'searchAll' or other search-related siblings. It mentions the 7-day constraint but doesn't explicitly state this is for recent-only searches versus comprehensive searches. No prerequisites, exclusions, or comparison to other tools are provided.

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

• bookmarkPostC
  2.9/5.0
  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 states the action is a mutation ('bookmark'), implying it's not read-only, but fails to describe side effects, error conditions, or response format. This leaves significant gaps for a tool that modifies user 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, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it highly concise and 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what happens on success/failure, whether bookmarks are unique, or how to verify the action. Given the complexity and lack of structured data, more context is needed.

  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% description coverage, fully documenting both parameters. The description adds no additional meaning beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate when the schema does all the work.

  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 ('bookmark') and resource ('a post') with the context 'on behalf of the authenticated user', making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'removeBookmark' beyond the opposite action, missing a direct comparison that would earn 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?

  The description provides no guidance on when to use this tool versus alternatives like 'removeBookmark' or 'getUserBookmarks', nor does it mention prerequisites such as authentication or post visibility. It only implies usage through the action, lacking explicit context or exclusions.

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

• createPostC
  2.9/5.0
  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 states the tool creates a post but doesn't mention potential side effects (e.g., public visibility, rate limits, or error conditions). It hints at authentication ('on behalf of the authenticated user') but doesn't specify required permissions or consequences of misuse, leaving significant gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the essential action without unnecessary elaboration, making it easy to parse quickly.

  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 complexity (9 parameters with nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain return values, error handling, or behavioral nuances like how media or polls are processed. For a tool with rich input options and mutation effects, more detail is needed to ensure proper usage.

  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 description adds no parameter-specific information beyond what's in the input schema. With a schema description coverage of 56%, the baseline is 3, as the schema documents parameters like 'text' and 'media', but the description doesn't compensate for the coverage gap or provide additional context about parameter usage or interactions.

  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 ('create a new post') and resource ('post'), specifying it's done 'on behalf of the authenticated user'. However, it doesn't explicitly differentiate from sibling tools like 'createRetweet' or 'likePost', which also involve post creation or interaction, leaving some ambiguity about when to choose this specific tool.

  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. For example, it doesn't mention when to choose 'createPost' over 'createRetweet' or 'likePost', nor does it discuss prerequisites like authentication requirements or context for posting. The description lacks any usage context or exclusions.

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

• createRetweetC
  2.9/5.0
  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 states the action is a retweet, implying a write operation that creates a public share, but lacks details on permissions (e.g., if the user can retweet private posts), rate limits, error conditions (e.g., if the post is deleted), or what the response includes (e.g., success confirmation or new retweet ID). This is a significant gap for a mutation tool.

  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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  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 is a mutation (creating a retweet) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or return values, which are crucial for an AI agent to use it correctly in context with 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 input schema has 100% description coverage, with clear parameter definitions for 'user_id' and 'tweet_id'. The description adds no additional semantic context beyond implying these are required for the retweet action, so it meets the baseline of 3 where the schema does the heavy lifting.

  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 ('Retweet') and resource ('a post') with the context 'on behalf of the authenticated user', which specifies the agent. However, it doesn't explicitly distinguish this from sibling tools like 'getRetweets' (which retrieves retweets) or 'deleteRetweet' (which removes one), though the verb 'Retweet' implies creation versus deletion or retrieval.

  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. For example, it doesn't mention when to choose 'createRetweet' over 'likePost' for engagement, or how it differs from 'bookmarkPost' in saving content. There's also no mention of prerequisites, such as needing authentication or valid post IDs.

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

• deletePostC
  2.9/5.0
  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 states the action is 'Delete,' implying a destructive, irreversible mutation, but fails to specify critical details like required permissions, whether deletion is permanent or recoverable, or any rate limits. This is a significant gap for a destructive operation with zero annotation coverage.

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

  Conciseness5/5

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

  The description is extremely concise—a single, clear sentence with zero wasted words. It front-loads the core action ('Delete') and resource, making it easy to parse. Every part of the sentence earns its place by directly supporting the tool's purpose without redundancy.

  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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks essential context such as error handling (e.g., what happens if the ID doesn't exist), side effects, or return values. Given the complexity of deletion operations and the absence of structured behavioral data, this description falls short of providing adequate guidance.

  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 description adds minimal value beyond the input schema, which has 100% coverage and fully documents the single 'id' parameter. It mentions 'by ID,' aligning with the schema's description, but doesn't provide additional context like ID format examples or validation rules. Given the high schema coverage, 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 clearly states the action ('Delete') and the target resource ('a post by ID'), which is specific and unambiguous. It distinguishes itself from siblings like 'unlikePost' or 'removeBookmark' by focusing on permanent deletion. However, it doesn't explicitly differentiate from destructive siblings like 'deleteRetweet' beyond the resource type, keeping it from a perfect score.

  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 prerequisites (e.g., needing post ownership or admin rights), exclusions (e.g., not for retweets), or related tools like 'hideReply' for non-destructive actions. This lack of context leaves the agent to infer usage from the tool name alone.

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

• deleteRetweetC
  2.9/5.0
  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 states the tool performs a removal action, implying mutation, but lacks details on permissions needed, whether the action is reversible, rate limits, or error conditions. This is a significant gap for a mutation tool without annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('Remove a retweet') and adds necessary context ('on behalf of the authenticated user') without redundancy, making it highly concise and 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after removal (e.g., success response, error handling), nor does it cover behavioral aspects like side effects or dependencies, leaving critical gaps for agent usage.

  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 schema already documents both parameters ('user_id' and 'tweet_id') adequately. The description doesn't add any extra meaning or context about these parameters beyond what the schema provides, meeting the baseline score for 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 clearly states the action ('Remove a retweet') and specifies it's performed 'on behalf of the authenticated user', which distinguishes it from general deletion tools. However, it doesn't explicitly differentiate from sibling tools like 'deletePost' or 'unlikePost', which target different types of content interactions.

  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 like 'deletePost' (for original posts) or 'unlikePost' (for likes). It also doesn't mention prerequisites, such as requiring an existing retweet to remove, leaving usage context entirely implicit.

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

• getLikedTweetsC
  2.9/5.0
  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 states it 'gets' posts (implying a read operation) but doesn't clarify whether this requires authentication, has rate limits, returns paginated results (though the schema hints at pagination), or what the output format looks like. For a tool with 6 parameters and no annotation coverage, this leaves significant behavioral gaps.

  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, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the essential action and resource, making it immediately scannable. Every word earns its place, with no redundancy or fluff.

  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 tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address authentication needs, rate limits, pagination behavior (beyond the schema hint), error conditions, or output format. Given the complexity and lack of structured metadata, the description should provide more contextual guidance for effective tool 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%, so the schema fully documents all 6 parameters. The description adds no parameter-specific information beyond implying the 'id' parameter refers to a user. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter usage or interactions.

  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 verb ('Get') and resource ('posts that a user has liked'), making the purpose immediately understandable. It distinguishes this from siblings like 'getUserBookmarks' or 'getUserTimeline' by focusing on liked posts. However, it doesn't specify the resource type (tweets/posts) or explicitly differentiate from 'getLikingUsers' which retrieves users who liked a post rather than posts liked by a 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'getUserBookmarks' (for bookmarked posts) or 'getUserTimeline' (for user's own posts), nor does it specify prerequisites like authentication requirements or rate limits. The agent must infer usage from the tool name alone.

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

• getLikingUsersC
  2.9/5.0
  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. While 'Get' implies a read-only operation, the description doesn't mention any behavioral traits such as rate limits, authentication requirements, pagination behavior (implied by the pagination_token parameter but not explained), or what the return format looks like. This leaves significant gaps for a tool with 6 parameters.

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

  Conciseness5/5

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

  The description is a single, clear sentence with zero wasted words. It's appropriately sized and front-loaded, immediately conveying the core purpose without unnecessary elaboration.

  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 complexity (6 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain the return format, pagination behavior, or any error conditions. While the schema covers parameters well, the lack of behavioral context and output information leaves the agent with significant gaps in understanding how to use this 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?

  The schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the format of 'expansions' or 'tweet.fields' beyond their schema descriptions). This meets the baseline of 3 when the schema does the heavy lifting.

  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 verb 'Get' and the resource 'users who liked a specific post', making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'getLikedTweets' or 'getUserBookmarks' that also retrieve user-related data, missing an opportunity for explicit 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 guidance on when to use this tool versus alternatives. With sibling tools like 'getLikedTweets' (which retrieves tweets liked by a user) and 'getUserBookmarks' (which retrieves bookmarked posts), there's no indication of the specific context or prerequisites for selecting 'getLikingUsers' over these other user-data retrieval tools.

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

• getRetweetsC
  2.9/5.0
  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 states the tool retrieves retweets but lacks details on permissions, rate limits, pagination behavior, or response format. For a read operation with multiple parameters, this leaves significant gaps in understanding how the tool behaves beyond its basic function.

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

  Conciseness5/5

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

  The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by directly stating what the tool does.

  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 complexity of 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover behavioral aspects like pagination handling, error cases, or what the returned data looks like. For a tool that fetches social media data with multiple options, more context is needed to ensure proper usage.

  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% description coverage, documenting all parameters clearly. The description doesn't add any semantic details beyond the schema, such as explaining the purpose of expansions or field selections. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.

  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: 'Get posts that retweet a specific post.' It specifies the verb ('Get') and resource ('posts that retweet a specific post'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'getBulkPosts' or 'getSinglePost' in terms of retweet-specific functionality, which prevents a perfect score.

  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 scenarios like retrieving retweets for analysis, comparing with other post-fetching tools, or prerequisites such as needing a valid post ID. Without this context, an agent might struggle to choose between this and similar tools like 'getBulkPosts' or 'getSinglePost'.

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

• getSinglePostC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'optional field expansions' which hints at configurability, but fails to describe critical behaviors: whether this is a read-only operation, what authentication is required, rate limits, error conditions, or the structure of the returned data. For a tool with no annotation coverage, this leaves significant gaps.

  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, efficient sentence that front-loads the core purpose. Every word earns its place, though it could potentially be more structured by separating the core retrieval from the expansion feature. There's no wasted verbiage.

  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 complexity (7 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the tool returns, how expansions affect the output, error handling, or authentication requirements. For a retrieval tool with multiple configuration options and no output schema, more context is needed to make it actionable.

  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 schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional field expansions' which loosely references the expansion-related parameters, but doesn't provide additional context about how expansions work or their relationship to the various '.fields' parameters. This meets the baseline for 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 clearly states the verb ('Retrieve') and resource ('a single post by ID'), making the purpose unambiguous. It distinguishes itself from bulk retrieval tools like 'getBulkPosts' by specifying 'single post', but doesn't explicitly differentiate from other single-post operations like 'getLikedTweets' or 'getUserBookmarks' beyond the ID-based retrieval.

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

  Usage 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. With many sibling tools available (e.g., 'getBulkPosts', 'getUserTimeline', 'searchRecent'), there's no indication of when ID-based retrieval is preferred over other methods, nor any mention of prerequisites or constraints.

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

• getUserBookmarksC
  2.9/5.0
  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 states the tool retrieves data ('Get'), implying a read-only operation, but doesn't address critical aspects like authentication requirements, rate limits, pagination behavior (beyond the parameter), error handling, or response format. This leaves significant gaps for a tool with 6 parameters.

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

  Conciseness5/5

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

  The description is a single, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately front-loaded and earns its place by establishing what the tool does in minimal terms.

  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 tool with 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the return format, pagination behavior, error conditions, or authentication needs. While the schema covers parameters, the overall context for safe and effective use is lacking.

  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%, so all parameters are documented in the schema itself. The description doesn't add any meaningful semantic context beyond what's in the schema (e.g., explaining how expansions or fields work in practice). This meets the baseline for high schema coverage but doesn't enhance understanding.

  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 a user's bookmarked posts' clearly states the verb ('Get') and resource ('user's bookmarked posts'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getLikedTweets' or 'getUserTimeline' which also retrieve user-specific content, missing full 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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context for use, or comparison with sibling tools like 'getLikedTweets' or 'searchAll', leaving the agent to infer usage patterns independently.

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

• getUserMentionsC
  2.9/5.0
  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 states the tool retrieves posts but lacks details on permissions required, rate limits, pagination behavior (implied by 'pagination_token' but not explained), or what the output looks like (e.g., format, error handling). For a read operation with 10 parameters, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, clear sentence: 'Get posts that mention a specific user.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's function. Every part of the sentence earns its place by directly stating what the tool does.

  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 complexity (10 parameters, no output schema, no annotations), the description is incomplete. It doesn't address behavioral aspects like pagination, rate limits, or output format, which are crucial for a retrieval tool. Without annotations or an output schema, the description should provide more context to help an agent use the tool effectively, but it falls short.

  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%, meaning all parameters are documented in the input schema itself. The description doesn't add any meaning beyond the schema—it doesn't explain parameter interactions, default values, or usage examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract from the existing documentation.

  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: 'Get posts that mention a specific user.' It specifies the verb ('Get') and resource ('posts that mention a specific user'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'getUserTimeline' or 'searchAll,' which might also retrieve user-related posts, so it falls short of a perfect score.

  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 prerequisites, such as needing a user ID, or compare it to siblings like 'getUserTimeline' (which might show posts by a user) or 'searchAll' (which could search for mentions). Without this context, an agent might misuse it or overlook better options.

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

• getUserTimelineC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action ('Get') without mentioning pagination behavior (implied by 'pagination_token' parameter but not explained), rate limits, authentication requirements, error conditions, or what format/scope the timeline includes. For a retrieval tool with 11 parameters, this leaves significant behavioral gaps.

  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 extremely concise with a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a retrieval operation and front-loads the essential information.

  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 complexity (11 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't explain what a 'timeline' entails (chronological posts? includes retweets?), how results are structured, pagination behavior, or error handling. For a data retrieval tool with many filtering options, more context is needed to use it 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?

  The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters (e.g., how 'start_time'/'end_time' interact with 'since_id'/'until_id'), provide examples for complex fields like 'expansions', or clarify the timeline's chronological order. With complete schema coverage, the baseline is 3.

  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: 'Get a user's timeline of posts' specifies the verb ('Get') and resource ('user's timeline of posts'). It distinguishes from some siblings like 'getSinglePost' or 'getUserBookmarks' by focusing on a chronological feed, but doesn't explicitly differentiate from all similar retrieval tools like 'getUserMentions' or 'searchRecent'.

  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 when this tool is appropriate compared to siblings like 'getUserMentions' (for mentions timeline), 'searchRecent' (for keyword-based timeline), or 'getLikedTweets' (for liked posts). No exclusions or prerequisites are stated.

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

• hideReplyC
  2.9/5.0
  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 states the action but lacks critical details: whether this requires specific permissions, if changes are reversible, what happens to hidden replies (e.g., visibility to others), or any rate limits. This is a significant gap for a mutation tool.

  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, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it easy to parse quickly.

  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 complexity as a mutation with no annotations and no output schema, the description is incomplete. It doesn't explain the outcome (e.g., what 'hidden' means in practice), error conditions, or prerequisites, leaving the agent with insufficient context for reliable use.

  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 schema fully documents both parameters ('id' and 'hidden'). The description adds no additional meaning beyond what the schema provides, such as format examples or edge cases, meeting the baseline for high 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 clearly states the verb ('hide or unhide') and resource ('a reply to a post'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'deletePost' or 'bookmarkPost', which also modify post visibility or state, leaving room for potential confusion.

  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. For example, it doesn't clarify if this is for moderation versus user actions, or how it differs from 'deletePost' or other visibility-related tools in the sibling list.

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

• likePostC
  2.9/5.0
  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 implies a write operation ('Like') but doesn't mention permissions, rate limits, side effects, or response format. This leaves significant gaps for a mutation tool.

  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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, and return values, which are critical for proper agent usage given the tool's complexity and 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 100% description coverage, clearly documenting both parameters. The description adds no additional parameter details beyond what's in the schema, so it meets the baseline for adequate but not exceptional 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 clearly states the action ('Like') and resource ('a post on behalf of the authenticated user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'unlikePost' or 'getLikedTweets', which would be needed for a perfect score.

  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 like 'unlikePost' or 'bookmarkPost'. It mentions 'on behalf of the authenticated user' but doesn't clarify prerequisites, exclusions, or specific contexts for application.

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

• removeBookmarkC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but provides minimal behavioral context. It states the action is performed 'on behalf of the authenticated user,' hinting at authorization needs, but doesn't disclose side effects (e.g., irreversible deletion), rate limits, error conditions, or what happens if the bookmark doesn't exist.

  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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.

  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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, error handling), expected outcomes, or how it integrates with the broader system (e.g., sibling tools). The context signals indicate complexity (2 required parameters), but the description doesn't compensate adequately.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the relationship between user_id and authentication). Baseline 3 is appropriate as the schema does the heavy lifting.

  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 ('Remove') and resource ('bookmark'), specifying it's done on behalf of the authenticated user. It distinguishes from siblings like 'deletePost' or 'unlikePost' by focusing on bookmarks, but doesn't explicitly differentiate from 'getUserBookmarks' (which is a read operation).

  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. It doesn't mention prerequisites (e.g., the bookmark must exist), when not to use it, or how it relates to siblings like 'bookmarkPost' (for adding) or 'getUserBookmarks' (for listing).

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

• getBulkPostsB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic retrieval functionality. It doesn't disclose whether this is a read-only operation (implied but not stated), rate limits, authentication requirements, error behavior for invalid IDs, or response format details. Significant behavioral gaps remain.

  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?

  Perfectly concise single sentence that immediately communicates the core functionality. No wasted words or unnecessary elaboration. Front-loaded with the essential information.

  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 7-parameter retrieval tool with no annotations and no output schema, the description is minimally adequate. It covers the primary use case but lacks important context about behavior, alternatives, and response format. The high schema coverage helps, but more behavioral disclosure would be needed for full 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?

  Schema description coverage is 100%, providing complete parameter documentation. The description adds minimal value beyond the schema, only mentioning the 'ids' parameter constraint ('up to 100'). No additional semantic context is provided for the six expansion/field parameters.

  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 ('Retrieve') and resource ('posts by their IDs') with a specific scope ('up to 100'). It distinguishes from getSinglePost by handling multiple IDs, but doesn't explicitly differentiate from other bulk operations like searchAll or searchRecent.

  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 on when to use this tool versus alternatives like getSinglePost (for one ID), searchAll/searchRecent (for query-based retrieval), or getUserTimeline (for user-specific posts). The description implies usage when you have specific post IDs, but provides no explicit context or exclusions.

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

• getPostCountsAllB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions access requirements (Academic Research/Enterprise) which is valuable context, but doesn't describe what 'time-bucketed' means in practice, the format of returned counts, whether results are paginated, rate limits, or error conditions. For a 6-parameter tool with no annotations, this leaves significant behavioral gaps.

  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 efficiently structured in a single sentence that front-loads the core purpose followed by important constraints. Every element (time-bucketed, all posts, full archive, access requirements) serves a purpose. However, it could be slightly more structured by separating the access requirement into a second sentence for clarity.

  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 6-parameter counting tool with no output schema and no annotations, the description is moderately complete. It covers the core purpose and access requirements but lacks details about return format, pagination, error handling, and how parameters interact. The 100% schema coverage helps, but behavioral aspects remain underspecified given the tool's complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema - it implies the tool works on 'all posts (full archive)' which contextualizes the time/ID parameters, but doesn't provide additional semantic guidance about parameter interactions or usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.

  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: 'Get time-bucketed post counts for all posts' specifies the verb (get), resource (post counts), and key behavior (time-bucketed). It distinguishes from sibling 'getPostCountsRecent' by specifying 'full archive' scope. However, it doesn't explicitly differentiate from other counting/search tools like 'searchAll' or 'searchRecent'.

  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 provides some usage context: 'requires Academic Research or Enterprise access' indicates prerequisites, and 'full archive' implies it should be used for historical data rather than recent posts (contrasting with 'getPostCountsRecent'). However, it doesn't explicitly state when to use this versus alternatives like 'searchAll' or provide clear exclusion criteria beyond access requirements.

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

• searchAllB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions access requirements (Academic Research or Enterprise) which is useful context about permissions. However, it doesn't describe important behavioral traits like pagination behavior (implied by next_token/previous_token parameters but not explained), rate limits, response format, or whether this is a read-only operation. For a search tool with 11 parameters, this leaves significant gaps.

  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 extremely concise - a single sentence that packs essential information about scope and access requirements. It's front-loaded with the core purpose and includes critical constraints. Every word earns its place with zero waste or redundancy.

  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 complex search tool with 11 parameters, no annotations, and no output schema, the description is insufficient. While concise, it doesn't explain the search behavior, result format, pagination mechanism (despite tokens being parameters), or how the various filtering parameters interact. The access requirement is helpful but doesn't compensate for the lack of behavioral context needed for effective tool use.

  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 all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'full archive' which relates to the temporal scope but doesn't explain how this interacts with the time-related parameters (start_time, end_time, since_id, until_id). Baseline 3 is appropriate when schema does the heavy lifting.

  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 verb ('Search') and resource ('all posts'), specifying it covers the 'full archive'. It distinguishes from sibling 'searchRecent' by indicating broader scope. However, it doesn't explicitly mention what makes it different from other search-like tools like 'getUserMentions' or 'getUserTimeline'.

  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 provides some usage context by stating it 'requires Academic Research or Enterprise access', which implies when it can be used based on subscription level. It also distinguishes from 'searchRecent' by mentioning 'full archive'. However, it doesn't explicitly say when to choose this over alternatives like 'getBulkPosts' or 'getPostCountsAll', nor does it provide when-not-to-use guidance.

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

• getPostCountsRecentB
  3.3/5.0
  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 mentions 'time-bucketed post counts' and 'recent posts (last 7 days)', which gives some context on output format and time constraints. However, it lacks details on permissions, rate limits, error handling, or what the counts represent (e.g., aggregated data). For a tool with no annotations, this is a significant gap in behavioral transparency.

  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, efficient sentence: 'Get time-bucketed post counts for recent posts (last 7 days)'. It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by conveying key information.

  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?

  Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and time scope but lacks details on output format, error cases, or how parameters like 'query' interact with time constraints. Without annotations or output schema, more context would be beneficial for full 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?

  Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema by implying time-bucketing and a default 7-day period, but it doesn't explain parameter interactions or provide additional semantics. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate significantly.

  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: 'Get time-bucketed post counts for recent posts (last 7 days)'. It specifies the action ('Get'), resource ('post counts'), and scope ('recent posts, last 7 days'), but doesn't explicitly differentiate from its sibling 'getPostCountsAll', which likely handles a broader time range. This makes it clear but not fully sibling-distinctive.

  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 recent posts (last 7 days), suggesting a temporal context. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'getPostCountsAll' or 'searchRecent', nor does it mention exclusions or prerequisites. The context is implied but not comprehensive.

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

• unlikePostA
  3.5/5.0
  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. It mentions 'on behalf of the authenticated user,' which hints at authentication needs, but doesn't disclose other behavioral traits such as whether the operation is reversible, potential rate limits, error conditions, or what happens if the post isn't liked. This leaves significant gaps for a mutation tool.

  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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for its function.

  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?

  Given the tool's moderate complexity (a mutation with two parameters), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers the basic action and authentication context but lacks details on behavioral aspects and output, making it adequate but not fully comprehensive.

  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%, so the schema already documents both parameters ('user_id' and 'tweet_id') with clear descriptions. The description doesn't add any additional meaning beyond what the schema provides, such as format examples or constraints, which aligns with the baseline score when schema coverage is high.

  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 specific action ('Unlike') and resource ('a post'), and distinguishes it from sibling tools like 'likePost' by specifying the opposite operation. It's precise and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage when a user wants to remove a like from a post, but it doesn't explicitly state when to use this tool versus alternatives (e.g., 'deletePost' for removing a post entirely) or mention prerequisites like authentication. It provides basic context but lacks detailed guidance.

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