RelayX — X/Twitter data

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds genuinely useful behavioral context beyond them: this call is free and never charged, which matters for an agent managing a credit budget. It does not discuss rate limits or return format.

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

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

Front-loaded and short, with the core purpose in the first sentence. The second line re-states the same 'free' fact already given as 'Always free', which is mild redundancy rather than added information.

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

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

For a zero-parameter, read-only tool with annotations covering the safety profile, the description is essentially complete. Without an output schema it could note the return shape (a credit count/number), but 'credits remaining' is sufficiently self-explanatory.

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

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

The tool takes zero parameters, so there is nothing to document beyond the schema. Baseline 4 applies; the description coherently frames what the parameterless call returns.

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

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

States a specific verb and resource ('Return the credits remaining') and pins the scope precisely to the account behind the API key making the request. This unambiguously distinguishes it from every sibling, all of which are Twitter/X content tools.

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

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

Implies the use case clearly (checking your balance) and adds a cost condition ('Always free') that tells the agent it is safe to call without spending credits. It does not name alternatives or exclusions, but no sibling overlaps, so there is little to route against.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral detail not present elsewhere: a cost of 15 credits per call. It does not describe rate limits, pagination, or failure modes, so it is above baseline but not rich.

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

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

Two lean sentences, purpose front-loaded, cost appended on its own line. Nothing is redundant, though the profile-field enumeration slightly overlaps what a schema/output could convey.

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

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

For a one-parameter read tool with annotations covering safety, the description is nearly sufficient, and enumerating the returned fields partially compensates for the absent output schema. It lacks any note on invalid community_id handling or pagination, but little else is missing.

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

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

Schema description coverage is 0% and the single parameter (community_id) is never mentioned in the description, so no meaning is added. The parameter name is largely self-explanatory for a single simple read, which keeps this at a middling score rather than poor.

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

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

States a specific verb (Return) and resource (a Community's profile) and even enumerates the returned fields (name, purpose, rules, member count, moderators). The purpose is unmistakable, but it does not distinguish itself from community-related siblings like community_tweets or list_members.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance. The sibling list contains several community/user tools (list_members, community_tweets, user_info) an agent would have to disambiguate by inference alone.

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

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

Annotations already cover safety (readOnlyHint, openWorldHint), and the description adds genuinely useful behavior beyond them: the pagination contract (has_next_page + next_cursor, pass next_cursor as cursor) and the cost model (13 credits per tweet, 15 minimum, waived on bulk). Auth/permission requirements for private vs public communities remain unstated.

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

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

Three short, front-loaded sentences with zero filler: what it returns, how pagination works, and what it costs. Each sentence earns its place.

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

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

With no output schema, the description usefully sketches the return shape (post timeline plus pagination envelope) and the cost, which is enough for correct invocation. The remaining gap is identifying the required community_id (format/source), which an agent must guess.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains the cursor parameter well (feed next_cursor back as cursor), but says nothing about community_id format or where to obtain it, leaving the required parameter fully undocumented across both schema and description.

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

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

States a specific verb and resource ('Return the timeline of posts') and narrows scope to 'a single Community', which separates it from generic timeline siblings like list_tweets_timeline and user_tweet_timeline. It does not explicitly name a sibling alternative, but the scoping phrase is distinctive enough for an agent to route correctly.

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

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

Usage is implied by the scope statement (fetch a Community's post timeline), but there is no explicit when-to-use, when-not-to-use, or named alternative among the many timeline/search siblings. An agent must infer that this is the community-scoped counterpart to the user timelines.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds value beyond them by disclosing the credit-charging behavior ('Charged like tweets / user_info') and sketching the return content (post with author and metrics vs. a profile). It omits error behavior for malformed ids, which keeps it from a 5.

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

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

Everything is packed into one front-loaded sentence with no filler, and the two id forms are presented in parallel. The trailing 'Charged like tweets / user_info' is terse to the point of being cryptic, but it does earn its place as cost information.

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

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

With an output schema present, the description need not enumerate return fields, and the annotations cover the safety profile, so the remaining burden is the input format — which is fully explained. The only gap is behavior on invalid or ambiguous ids.

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

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

Schema description coverage is 0% for the single 'id' parameter, so the description must carry the burden — and it does, spelling out two accepted formats ("tweet:<id>" or bare numeric, "user:<handle>") and tying each to a different return type. It does not mention failure modes for unrelated prefixes or non-numeric input.

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

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

States a specific verb and resource ('Fetch one X item by id') and enumerates the two supported id namespaces with what each returns, so an agent can see this is a polymorphic single-item lookup rather than a bulk list. It is distinguishable from siblings like tweets/user_info by the id-prefix mechanism, though it never names an alternative tool explicitly.

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

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

The prefix syntax ('tweet:<id>' / 'user:<handle>') implicitly tells the agent when this tool applies, and the pricing note hints at the cost context. However, there is no explicit when-to-use/when-not guidance or named alternative (e.g. when to prefer tweets or user_info instead).

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: pagination mechanics (has_next_page + next_cursor) and per-item credit costs with a per-call minimum. It stops short of noting auth/permission requirements, but this is well above the annotation baseline.

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

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

Three short, front-loaded blocks with no wasted prose; the pagination and cost facts are each stated once. The arrow notation for credit tiers is terse but readable.

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

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

With no output schema, the description correctly covers the return shape that matters (has_next_page, next_cursor) and the cost model, so an agent can loop pages and predict spend. Only the list_id semantics and any access requirements are absent.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It explains how to use cursor (feed back next_cursor), which is valuable, but list_id is left entirely unexplained beyond the name. Partial compensation for the coverage gap.

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

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

States a specific verb and resource ('Page through the accounts subscribed to a List') and constrains it to a List, which separates it from user_followers and list_members. An agent can identify the target entity without opening the schema.

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

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

The list-scoped wording implies when this applies, but there is no explicit guidance on choosing it over close siblings like user_followers or list_members, and no prerequisites stated. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: the pagination contract (returns has_next_page + next_cursor) and a non-obvious credit-cost model (3/2/1 tiering, min 15, waived on bulk). This is real added value, though permission or return-shape details remain unstated.

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

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

Three short, front-loaded lines with no filler: purpose, pagination, and cost. Every sentence earns its place and nothing is buried.

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

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

With no output schema, the description usefully discloses the return envelope (has_next_page/next_cursor) and cost, which an agent needs to call correctly. It stops short of describing the list_id format or the account object shape, but it is largely complete for a two-parameter read tool.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains cursor well (pass next_cursor as cursor to continue), but list_id is left entirely to inference from the resource phrase. Partial compensation for the coverage gap warrants a 3.

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

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

States a specific verb (page through) and resource (accounts that belong to a List), which naturally separates it from siblings like list_followers and list_tweets_timeline. It doesn't explicitly name an alternative, but the resource definition is unambiguous.

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

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

The description explains pagination mechanics but gives no when-to-use guidance versus alternatives (e.g., list_followers vs list_members), nor any prerequisites or context for choosing this tool. Usage is only implied by the resource name.

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

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

Annotations already establish readOnlyHint and openWorldHint, yet the description adds real operational context: result ordering (newest first), the pagination contract (has_next_page + next_cursor), and billing (13 credits per tweet, 15 minimum, waived on bulk). The only soft spot is that 'waived on bulk' leaves the threshold unstated, and auth/error behavior is not covered.

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

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

Three short lines, each earning its place: purpose and ordering first, then the pagination protocol, then cost. No repetition of the tool name or filler, and the most decision-relevant fact leads.

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

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

With no output schema, the description must carry return-value information, and it does disclose the pagination envelope (has_next_page, next_cursor). What the individual post objects contain is not described, which is a minor gap for a read-only listing tool.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains cursor semantics well ('pass next_cursor as cursor') but says nothing about listId beyond the resource name, leaving one of two parameters undocumented in both places.

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

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

The first sentence states a concrete verb and resource with scope and ordering: 'Return the timeline of posts from a List, newest first.' The explicit 'from a List' plus 'newest first' separates it from user_tweet_timeline and community_tweets without opening a schema.

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

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

Usage is implied by the resource name, and the description does give the continuation procedure ('pass next_cursor as cursor for more'). However, it never states when to choose this over sibling timeline tools such as user_tweet_timeline or community_tweets, so alternative selection is left to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine behavioral context beyond that: the result shape ({id, title, url}), the fetch follow-up path, and explicitly that the call is charged like tweet_advanced_search (Top ranking), which is important cost information.

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

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

Four short sentences, front-loaded with the core purpose, then return shape/workflow, then syntax support, then cost. Every sentence adds distinct information with no padding.

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

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

Given a single-param tool with an output schema (so return values needn't be explained) and annotations covering safety, the description covers syntax, cost, and workflow adequately. Minor gaps remain: what "recent" means and result limits/pagination are unspecified.

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

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

Schema coverage is 0% for the single query parameter, so the description must carry it, and it does: it enumerates concrete X search syntax (from:handle, quoted phrases, lang:en, since:, min_faves:, -filter:replies). This meaningfully describes the accepted input format beyond the bare schema.

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

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

States a specific verb and resource ("Search recent public X (Twitter) posts"), which clearly separates it from user_search (users) and other user/list tools. It does not, however, fully differentiate from tweet_advanced_search, which it only references by name for pricing.

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

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

Implies a workflow by telling the agent to "pass an id to fetch for the full text," routing to the fetch sibling. It also notes the charging model relative to tweet_advanced_search, but never states when to prefer this tool over that sibling or any when-not conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered without the description. The description adds a genuinely useful behavioral fact not present in the structured fields: a 15-credit cost per call, which lets the agent budget calls. It stops short of 5 because auth requirements and failure/error behavior for invalid IDs are unstated.

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

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

Two short lines, zero filler, with the core purpose front-loaded and the cost note clearly separated. It is efficient, though the extreme brevity leaves no room for the parameter detail the tool actually needs.

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

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

For a simple read-only lookup with annotations covering the safety profile and no output schema to explain, listing the returned fields plus cost makes it largely complete. The gaps are the undocumented space_id format and lack of any error/precondition note, which are meaningful for a keyed single-resource fetch.

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

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

One required parameter with 0% schema description coverage — the schema gives only the title 'Space Id' and no format. The description does nothing to compensate: it never says whether space_id is a numeric ID, a slug, or a full URL, which is the single most likely source of invocation error.

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

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

States a specific verb and resource ('Return a Space's details') and enumerates the fields returned (title, host, speakers, state, listener counts), which tells the agent exactly what it gets. No sibling covers Spaces, so differentiation is effectively implicit rather than stated, which keeps it just 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.

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

No guidance on when to use this versus other tools, no prerequisites (e.g. must the Space be live?), and no note about what happens for expired or invalid Space IDs. The only usage-relevant statement is the per-call cost, which is a constraint rather than an invocation guideline.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral context not in annotations: the credit cost of 15 per call and that results are ranked by position.

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

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

Two tightly written sentences, with the core purpose front-loaded and the credit cost clearly separated. No filler.

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

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

For a simple read-only tool with annotations covering safety, the description covers purpose and cost but leaves the count parameter unexplained and does not clarify default behavior. Adequate but with a clear gap.

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

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

Schema description coverage is 0%, so the description must compensate. It defines WOEID (Where On Earth ID), which adds meaning for one parameter, but says nothing about the count parameter, its default of 30, or the WOEID default of 1.

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

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

States a specific verb, resource, and scope: returns trending topics for a WOEID, ranked by position. No sibling tool covers trending topics, so an agent can select it without confusion.

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

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

The description gives no explicit when-to-use, when-not-to-use, or alternative tools. It mentions WOEID as the input basis, but that is a parameter fact, not usage guidance.

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

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

Annotations only assert readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — pagination contract (returns has_next_page + next_cursor, pass next_cursor as cursor) and credit cost model (13/tweet, 15 minimum, waived on bulk). This is meaningful disclosure the annotations do not carry.

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

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

Front-loaded with purpose, then cleanly sectioned into queryType, paging, and credits. Dense but every block earns its place; no filler or repetition.

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

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

For a complex search tool with no output schema and 0% param coverage, the description covers purpose, filter syntax, the two query modes, pagination, and cost. It stops short of describing result shape or rate/result limits, but the essentials for a correct call are present.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: it enumerates the query operator syntax (from:, since:, min_faves:, filter:media, etc.), defines queryType's two values, and ties cursor to the returned next_cursor. Minor gap is no explicit format/limit notes on the cursor beyond re-use.

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

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

States a specific verb+resource ('Search posts') scoped to 'full query syntax' with author/date/language/media/engagement operators. Clear what it does, but it never distinguishes itself from the sibling 'search' tool, leaving the agent to infer why the 'advanced' variant exists.

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

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

Explains the queryType choice ('Latest' chronological default vs 'Top' engagement-ranked), which is useful routing. However it offers no explicit when-to-use-this-vs-alternatives guidance against siblings like search, user_search, or list_tweets_timeline.

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

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

With annotations already declaring readOnlyHint=true and openWorldHint=true, the description adds useful behavioral context: it explains pagination return fields ('has_next_page + next_cursor'), how to continue paging, and the credit cost model. It does not cover authentication or rate limiting beyond credits, but for a read-only paginated endpoint this is a strong disclosure.

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

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

The description is three short, front-loaded lines: purpose first, then pagination mechanics, then credit cost. Every sentence carries actionable information, and there is no filler.

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

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

For a simple, read-only, paginated endpoint with annotations covering safety and open-world behavior, the description explains the return pagination model and credit cost. It omits tweetId semantics, but an agent can infer that tweetId identifies the tweet whose quotes are paginated; the remaining omission is minor rather than blocking.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does by explaining that 'next_cursor' should be passed as 'cursor' for more results, which adds real meaning beyond the schema. However, it says nothing about the required 'tweetId' parameter — its format, source, or behavior — leaving a significant gap for one of only two parameters.

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

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

The description gives a specific verb and resource: 'Page through quote posts,' and adds a parenthetical definition — 'reposts that added commentary' — that distinguishes quote posts from retweets and replies. It does not explicitly name sibling alternatives, but the resource itself is clear enough for an agent to distinguish it from tools like tweet_replies or tweet_retweeters.

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

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

The description implies the use case by defining quote posts as reposts with commentary, which helps distinguish this tool from reply- and retweet-focused siblings. However, it never states when to choose this over alternatives or any exclusions, so guidance is only implied rather than explicit.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description goes beyond that with two genuinely useful traits not in structured fields: the pagination contract (returns has_next_page and next_cursor, pass next_cursor as cursor) and the credit cost model (13 per tweet, minimum 15 per call, waived on bulk). It does not mention auth or rate limiting, but the cost disclosure is substantive added value.

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

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

Four short lines with zero filler; the core action and scope come first, followed by pagination mechanics and cost. Every line carries distinct information an agent needs.

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

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

With no output schema, the description partially covers returns by naming has_next_page and next_cursor, and it covers scope and credits. It does not describe the reply objects themselves (fields, whether nested replies are included), which is the main remaining gap for a no-output-schema tool.

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

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

Schema description coverage is 0%, so the description carries the full burden for the two parameters. It handles cursor well by explaining the round-trip ('pass next_cursor as cursor'), and tweetId is identified as the post whose replies are fetched. It still omits any ID format or validity expectations, so it is good but not complete compensation.

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

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

States a specific verb and resource: 'Page through the direct replies to a post.' The scope ('direct replies', 'under tweetId') is precise, and an agent can infer this is a reply-listing tool. However, it never acknowledges the sibling tweet_replies_v2 or explains how the two differ, which is a real risk given the near-identical names.

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

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

Usage is implied by the phrase 'direct replies' and the tweetId requirement, giving the agent a reasonable sense of when the tool applies. But there is no explicit when-to-use/when-not guidance and no routing to alternatives such as tweet_replies_v2 or tweet_thread_context, which is exactly what an agent needs here.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is set. The description goes beyond them usefully by disclosing pagination semantics (returns has_next_page + next_cursor) and a concrete cost model (13 credits/tweet, min 15, waived on bulk) — genuinely actionable 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.

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

Three tight, front-loaded segments (purpose, paging, cost) with no filler. Every sentence carries information; the key differentiator and mechanics come first.

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

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

For an annotated read-only retrieval tool with no output schema, the description covers paging and cost adequately. However it omits queryType semantics and tweetId format, and the unresolved ambiguity of 'Replies to a post' leaves some gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the burden. It explains cursor well ('pass next_cursor as cursor for more'), but leaves tweetId (format/identity) and queryType (valid values, effect of default 'Relevance') undocumented in both schema and text. Partial compensation only.

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

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

States a specific verb+resource ('Replies to a post') and adds a differentiating trait vs the sibling tweet_replies: 'newer timeline shape, which preserves conversation threading more faithfully.' The phrasing 'Replies to a post' is slightly ambiguous between an action and a retrieval, but the paging/cursor context clarifies it is a read.

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

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

No explicit when-to-use or when-not guidance. It never mentions the sibling tweet_replies tool or the conditions under which the older shape would be preferred, leaving the agent to infer selection from 'newer' alone. Describes mechanics (paging, credits) but not usage context.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description meaningfully adds beyond them: it discloses pagination mechanics (has_next_page + next_cursor) and an explicit credit cost model (15 per user, min 15, waived on bulk). These are genuinely useful operational traits an agent cannot get from annotations. It stops short of auth or rate-limit details.

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

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

Three short lines, front-loaded with the core purpose, then pagination, then cost. Every clause carries distinct information with no repetition. The structure is easy for an agent to parse at a glance.

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

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

With no output schema, the description helpfully explains the pagination envelope (has_next_page + next_cursor) and the cost, which covers most of what an agent needs. The shape of the returned account objects themselves is not described, which is the only real gap for a simple two-parameter read tool.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It does explain the cursor parameter well by tying next_cursor to cursor for continuation, but tweetId is only implied by "a post" and gets no format or type clarity. Partial compensation, so a 3.

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

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

The description states a specific verb and resource ("List the accounts that reposted a post") with the scope tightly bound to a single post. It naturally distinguishes this from siblings like tweet_quotes and tweet_replies, which target different relationships to the same post. An agent can identify the correct tool without opening the schema.

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

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

Usage is implied by the purpose, and the pagination note explains how to continue a result set, but there is no explicit when-to-use/when-not guidance or named alternatives. Relevant siblings such as tweet_quotes or tweet_replies (other ways to enumerate accounts around a post) are never referenced. Minimum-viable rather than instructive.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely non-structured context: credit pricing (13 per tweet, 15 minimum, waived on bulk). It still omits failure behavior for invalid/expired ids and any pagination or batch-size limits.

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

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

Three tight lines: purpose first, parameter format second, cost third. No filler, and the most important information is front-loaded.

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

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

No output schema exists, and the description compensates by naming the returned fields. Combined with cost disclosure for a single-parameter bulk tool, it is nearly complete, missing only error/limit behavior.

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

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

Schema coverage is 100% so the baseline is 3, and the description goes beyond the schema's terse 'comma-separated tweet ids' by supplying a concrete format example ("20,1234567890").

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

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

States a specific verb and resource: 'Hydrate many post ids into full post objects in one call', plus the returned payload shape (author, metrics, media). It is distinguishable from search-style siblings by its id-driven hydration semantics, though it never names a sibling explicitly.

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

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

No when-to-use, when-not-to-use, or alternative is given. An agent cannot tell from the description when to hydrate by ids versus calling search or tweet_advanced_search, nor that it must already hold valid ids.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description goes beyond them by disclosing pagination mechanics ('has_next_page + next_cursor; pass next_cursor as cursor') and a non-obvious credit cost model with a per-call minimum and a bulk waiver. These are real operational traits an agent needs, though it does not say whether hidden/deleted ancestors are excluded.

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

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

Three short, front-loaded lines: purpose first, then pagination, then cost. No filler, and each line conveys distinct information.

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

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

With no output schema and no parameter descriptions, the description compensates well by naming the returned pagination fields and the cost model. The main remaining gap is the shape of the thread payload (orders, nesting, inclusion of ancestors vs replies), but the description is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must carry the burden. It does explain the cursor parameter's role ('pass next_cursor as cursor for more'), which is genuinely useful, but tweetId is left entirely unexplained – the agent must guess whether it takes a numeric ID, a URL, or a handle.

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

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

The description states a specific verb and resource ('Return a post together with its ancestors and replies') and defines the scope as rebuilding a whole conversation thread. That scope implicitly separates it from siblings like tweet_replies, which return only the reply branch, though no sibling is named outright.

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

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

The phrase 'so you can rebuild the whole conversation thread' implies the use case, but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of the alternatives (tweet_replies, tweet_replies_v2, tweet_quotes) that overlap with this tool. The agent must infer selection from context.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds two genuinely useful behavioral facts beyond structured data: the per-call cost (15 credits) and that fields are conditionally present depending on what the account publishes. It does not discuss auth requirements or partial-failure behavior.

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

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

Two short lines with the purpose front-loaded and nothing redundant. The cost note is placed last, which is appropriate, though the quoted 'about' panel naming is slightly jargon-dependent.

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

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

For a read-only, single-parameter tool with no output schema, the description does the essential work: it names the returned fields, flags conditional availability, and discloses the credit cost. It stops short of covering error cases or clarifying how it differs from user_info.

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

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

Schema description coverage is 0% for the single required userName parameter, but the parameter name is self-explanatory and the description's mention of 'a profile' reinforces that it identifies a target user. No format or lookup semantics (ID vs handle) are clarified, so it neither compensates for nor worsens the gap.

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

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

States a specific verb and resource ('return the extended about panel for a profile') and enumerates the returned fields (category, location, website, joined date), so the agent knows exactly what this yields. It does not, however, contrast itself with the obvious neighbor user_info, leaving the agent to infer the difference.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named despite several sibling profile tools (user_info, user_batch_info_by_ids) that could serve overlapping needs. The caveat 'where the account publishes them' is the only implicit scoping signal.

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

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

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description usefully adds a cost model not present in structured fields: 15 credits per user, minimum 15, waived on bulk. It stops short of noting error handling or partial-failure behavior for invalid ids.

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

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

Two short sentences, front-loaded with the core operation and followed by the pricing caveat. No filler, and every clause carries actionable information.

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

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

For a single-parameter read-only batch tool with no output schema, the definition covers purpose, cost, and batch scope adequately. The only minor gap is how return values are shaped (e.g., mapping ids to profiles) and what happens on unknown ids.

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

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

Schema coverage is 100% and documents userIds as a comma-separated string, so the baseline is 3. The description adds that the ids are numeric and that many can be supplied at once, which meaningfully reinforces the format beyond the schema.

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

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

The description states a specific verb (Resolve), resource (numeric user ids), and output (full profiles), with the batch scope made explicit ('in one call'). It implicitly contrasts with individual lookup, which maps to sibling user_info, but never names that sibling directly.

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

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

It gives a clear selection signal — use this for bulk resolution because it is 'far cheaper per user than looking them up individually' — which steers the agent away from per-id calls. There is no explicit when-not condition or named alternative, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful operational context with the per-call credit cost (30 credits), but does not describe return format, permissions, 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.

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

Two short sentences with the purpose front-loaded and the cost second. Every sentence earns its place and there is no redundant or filler content.

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

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

For a simple read-only check tool, annotations cover safety and the description gives cost, but the lack of an output schema and the absence of parameter detail leave the return shape and input format unspecified. The definition is functional but incomplete for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only refers to 'two accounts' without mapping source_user_name and target_user_name or explaining accepted identifier formats or directional semantics.

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

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

The description states a specific verb ('Check') and resource ('follow relationship between two accounts') and specifies scope ('in both directions'), which distinguishes it from sibling list tools like list_followers and user_followings. An agent can identify the operation without opening the schema.

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

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

Usage is implied by the verb 'Check' and the both-directions scope, but there is no explicit when-to-use guidance, no when-not-to-use guidance, and no alternative sibling named. The agent must infer that this is for relationship checks rather than bulk listing.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description goes beyond them by disclosing result ordering, the pagination contract (has_next_page + next_cursor), and a detailed cost model with a per-call minimum. It does not state auth requirements or rate limits beyond credits, but the added behavioral detail is substantial.

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

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

Three short, front-loaded sentences with zero filler: purpose and ordering first, then pagination, then cost. Every sentence earns its place.

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

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

With no output schema, the description correctly explains the return shape (has_next_page + next_cursor) along with cost and pagination. It omits what fields each follower record contains and any auth prerequisites, but is otherwise complete for a paged list tool.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It explains cursor well ('pass next_cursor as cursor for more') and userName is self-evident, but pageSize is never described and its relationship to the per-call minimum is only implied, leaving one of three parameters under-specified.

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

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

States a specific verb and resource ('page through the accounts that follow a user') plus ordering ('newest follower first'), which clearly distinguishes it from user_followings. It does not, however, differentiate from the sibling list_followers, leaving ambiguity about which account-listing tool to choose.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as list_followers, user_verified_followers, or user_followers_ids. The pagination mechanics imply a paging use case, but the agent gets no routing help between the several follower-listing siblings.

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

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

Annotations only cover readOnlyHint/openWorldHint, so the description carries real load and delivers: pagination contract (has_next_page + next_cursor, feed next_cursor back as cursor), a tiered credit cost model, and a 15-per-call minimum with a bulk waiver. It omits error/rate-limit behavior and auth requirements, but the cost and pagination disclosure is well beyond what the annotations provide.

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

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

Three short, front-loaded blocks — purpose first, then pagination, then cost — with no filler sentences. Every line earns its place and the routing rationale leads.

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

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

With no output schema, the description adequately describes the return shape (ids only, plus paging fields) and the cost model. The one gap is that it never clarifies how the target account is identified, notable given 0 required parameters and both userId/userName being optional.

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

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

Schema description coverage is 0% with 4 parameters, so the description must compensate. It explains cursor semantics ('pass next_cursor as cursor for more') which is genuinely useful beyond the bare default of -1, but it says nothing about how userId vs userName select the target or what count/default 5000 means, leaving half the parameters undocumented in both places.

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

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

States a specific verb+resource ('Return follower ids only') and immediately distinguishes itself from the profile-returning siblings by emphasizing IDs-only output and pagination. An agent can tell it apart from user_followers / list_followers / user_verified_followers without opening a schema.

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

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

Gives clear context: 'The cheapest way to snapshot a big follower graph before hydrating the profiles you care about' tells the agent when this tool is the right first step versus fetching full profiles. It does not explicitly name the sibling to use for hydration, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description goes further by disclosing the pagination contract (has_next_page + next_cursor, pass next_cursor as cursor) and the credit cost model with a minimum and bulk waiver. The cost phrasing ('tiered by page fill') is somewhat cryptic, keeping it just short of a 5.

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

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

Three short, front-loaded lines: purpose first, then pagination mechanics, then cost. No filler sentences and every line carries operational information.

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

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

With no output schema, the description usefully names the return fields (has_next_page, next_cursor), and annotations cover the read-only profile. The remaining gap is the unaddressed ambiguity with user_followers/list_followers and the undocumented pageSize, which an agent may need to call correctly.

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

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

Schema description coverage is 0%, so the description carries the burden; it explains cursor use well, and userName is self-evident, but pageSize (default, maximum, valid range) is undocumented in both schema and description, leaving one of three parameters opaque.

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

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

States a specific verb and resource ('Page through the accounts a user follows, newest first'), which an agent can distinguish from a bare 'list users'. It does not, however, name or contrast with the confusingly similar sibling user_followers (accounts following the user) or list_followers, leaving differentiation to inference.

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

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

Usage is implied by the purpose statement and the paging contract, but there is no explicit when-to-use / when-not-to-use guidance and no routing to alternatives such as user_followers, user_followers_ids, or user_verified_followers. Adequate but leaves the agent to figure out which following/follower tool applies.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the safety profile is clear. The description adds real behavioral detail beyond that: a concrete credit cost ('15 per call') and a downstream dependencies hint about the returned `id`. It stops short of return shape or caching/rate behavior, so not a 5.

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

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

Three tight sentences, front-loaded with purpose, then param format, then cost and chaining. Every sentence earns its place with no repetition of structured data.

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

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

With no output schema, the description must cover returns — and it lists the profile fields plus the `id` needed for chaining. Combined with the cost note and param format guidance, an agent has everything required to call this correctly.

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

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

Schema description coverage is 0%, so the description carries full burden — and it does: 'Pass userName = the handle without @ (e.g. "jack")' gives exact format and a concrete example. This fully compensates for the undocumented schema property.

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

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

States a specific verb and resource — 'Look up a single profile by its @handle' — and enumerates the returned fields (bio, counts, verification state, avatar, banner). The word 'single' implicitly separates it from the batch sibling user_batch_info_by_ids without needing to name it.

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

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

Usage is implied rather than stated: the chaining hint 'The returned `id` is what tools taking userId need' tells the agent this is the entry point for userId-based tools, which is genuinely useful. However, there is no explicit when-to-use or when-to-prefer-an-alternative guidance against siblings like user_about or user_search.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description adds real behavioral context beyond them: pagination semantics (has_next_page + next_cursor, ~20 per page) and an explicit cost model (13 credits per tweet, 15 minimum, waived on bulk). It does not describe rate limits or auth requirements, but for a read tool this is above-average disclosure.

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

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

Four short, front-loaded lines that each carry information; the paging and credit facts are separated cleanly. Minor redundancy: 'newest first' appears twice, wasting part of a very short text.

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

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

There is no output schema, yet the description compensates by naming the returned paging fields (has_next_page, next_cursor), which is exactly what an agent needs for iteration, plus a cost model. The only material omission is any explanation of includeReplies and of how this feed differs from sibling timeline tools.

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

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

Schema coverage is 0%, so the description must carry parameter meaning, and it does explain userName vs userId (either/or), cursor (pass next_cursor), and the ~20-per-page page size. However the includeReplies parameter is never mentioned or explained, leaving one of four parameters undocumented in both schema and description.

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

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

States a specific verb+resource+scope ('a user's most recent posts and reposts, newest first'), which is clear enough to distinguish from sibling feeds like user_mentions. However it never contrasts itself with the very similar siblings user_tweet_timeline or tweets, so the agent cannot be fully certain which to pick from the name alone.

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

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

Gives parameter-level usage guidance ('Pass userName (handle) or userId') and explains paging continuation via cursor, which is genuinely useful. But it offers no when-to-use/when-not guidance relative to overlapping siblings such as user_tweet_timeline, 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.

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), but the description adds genuinely useful behavior: pagination contract (has_next_page + next_cursor), ordering (newest first), and a precise credit cost (13 per tweet, min 15, waived on bulk). This is real context beyond the structured fields.

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

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

Three tight, front-loaded paragraphs — purpose, pagination, cost — each earning its place with zero filler or repetition of the structured fields.

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

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

With no output schema, the description usefully sketches the return shape (cursor fields) and cost model, which is what an agent needs to page correctly. It is slightly short on userName input semantics, but otherwise complete for a two-parameter read tool.

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

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

Schema description coverage is 0%, so the description has to carry parameter meaning. It explains cursor usage well ('pass next_cursor as cursor for more'), but says nothing about the required userName format (handle vs. ID, leading @), leaving half the parameters under-documented.

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

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

States a specific verb and resource ('Return posts that mention a user') with scope ('newest first') and a clarifying frame ('the account's inbound conversation'). This distinguishes it implicitly from reply/timeline siblings, but it never names an alternative tool explicitly, so it lands at 4 rather than 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The description never references the many adjacent siblings (tweet_replies, user_tweet_timeline, search), so an agent must infer the boundary between 'mentions' and 'replies' on its own.

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

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

Although annotations already declare readOnlyHint and openWorldHint, the description adds genuinely useful behavior beyond them: the pagination contract (returns has_next_page + next_cursor, and how to pass next_cursor back) and the credit cost model (15/user, min 15, waived on bulk). These are operational details the agent cannot infer from annotations.

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

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

Three short, front-loaded lines with no filler; the core purpose, pagination, and cost are each stated once. Only minor vagueness ('waived on bulk') keeps it from being maximally crisp.

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

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

For a two-parameter search with no output schema, the description covers the operation, pagination, and cost. It lacks detail on query matching semantics and sibling routing, but is otherwise sufficient to call the tool correctly.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains `cursor` well via the pagination paragraph, but `query` is only glossed as 'keyword' with no format, matching, or scope details. Partial compensation for the coverage gap warrants a mid score.

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

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

States a specific verb and resource ('Search profiles ... return matching users ranked by relevance'), which is clearly distinguishable from profile-fetching siblings like user_info or user_batch_info_by_ids. However, it does not explicitly contrast with the general-purpose `search` sibling, so the agent must infer the boundary.

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

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

The description implies the use case ('by keyword', returns ranked matching users), but gives no explicit when-to-use versus the general `search` tool or the ID-based user tools. 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.

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

Annotations already declare the safe read-only, open-world profile, and the description meaningfully adds to that: an explicit pagination contract (returns has_next_page + next_cursor, pass next_cursor as cursor) and a cost/rate model (13 credits per tweet, min 15 per call, waived on bulk). Auth needs and non-pagination output shape are not covered, keeping it short of a 5.

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

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

Three tight lines, front-loaded with purpose, then pagination mechanics, then cost. Each sentence adds distinct, non-redundant information with zero filler.

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

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

With no output schema, the description steps in to explain the pagination return fields and the credit cost, which is the information an agent most needs. It falls short of complete only because includeParentTweet and the exact includeReplies behavior remain unexplained for a 4-parameter tool.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet it only clarifies the cursor parameter (pass next_cursor as cursor). The required userId and especially the includeParentTweet toggle get no explanation, and includeReplies is only loosely implied by 'including replies'.

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

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

States a specific verb (Return) and resource (a user's full timeline including replies), and pins the scope with a concrete analogy to the profile's posts-and-replies tab. It distinguishes itself from narrower siblings like user_last_tweets or user_mentions implicitly through the 'full timeline including replies' framing, though it never names an alternative.

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

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

Usage is only implied through the 'full timeline including replies' scope, which suggests this is for complete history rather than targeted lookups, but no explicit when-to-use or when-not-to-use guidance is given and no sibling is named as the alternative.

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

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

Annotations cover safety (readOnlyHint, openWorldHint), and the description adds genuinely non-obvious behavior: the return envelope (has_next_page + next_cursor), the pagination loop, and a tiered credit cost model with a minimum and bulk waiver. These cost and pagination details are exactly the kind of context annotations cannot supply.

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

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

Front-loaded purpose, then a dedicated pagination line, then a dedicated credits line. Three tight segments, no filler, and the most decision-relevant info comes first.

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

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

For a paginated list tool with no output schema, the description supplies the pagination contract and cost model. It does not describe the shape of the returned verified-account objects or page-size limits, a minor gap.

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

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

Schema coverage is 0%, so the description must carry the load. It explains the cursor parameter precisely ('pass next_cursor as cursor for more'), which is the only non-obvious parameter; user_id is self-evident. This compensates well for the empty schema.

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

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

The description uses a specific verb ('Page through') and a scoped resource ('only the verified accounts that follow a user'), which implicitly distinguishes it from sibling user_followers/list_followers by the 'verified' filter. It stops short of naming the sibling it is not, so an agent must infer the difference.

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

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

'useful for gauging reach among notable accounts' gives a use case, so usage is implied. However, it never states when to prefer this over user_followers or list_followers, nor any exclusions, leaving alternative selection to inference.

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