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

With no annotations, the description carries the full behavioral burden, and it does supply meaningful traits: it is deterministic, performs a membership check, captures screenshots, handles composer recovery, and verifies the post in the feed. It still omits prerequisites (account must be switched in?), auth requirements, and failure behavior, but the disclosed flow is richer than a bare 'posts' statement.

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?

A single dense sentence that front-loads the action and resource before listing phases; there is no filler. The list of phases is slightly feature-catalog-flavored but each item earns its place by hinting at robustness behavior.

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 4-parameter composite tool with no output schema and no annotations, the description covers the execution phases but leaves out key operational context: required preconditions (signed-in account, community membership state), what the screenshots/verification return, and how failure/recovery surfaces to the caller.

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 100%, so the schema already documents url, join (defaults true), text, and account. The description adds no parameter-level detail (e.g., what happens when join is false, or how account relates to the switcher), so the baseline of 3 applies.

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 ('Run') and resource ('community-post task') and enumerates the constituent phases (membership check, screenshots, composer recovery, feed verification), which signals a composite orchestration tool rather than an atomic action. This implicitly separates it from atomic siblings like x_open_community or x_create_post, though it never names an alternative 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 description describes what the task contains but gives no explicit guidance on when to choose this composite task over chaining the atomic siblings (x_open_community + x_create_post + x_verify_text_visible). No prerequisites, no exclusions, no alternatives are named.

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 no annotations, the description carries the full burden, and it does disclose genuinely useful internal behavior: button-state verification and an automatic real-typing fallback when X rejects the initial input. However, it omits key operational facts for a public, non-reversible write — whether authentication is required, where in the UI it must be invoked, and whether the post can be undone or deleted.

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?

A single front-loaded sentence with no filler; the verb and target are first, and the fallback detail is a reasonable behavioral note rather than padding. It is tight, though the composer/verification detail is arguably implementation-level rather than selection-level.

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 and no annotations, so the description should also say what a successful call yields (post ID/URL) or what failure looks like; it does not. It covers the mechanism adequately for a one-parameter tool but leaves the agent without any return-value or error expectations.

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 100% with a single, self-explanatory 'text' parameter, so the schema already does the work and the description adds no syntax, length-limit, or formatting guidance beyond it. Baseline 3 is appropriate.

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 precise verb+resource ('Create a new X post') plus the mechanism scope ('from the home composer'), which implicitly separates it from the reply (x_reply_to_post) and quote (x_quote_post_task) siblings that compose from different surfaces. An agent can tell what this does 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 only implied by 'Create a new X post' — the agent can infer this is the tool for a top-level post, but no alternatives are named and no when-not conditions are given (e.g., use x_reply_to_post for replies, x_quote_post_task for quotes). No prerequisites such as being logged in or on the home page 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?

With no annotations, the description carries the full burden but does add real traits: 'deterministic', account switching, screenshots, and a persisted run journal. It stops short of disclosing permission needs, reversibility of the like/repost mutations, or failure behavior for a stateful multi-step tool.

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?

A single front-loaded sentence that lists the composite capabilities without filler or redundancy.

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 4-parameter mutating task with no annotations and no output schema, the description lists features but omits the two things an agent most needs: when to choose it over its many siblings, and the side-effect/auth profile of an operation that switches accounts and performs engagement actions.

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 url, account, like, and repost (including their defaults) are already fully documented in the schema. The description's 'optional like/repost actions' and 'account switch' merely restate those fields, adding no syntax or format detail 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?

States a specific verb (run) and resource (engage-post task) and enumerates the composite behaviors: account switch, screenshots, optional like/repost, journal. It implies differentiation from atomic tools like x_like_post by describing itself as a bundled task, but never names a sibling to disambiguate.

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 guidance on when to use this composite task rather than the atomic x_like_post/x_repost_post or the generic x_switch_account_and_act_task. The reader must infer the intended scenario from the feature list 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?

No annotations are supplied, so the description carries the full behavioral burden. It says the tool 'opens' the community but does not disclose whether this requires the browser to be on a logged-in session, whether it navigates the page as a side effect, whether it waits for load, or what happens on a private/restricted community where metadata is not visible.

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?

A single front-loaded sentence with no filler. Slightly low on information density but structurally clean.

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-URL extraction tool with no annotations and no output schema, the description covers the high-level return shape but omits authentication prerequisites, navigation side effects, and error behavior. It is minimally adequate but leaves real gaps given the lack of structured disclosure elsewhere.

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 100% and there is only one parameter, whose meaning ('Full X community URL') is fully specified in the schema. The description adds no parameter-level detail, so baseline 3 applies.

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 ('Open') and resource ('community') and enumerates the returned metadata (name, description, member/post hints, join state). It does not differentiate from sibling x_open_community, which likely navigates to the community rather than extracting structured metadata — the description would be stronger if it named that distinction.

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 guidance and no mention of alternatives. The sibling set contains x_open_community, x_search_communities, and x_map_community, all plausible confusions, yet the description offers no routing criteria.

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?

No annotations are supplied, so the description carries the full burden. It does disclose two useful behaviors: that the tool opens/navigates a post (a side effect, not a pure read) and that stats are limited to those 'visible' in the session. It stops short of stating auth requirements, tab-creation side effects, 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?

A single front-loaded sentence that names the operation and the output shape with zero filler. Nothing is wasted or 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?

The description names the return record fields, which partly compensates for the absence of an output schema. But with no annotations and no output schema, it should say more about side effects, permissions, and how it differs from x_open_post; that boundary gap directly affects correct tool selection.

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 100%, and both parameters (url, tabId) are documented in the schema, including the meaning of reusing an existing tab. The description adds no further parameter semantics, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Open a post') and enumerates the returned record fields (author, text, media, visible stats), so the agent knows exactly what this tool produces. However, it never distinguishes itself from adjacent siblings like x_open_post or x_get_post_thread, leaving the agent to 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. With siblings x_open_post and x_get_post_thread present, the agent gets no signal for choosing x_extract_post over them, which is a real selection hazard.

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 no annotations, the description carries the full burden and it does disclose the return shape and the 'when visible' caveat implying possibly-absent data, plus 'Open' signals a tab side effect reinforced by the tabId param. It omits auth/permission requirements, rate limits, and whether data is cached or freshly fetched.

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?

A single tight sentence, front-loaded with the verb and resource with zero filler. Every clause (bio, stats, pinned post, when visible) 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 specifies the return fields, which is the main burden here. It is slightly incomplete in not routing between itself and the profile-oriented siblings, but the payload description covers the essentials.

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 both parameters (tabId, username) are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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 (open/extract) and resource (profile) plus the exact return payload (bio, stats, pinned post), which distinguishes it from x_get_profile_posts. However, it never names the closest sibling (x_open_profile) to clarify how extraction differs from mere navigation.

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 or when-not-to-use guidance is given, despite siblings like x_open_profile, x_get_profile_posts, and x_search_profiles competing for the same intent. Usage must be inferred entirely from the return payload.

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 no annotations, the description carries the full disclosure burden. It does add value by noting the tool verifies the resulting follow state and acts on the active account, but omits auth requirements, what happens if already following, rate-limit behavior, and failure semantics.

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?

A single tight sentence that front-loads the action and pairs it with the verification outcome. No padding or redundant restatement of the name.

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 two-parameter action tool with no output schema, the description covers the core action and hint at verification. However, with zero annotation coverage it leaves mutation-side behavioral details (permissions, idempotency when already followed, error handling) undocumented.

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 100%, so tabId and username are already documented. The description adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb (follow) and resource (X profile), plus the added scope of verifying the resulting follow state from the active account. It is clear on its own, but does not distinguish itself from the confusing sibling x_follow_profile_task, leaving an agent to guess at the split between them.

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

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

No explicit when-to-use guidance, prerequisites, or exclusions are given. The presence of the near-identically named sibling x_follow_profile_task makes routing ambiguous, yet the description offers no condition to pick one over the other.

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 no annotations, the description carries the full burden. It usefully discloses that the task switches accounts, captures screenshots, and verifies profile state, and 'deterministic' hints at repeatability. However, it omits that following is a mutating/irreversible action, any auth or permission requirements, and what happens on failure.

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?

A single front-loaded sentence with no filler. It is efficient, though the term 'deterministic' is left unexplained and the enumeration of components is dense rather than prioritized.

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 composite, mutating task with no annotations and no output schema, the description is minimally viable. It conveys the ingredients but not the outcome, failure behavior, or artifacts (screenshots) the caller should expect.

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 both parameters are documented in the schema (account handle/switcher label, username with/without @). The description adds only the notion that account switching occurs, which is already implied by the account parameter, so baseline 3 applies.

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 ('Run a deterministic follow-profile task') and enumerates distinguishing components: account switching, screenshots, profile-state verification. This separates it from the plain x_follow_profile sibling, though it never names that 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 guidance on when to pick this over x_follow_profile, x_switch_account_and_act_task, or manually chaining x_switch_account + x_follow_profile. The agent must infer selection criteria from the name 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?

No annotations are provided, so the description carries the full burden. 'Currently visible' usefully signals a snapshot of live UI state rather than a server-side lookup, but the description does not state access requirements, whether the app must be foregrounded, or behavior when no accounts are present.

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?

A single front-loaded sentence with no filler. It is appropriately sized for a zero-parameter read tool, though it is terse enough that no extra context is offered.

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 should describe the shape of what comes back; it only broadly indicates account identity and switcher entries. For a simple no-param read this is adequate but leaves the return contract underspecified.

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 no parameter semantics to document and the baseline of 4 applies. The description correctly does not invent 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?

States a specific verb (Inspect) and resource (active X account plus account-switcher entries), which lets an agent distinguish it from x_switch_account and the other x_get_state variants. It is clear but not sharply differentiated from sibling read tools like x_get_state.

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 guidance, no prerequisites, and no mention of alternatives such as x_get_state or x_get_state_map. The agent must infer that this is the read-only counterpart to x_switch_account.

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 no annotations at all, the description carries the full behavioral burden. The word 'visible' usefully signals that extraction is limited to currently rendered content rather than API-backed retrieval, but nothing is said about authentication state, scrolling/pagination, rate limits, or whether the feed must already be open.

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?

A single tight sentence with the action verb front-loaded and zero filler. Nothing could be removed without losing 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 simple two-optional-parameter read tool with a fully documented schema and no output schema, the description is adequate but thin. It leaves open what 'current' means operationally and how visible-content limits interact with the limit parameter.

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 100% — both 'url' (full community URL, opened first) and 'limit' (1-30) are documented in the schema itself. The description only loosely restates 'specified' for the url parameter and adds no syntax or format detail, so baseline 3 is appropriate.

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 ('Extract') and resource ('visible posts from ... X community feed'), so an agent knows this reads posts rather than community metadata. It does not, however, differentiate itself from near-neighbors like x_extract_community or x_search_posts, which the agent must disambiguate on its own.

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?

'Current or specified X community feed' implies the two usage modes (default to the currently open community vs. pass a URL), which is useful context. But there is no guidance on when to prefer this over x_extract_community or x_get_timeline, and no stated prerequisites.

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 no annotations, the description carries the full behavioral burden. 'Inspect' conveys a read-only, non-mutating operation and it discloses part of the payload (button enabled flag), but it does not confirm absence of side effects or describe the full shape of what is returned.

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?

A single, front-loaded sentence with no filler. The resource under inspection leads, and the specific detail (button enabled) follows immediately.

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-param read tool with no output schema, the description is close to sufficient but uses 'including', implying the state contains more fields that are never enumerated. An agent knows what it is inspecting but not the complete return shape or how to interpret the enabled flag.

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 for parameter documentation to add and the baseline of 4 applies. No parameters are left ambiguous.

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 ('Inspect') and resource ('current X composer state'), and even names the key datum (whether the Post/Reply button is enabled). It is clearly distinguishable from generic siblings like x_get_state, though it does not explicitly contrast itself with them.

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

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

Usage is only implied: mentioning the Post/Reply button enabled state hints this is a pre-post validation check, but the description never states when to call it, when to prefer x_get_state, or any prerequisite. No explicit when/when-not guidance or alternatives are named.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully flags that only the 'visible' thread is extracted and that a post is opened/navigated to first, but it says nothing about pagination within the thread, auth/session requirements, rate limits, or behavior when the thread is truncated.

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?

A single front-loaded sentence that opens with the action and immediately qualifies the scope. No filler, no restatement of the tool name.

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

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

With no annotations and no output schema, the description is the sole source of behavioral context, and it covers only the extraction target and visibility constraint. For a browser-driving extraction tool, more detail on ordering, truncation, and tab side-effects would be needed to call it complete.

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 100%, so url, limit (1-50) and the tabId reuse behavior are already fully documented in the schema. The description adds no additional parameter semantics, which is the expected baseline when the schema does the work.

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 pair: 'open a post and extract the visible thread/timeline around it as structured post rows.' The scoping phrase 'around it' distinguishes it from x_get_timeline (the caller's own timeline) and x_extract_post (a single post), though it never names those siblings 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?

Usage is only implied by the resource being extracted ('thread/timeline around it'). There is no explicit when-to-use statement, no exclusion of the nearby alternatives like x_extract_post or x_get_timeline, and no prerequisites given.

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 no annotations, the description carries the full burden of behavioral disclosure, yet it only says it opens a profile and extracts visible posts. It does not state authentication requirements, whether it opens a new tab (beyond the tabId parameter), side effects, rate limits, or that it is a read-only operation.

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 a single, front-loaded sentence with no wasted words. It states the core action directly and efficiently.

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 tool with no annotations and no output schema, the description is too sparse. It does not explain return format, error behavior, or how the tool interacts with browser tabs, leaving significant gaps for an agent to infer.

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 100%, so the schema already documents username, limit, and tabId. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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: opening a profile and extracting visible posts from its timeline. It is clear and unambiguous, but it does not distinguish itself from siblings like x_extract_profile or x_get_timeline, so it falls short of the top score.

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 guidance on when to use this tool versus alternatives such as x_extract_profile, x_open_profile, or x_get_timeline. The action is described, but no conditions, exclusions, or alternative recommendations are provided.

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

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

No annotations are provided, so the description carries the full burden. 'Get' signals a read-only operation and the description enumerates the exact state fields returned, which is the key behavioral disclosure for a state-reader. It omits any note on errors, staleness, or tab-resolution behavior, 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?

A single front-loaded sentence with the core verb+resource first and the returned fields after the colon. 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?

With no output schema, the description does the necessary work of naming the return fields, which is sufficient for a zero-parameter state reader. Minor gaps remain around failure modes and how 'current tab' is resolved, but nothing blocks 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate.

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 ('Get') and resource ('structured X page state for the current tab') and enumerates the contents (route, page kind, selected tabs, composer state, account info). It distinguishes itself implicitly from the narrower sibling x_get_composer_state by covering the whole page state, though it never names that sibling.

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 'for the current tab' scopes the tool but gives no explicit when-to-use or when-not-to-use guidance, and does not mention the overlapping siblings x_get_composer_state or x_get_state_map. Usage is implied 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only/non-mutating operation, whether it needs an authenticated session, whether results are static built-ins versus live, or whether omitted 'surface' returns all maps. Only the 'built-in' hint adds any behavioral color.

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?

A single front-loaded sentence with no filler; the verb and the scope of returned maps arrive immediately and every clause 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 and no annotations, the description should at minimum explain what a 'state map' contains, since that is the entire return payload an agent will receive. It names the surfaces but never characterizes the data, leaving a meaningful gap for a lookup 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 100%, and the description's surface list mirrors the schema's list, so it adds little beyond the structured field. The one open question the description could have answered - what happens when 'surface' is omitted - is left unresolved, so a baseline 3 is appropriate.

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 the built-in X state maps' with an enumerated set of surfaces, which is more informative than the bare name. It does not, however, distinguish itself from close siblings such as x_get_state or x_get_composer_state, so an agent cannot tell from the description alone why it would pick this over those.

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 'for flaky surfaces' implies a usage condition (use these maps when the live surface is unreliable), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage must be inferred from the adjective 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?

No annotations provided, so the description carries the full burden. It says 'currently visible' which implies scoping to rendered DOM state, but does not disclose whether scrolling is required, whether extraction is read-only/no side effects, or any rate/visibility constraints.

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?

One front-loaded sentence with no filler. The list of returned fields is compact and useful. Slightly light on context given the crowded sibling environment.

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 one-param extractor with no output schema and no annotations, the description covers the what and the return fields. It omits when to use it versus the many sibling extract/search tools and any behavioral constraints, leaving clear gaps.

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 the single 'limit' parameter is fully documented in the schema with its 1-20 range. The description adds nothing about the parameter. Baseline 3 is appropriate.

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 (Extract) and resource (currently visible X timeline posts) and lists returned fields. Does not name a sibling or differentiate against x_get_profile_posts, x_get_community_feed, or x_extract_post, which is the main gap.

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 guidance or alternatives mentioned. With 37 siblings, an agent must infer from the name alone that this is for the home timeline vs profile or community feeds.

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 no annotations, the description carries the full behavioral burden. It does disclose the three checks it performs, giving some transparency, but it does not state whether the operation is read-only, what permissions are needed, whether it has side effects, or how results are returned.

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?

A single compact sentence front-loads the primary check and then lists the two reporting aspects. There is no filler or redundant wording.

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?

The description covers what the tool checks, which is useful for a zero-parameter diagnostic. However, with no output schema and no annotations, it does not describe the return format or any behavioral details an agent would need to interpret the health report fully.

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 the baseline is 4. There are no parameter semantics to clarify, and the empty schema requires no additional 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?

The description states a specific diagnostic purpose: check whether X is open in SurfAgent, identify the current X page state, and report composer/account readiness. This is clearly distinct from narrower siblings like x_get_state or x_get_composer_state, though it does not explicitly name an alternative tool.

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 as a preflight or diagnostic check before interacting with X, but the description gives no explicit when-to-use guidance, no conditions or exclusions, and no named alternative such as x_get_state or x_get_composer_state.

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 no annotations, the description carries the full behavioral burden. It usefully discloses that the tool verifies the resulting button state after clicking, which is real behavioral context. However, it omits what happens if the post is already liked, auth/rate-limit constraints, and whether the action is reversible.

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?

A single tight sentence that front-loads the action and appends the verification behavior. 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 zero-required-param mutation with no annotations and no output schema, the description should do more: it never explains what the verification step returns or how failures/idempotency are handled. It is adequate but leaves meaningful gaps.

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 100%, so url, tabId, postId, and username are already documented in the schema. The description adds no extra semantics about the url-vs-postId/username fallback logic, so baseline 3 applies.

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 ('Like a specific X post') plus an outcome ('verify resulting button state'). It is clearly distinguishable from siblings like x_repost_post or x_quote_post_task, though it doesn't explicitly address overlap with x_engage_post_task.

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 alternatives such as x_engage_post_task or x_repost_post, and no preconditions (e.g., must be logged in, post must exist). Usage is only implied by the 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?

With no annotations, the description carries the full burden, and it does disclose the multi-step autonomous behavior (navigating, extracting, sampling). It stops short of the operational profile an agent needs: it never states that this is a read-only browser scrape, whether it requires an authenticated session, or that it is slow/expensive because it drives multiple page interactions.

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?

A single front-loaded sentence that names the operation and then the steps, with no filler. It is appropriately sized; only the missing sibling routing keeps it from being exemplary.

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 six-parameter, no-annotation, no-output-schema tool, the description should at least hint at the shape of the mapping bundle it produces and how it relates to the atomic siblings. It covers the inputs' intent but leaves the return artifact and the routing decision unexplained, so it is only adequate.

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 100%, so the schema already documents all six parameters including feedLimit, profileLimit, save, and outputDir. The description's mention of 'extract feed rows' and 'profile a sample' loosely maps to those limits but adds no syntax, ranges, or defaults beyond the schema. Baseline 3 applies.

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 ('Run an autonomous community mapping pass') plus the resource and enumerates the three concrete steps: open community, extract feed rows, profile participants. An agent can tell it is a bundled pipeline. However, it never contrasts itself with the individual siblings (x_open_community, x_extract_community, x_extract_profile), so the 'map' composite is not clearly differentiated from the atomic 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?

There is no when-to-use / when-not-to-use guidance and no reference to the alternative atomic tools that perform the same steps individually. Usage can only be inferred from the word 'autonomous', leaving the agent to guess whether this replaces or supplements x_extract_community and x_extract_profile.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether opening changes app state, requires prior authentication, or what happens if the path is invalid or the section fails to load.

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 action and then the optional parameter behavior. Every clause earns its place with no waste.

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 one-parameter navigation tool with no output schema, the description is adequate: it covers the action and the optional path. It falls short only in not positioning itself against the numerous sibling open_* 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 description coverage is 100%, so the path parameter is already fully documented with examples. The description's mention of home, notifications, search, and profile paths largely restates the schema examples, adding little beyond them; baseline 3 applies.

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 clear verb+resource: opening X in SurfAgent, and mentions it can select a starting section via path. However, it does not distinguish itself from the many overlapping siblings like x_open_home, x_open_search, x_open_notifications, and x_open_profile, which appear to be specializations of this same operation.

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 guidance on when to use this generic opener versus the dedicated section tools (x_open_home, x_open_notifications, x_open_search, x_open_profile). With so many obvious alternatives, the omission of any when/when-not routing is a real gap.

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 no annotations, the description carries the full behavioral burden, yet it only hints that communities trigger special composer behavior without explaining what that means or why it matters. It says nothing about auth requirements, what happens on an invalid/non-community URL, whether it navigates in place, or any side effects.

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

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

Two short sentences with the action stated first and the rationale second; nothing is padded. The second sentence is somewhat vague ('weird composer behavior') but occupies little space, so it is efficient rather than wasteful.

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 navigation tool with no output schema, the description covers what it does and part of why. It is still missing how it relates to the generic x_open, what the URL must satisfy, and any signal about the resulting state, which leaves real gaps for an agent choosing among 35+ siblings.

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 100% - the url parameter is fully documented in the schema as a 'Full x.com/i/communities/... URL'. The description adds no format, validation, or example detail beyond that, so the baseline 3 applies.

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 ('Open an X community URL directly'), which separates it from search/extract siblings like x_search_communities or x_extract_community. It does not explicitly name which sibling it substitutes for, so the agent must infer the boundary with the generic x_open.

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 clause about community navigation having 'its own weird composer behavior' implies this tool exists instead of the generic x_open for community URLs, which is a soft routing hint. There is no explicit when-to-use/when-not statement and no named alternative among the many open_* 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?

No annotations exist, so the description carries the full burden. It usefully discloses one behavioral trait — the call blocks until a 'settled X page state' — which tells the agent it is a synchronizing navigation step. But it says nothing about authentication requirements, failure/timeout behavior, or what a 'settled' state means in practice.

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?

A single, front-loaded sentence with no filler. The action and its completion semantics are stated together efficiently.

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 parameter-less navigation tool with no annotations and no output schema, the description covers the essential action but omits the outcome an agent would want — what state or handle results from the call, and how failures surface. Adequate minimum, but not fully self-sufficient.

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, which is the baseline-4 case. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 ('Open') and a specific resource ('the X home timeline'), so an agent can distinguish it from x_open_notifications, x_open_search, or x_open_profile. It does not, however, clarify how it relates to the similarly named sibling x_get_timeline, leaving a real ambiguity unaddressed.

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 guidance on when to use this tool versus the many other open/get tools (x_get_timeline, x_open, x_open_search). Usage is only implied by the word 'Open'. No prerequisites or alternatives are named.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether authentication or a signed-in account is required, what view/state it opens, or whether it is a read-only navigation action. It only restates the operation.

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?

A single front-loaded sentence with no filler, appropriately sized for a no-argument navigation tool. It is terse rather than padded, though it also adds nothing beyond the name.

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 trivial zero-parameter, no-output tool the description is minimally sufficient, but with no annotations it leaves the agent without any indication of authentication requirements or what 'opening' the view entails.

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 for the description to disambiguate; the baseline for a parameterless tool applies.

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 clear verb ('Open') plus a specific resource ('X notifications'), and the resource name distinguishes it from the other navigation siblings (x_open_home, x_open_profile, x_open_search). It does not explicitly say how it differs from the generic x_open, but the resource specificity is enough to select 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?

No guidance on when to use this versus x_open_home, x_open_search, or the generic x_open, and no prerequisites stated. 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?

No annotations are provided, so the description bears the full burden. 'Open' implies a navigation side effect (likely creating/reusing a browser tab), but the description never states what happens on invocation, whether it requires an active session, or any side effects. The tabId parameter hints at tab behavior but this is not explained.

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?

A single, front-loaded sentence with no filler. It is appropriately sized for the tool, though the brevity contributes to the usage and behavioral gaps.

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

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

With no annotations and no output schema, the description should disclose what opening a post actually does and what the agent gets back. It leaves both the side effect and the result unspecified, which for a navigation tool with only a one-line description is a notable 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 100%, so the schema already documents all four parameters including the tabId reuse behavior. The description adds only the joint semantics that url is an alternative to username + postId, which is baseline value given the schema does the heavy lifting.

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 ('Open a specific X post') and cites the two identification modes (full URL or username + status ID). It is clear what the tool does, though it does not explicitly differentiate itself from siblings like x_extract_post or x_get_post_thread that operate on the same resource.

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 how to identify a post but gives no when-to-use guidance, no alternative tools named, and no exclusions. An agent must infer whether it should use this versus x_extract_post or x_get_post_thread.

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?

No annotations are provided, so the description carries the full burden. 'Open' suggests a navigation/UI action that produces a view rather than a data payload, but the description never confirms this, states whether anything is mutated or persisted, or indicates what the agent sees afterward.

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?

One short sentence, front-loaded with the verb and resource, with zero waste. It is arguably under-specified rather than over-verbose, but it is efficient for a one-parameter tool.

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?

The tool is simple (1 param, no nested objects, no output schema) so a minimal description is defensible, but it leaves an important ambiguity unresolved: whether 'open' navigates a UI context or returns profile data, which matters for sequencing with x_extract_profile and x_get_profile_posts.

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 100% and the single parameter is fully documented ('X username without @'). The description adds nothing beyond 'by username', so the baseline 3 applies.

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 ('Open') and resource ('a profile'), with the lookup key named. It contrasts implicitly with siblings like x_extract_profile and x_search_profiles, but does not explicitly say how 'open' differs from 'extract' or 'get_profile_posts'.

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 guidance, no prerequisites, and no mention of alternatives such as x_extract_profile or x_search_profiles. The agent must infer from the name alone when to navigate to a profile rather than extract or search for one.

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?

No annotations are provided, so the description carries the full burden. 'Open' implies a UI-navigation or state-changing action, but the description never says whether it mutates app state, requires an active session, or what happens to the current view. Behavioral disclosure is largely absent.

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?

A single tight sentence that front-loads the action and states options briefly. No waste, though its brevity borders on under-specification for a tool with many similar siblings.

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 two-parameter tool, the description is minimally sufficient, but with no annotations and ambiguous framing versus the search siblings, it leaves the agent unsure of the tool's exact effect and place in the workflow.

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 100%, so both parameters are already documented. The description's 'prefilled with a query and live filter' loosely maps to the query and mode parameters but adds no format, enum values, or constraint detail beyond the schema, matching the baseline of 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 (Open) and resource (X search), giving a clear high-level action. However, it does not differentiate from siblings like x_search_posts, x_search_profiles, or x_search_communities that actually execute searches, so an agent cannot easily tell whether this navigates a UI or runs a query.

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 guidance on when to use this versus the many sibling search tools. The word 'optionally' implies it can be called with no arguments, but the description never states the conditions or alternatives that select this tool.

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?

No annotations are provided, so the description carries the full burden, and it does well: it discloses the execution model (deterministic), captures screenshots before and after submit, performs account switching, and does profile-level verification. That is meaningful behavioral context beyond a bare verb. It stops short of 5 because failure modes, auth requirements, and what happens on verification mismatch 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?

A single front-loaded sentence with no boilerplate or filler; the task nature and verification steps are introduced immediately. It is a dense feature list rather than a strictly minimal statement, but nothing is wasted.

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 4-param task tool with no annotations and no output schema, the description covers the workflow but omits the operational essentials an agent needs: expected return/confirmation, failure behavior when verification fails, and preconditions such as an authenticated session. Adequate but with clear gaps.

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 100%, so all four parameters (url, like, text, account) are already documented in the schema, including the like default. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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: 'quote-post task'. The description conveys scope (screenshots, account switching, profile verification) so the agent understands this is a full end-to-end task wrapper, not a raw post action. It does not explicitly name a sibling it supersedes (e.g., x_create_post or x_reply_post_task), so it falls short of 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?

The description gives no when-to-use or when-not-to-use guidance and names no alternatives. With siblings like x_create_post, x_reply_post_task, and x_engage_post_task, an agent has to infer that this is the 'quote a post' variant rather than being told.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Lightweight' hints at low impact, but it never says what the action actually performs (reload, re-navigate, dismiss?), whether it has side effects, whether it needs an authenticated session, or whether it is safe to call repeatedly. For a mutation-style action tool with zero annotation coverage this is a significant gap.

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?

A single front-loaded sentence with no filler; the recovery targets are listed compactly. It could be slightly sharper but nothing is wasted.

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

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

With no annotations and no output schema, the description needs to explain what recovery means and what state changes it causes. It enumerates modes but leaves the core behavior, side effects, and result of the action unspecified, which is thin for an action 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 100%, so both parameters are already documented. The description restates the mode values (composer, home, url) and loosely correlates url with mode=url, but adds no new semantics such as default mode or validity constraints.

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 ('apply recovery actions') and resource ('X stuck states'), and enumerates the three recovery targets (composer, home, target URL), which maps directly onto the mode parameter. It distinguishes the tool from siblings like x_get_state or x_health_check, though 'recovery' remains somewhat abstract about what is actually recovered.

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 'for common stuck states' implies the trigger condition (UI is stuck), but gives no explicit when-not guidance and names no alternative — e.g., whether to try x_health_check or x_get_state first. Usage context is present but 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?

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the task is deterministic, it switches accounts, takes screenshots, and verifies the reply on the post surface. However, it omits failure behavior, retry semantics, permission/authentication requirements, and what the tool returns.

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?

A single front-loaded sentence with no filler; the orchestration traits are packed efficiently. It is terse enough that it does not over-explain, though it is arguably too short to fully orient the agent.

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 annotations and no output schema, so the description must do more work for a multi-step side-effecting task. It covers the broad flow (switch account, reply, screenshot, verify) but says nothing about return values, error handling, or preconditions, leaving real gaps.

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 100%, so all four parameters are documented in the schema itself. The description only loosely gestures at the account parameter ("account switching") and adds nothing about url, text, or like semantics, so baseline 3 applies.

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 ("reply-post task") and adds scope modifiers (deterministic, account switching, screenshots, post-surface verification). It distinguishes itself from the plain-action sibling x_reply_to_post by framing this as an orchestrated end-to-end task, though it never names that 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?

There is no explicit when-to-use / when-not-to-use guidance and no mention of the sibling alternatives (x_reply_to_post, x_engage_post_task, x_quote_post_task). The only guidance is implicit in the word "task," leaving the agent to infer that this bundles account switching and verification.

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 no annotations, the description carries full burden and does disclose meaningful internal behavior: pre-submit composer verification, an automatic real-typing fallback, and post-submit visibility verification. These traits help the agent understand the tool is self-verifying and resilient. It still omits auth prerequisites, rate limits, and failure/error behavior, so it is not fully complete.

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?

A single front-loaded sentence that leads with the core action before enumerating verification behaviors. Efficient and well-structured, though the trailing behavior list is packed into one clause.

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 mutation tool with no annotations and no output schema, the description usefully notes post-submit visibility verification (helping confirm success). But it omits prerequisites such as authentication/account-switching needs and what happens when verification fails, leaving gaps for a 5-parameter write operation.

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 100%, so the baseline is 3. The description adds nothing about how url vs postId/username are mutually exclusive or that tabId reuses an existing tab – that conditional logic is only in the schema, so no bonus over the structured fields.

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 ('Reply to a specific post'), which is clear and distinguishable from x_create_post (top-level posting) and x_quote_post_task. However, it never differentiates itself from the near-identical sibling x_reply_post_task, leaving the agent to guess which reply tool applies.

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 guidance and no named alternative among the many reply/post siblings (x_reply_post_task, x_engage_post_task, x_quote_post_task). Usage must be inferred purely from the tool 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?

With no annotations, the description carries the full behavioral burden. It does disclose one trait – that it verifies resulting state after the repost – but says nothing about permissions, idempotency when already reposted, rate limits, or failure behavior 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.

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

A single well-formed sentence that front-loads the action and adds the verification outcome, with 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?

Covers the core action and the verification step, but for a 4-parameter mutation with no annotations and no output schema, the description leaves gaps around preconditions, failure modes, and what 'verified' actually means to the caller.

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 100% and the schema already documents url, tabId, postId, and username including the 'if url is omitted' fallback. The description adds no parameter-level meaning, so the baseline of 3 applies.

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 (repost) and resource (a specific X post) plus an outcome (verify the resulting repost state). An agent can distinguish it from x_like_post, x_reply_to_post, or x_quote_post_task, though it never names an alternative to sharpen the distinction.

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 x_quote_post_task or x_engage_post_task, which also act on a post. No prerequisites (logged-in account, target tab) or exclusions are given.

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 no annotations, the description carries full behavioral burden. It usefully discloses retries, receipts, and a sampling strategy, which is real behavior beyond the schema. However, it omits permissions/auth requirements, expected duration or rate limits, and failure behavior beyond retries for what is clearly a long-running autonomous operation.

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?

A single front-loaded sentence with dense but relevant content; each listed capability (retries, receipts, extractions, sampling) maps to actual behavior. It is efficient, though the trailing list is somewhat run-on.

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 7-parameter autonomous tool with no annotations and no output schema, the definition is adequate but incomplete. It never explains what the research pass returns or what a 'receipt' bundle contains, which matters since output_schema is absent and return values go undocumented.

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 100%, so every parameter (save, outputDir, postLimit, threadDepth, profileLimit, communityLimit) is already documented in the schema. The description adds no syntax, defaults, or format detail beyond what the schema provides. Baseline 3 is appropriate.

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 ('Run an autonomous X research pass for a topic') and enumerates the composite sub-operations (post/thread/profile extraction, community sampling) that differentiate it from atomic siblings like x_search_posts or x_extract_post. It reads as a higher-level orchestrator rather than any single sibling, which is a meaningful distinction. It stops short of explicitly declaring itself the composite of those siblings.

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 word 'autonomous' and the multi-step framing imply this is for comprehensive research passes rather than one-off fetches, but no when-to-use/when-not is stated and no alternatives (e.g. x_search_posts + x_extract_post) are named. Usage is only inferable from the scope wording.

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?

No annotations exist, so the description carries the full behavioral burden, and it discloses little. It implies a read/scrape of a UI 'search surface' but says nothing about session/auth requirements, rate limits, whether results are capped or paginated, or what happens when no communities match.

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?

A single front-loaded sentence with no filler, and the return shape is stated immediately. The trailing phrase 'discovered on the search surface' is slightly vague but not wasteful.

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

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

With no annotations and no output schema, the description does add the return format (community cards/links), which is useful. However it omits prerequisites and behavioral limits that an agent needs to call this browser-style search tool correctly, leaving clear gaps.

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 100%: 'query' and 'limit' (1-20) are both documented in the schema itself. The description adds no query syntax, matching rules, or default-limit behavior beyond what the schema already provides, so the baseline 3 applies.

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 ('Search') and resource ('X communities'), plus what is returned ('community cards/links'). The resource name implicitly separates it from x_search_posts and x_search_profiles, but the description never explicitly contrasts them, so differentiation relies on the reader inferring from the tool name.

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 guidance is given. An agent cannot tell from the text whether this is preferable to x_search_profiles, x_open_search, x_map_community, or x_get_community_feed, nor what preconditions (e.g., an open search surface or active session) must hold.

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?

No annotations are provided, so the description carries the full behavioral burden. It hints that results are live-extracted from the search timeline but says nothing about auth requirements, rate limits, pagination, or what happens when no results match. For a scraping-style tool with zero annotation coverage this is a notable gap.

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?

A single efficient sentence with the action front-loaded and no wasted words. It is appropriately sized, though it is arguably too thin given the tool's behavioral opacity.

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

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

With no annotations, no output schema, and no parameter detail added, the description leaves the agent without a picture of what the returned "extracted results" contain or how large/streamed they are. For a search tool in a crowded sibling set, this is under-specified.

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 both the query and limit parameters are already documented in the schema, including the 1-20 range for limit. The description adds no syntax, query-language, or filtering details beyond that, so the baseline of 3 applies.

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 X posts") and the return nature ("extracted live results from the search timeline"), which distinguishes it from x_get_timeline and x_get_profile_posts. However it does not explicitly name or contrast with its closest siblings x_search_profiles and x_search_communities, 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?

The description gives no when-to-use or when-not-to-use guidance and names no alternatives. With siblings like x_search_profiles, x_search_communities, x_get_timeline, and x_research_topic present, an agent gets no routing signal for choosing this tool.

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 no annotations, the description carries the full behavioral burden, yet it discloses only the return fields. It says nothing about authentication needs, rate limits, pagination, or whether results are cached/curated versus a live query — all relevant for a search crawler over third-party accounts.

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?

A single front-loaded sentence that states the action and the payload with no filler. It is efficient, though it sacrifices coverage for brevity rather than balancing the two.

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, so listing the returned fields is genuinely useful. However, for a limited search tool the description omits any note on result ordering, pagination, or the 20-item cap's implications, leaving the agent with only a minimal picture.

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 100%, so both the query and the 1-20 limit bound are already documented, and the description adds no syntax, format, or operator guidance beyond that. Baseline 3 is appropriate 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.

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

The description gives a specific verb (Search) and resource (X profiles) and even enumerates the returned fields (display names, handles, bios, URLs), which separates it from extraction-oriented siblings like x_extract_profile and x_get_accounts. It does not name any sibling explicitly, so it stops 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?

There is no statement of when to use this tool versus x_search_posts, x_extract_profile, or x_get_accounts, and no prerequisite or exclusion guidance. The word 'Search' implies discovery semantics but the agent must infer the routing itself.

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?

No annotations are provided, so the description carries the full burden. It does disclose a meaningful behavioral trait beyond the schema: the tool changes session state and verifies the resulting active account, which tells the agent the call has a side effect and a read-back. However, it omits error behavior for invalid handles, multi-account ambiguity, or what happens if the target account is not signed in.

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?

A single front-loaded sentence with no filler; the verb and mechanism come first and the verification clause follows. Slightly dense but every clause contributes.

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 mutation tool with no annotations and no output schema, the description covers the action, the mechanism, and the post-condition ('verify the resulting active account state'), which implicitly describes the useful return information. Missing only failure-mode behavior, which is a minor gap at this complexity.

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 100% for the single 'account' parameter, including the @-optional format, so the schema already carries the semantics. The description adds no further detail about matching by handle versus label or how ambiguity is resolved, so baseline 3 applies.

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 (Switch) and resource (X accounts) plus the mechanism (in-session account switcher) and the side effect (verifying resulting active account state). It is clearly distinct from read siblings like x_get_accounts, though it does not explicitly contrast with x_switch_account_and_act_task, which is the closest related tool.

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 'through the in-session account switcher' implies when this tool applies (session-scoped switching), but there is no explicit when-to-use guidance, no mention of prerequisites (e.g., being logged in), and no routing to alternatives such as x_switch_account_and_act_task versus x_get_accounts. 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?

No annotations are provided, so the description carries the full behavioral burden. 'Deterministic' hints at reliability but is never explained — there is no statement about what happens if the account switch fails, whether the switch persists after the action, permission requirements, or error semantics for a tool that mutates session state.

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?

A single front-loaded sentence with no filler, naming the operation and its variadic actions immediately. It is appropriately sized, though it is terse enough that the squeeze comes at the cost of the guidance dimensions rather than from wasted words.

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?

This is a composite, state-mutating task tool with no annotations and no output schema, so the description is the only place failure modes, sequencing guarantees, and post-action state could be documented — and none of that is present. For a tool of this complexity the single sentence is not sufficient to call it safely.

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 100%, including the conditional requirements (url for open-url, username for follow-profile) and the allowed action values, so the schema already does the work. The description's mention of the three actions duplicates schema content and adds no syntax or format detail. Baseline 3 applies.

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 names a specific compound operation — an account switch followed by one of three named actions (open-home, open-url, follow-profile). That is far more concrete than the bare tool name. It stops short of distinguishing itself from siblings like x_switch_account or x_open_home, so an agent can't tell from the text alone why it should pick the bundled tool over the two primitives.

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 guidance: nothing says whether this is preferred over calling x_switch_account and x_open_home sequentially, nor when the bundled form is required. The action list implies possible contexts but never states a condition or an alternative, which is exactly what a multi-step orchestrator tool needs.

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?

No annotations accompany this tool, so the description carries the full behavioral burden. It does not state whether a failed visibility check returns false, throws, or errors, whether it waits/polls for the text, or whether the check is instantaneous — all important for a verification tool with no output schema.

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 core action front-loaded and no filler. The scope sentence earns its place by enumerating targets, though ordering could put the primary purpose even more prominently 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 simple two-parameter verification tool this is close to sufficient, but the absence of an output schema means the description should clarify what a successful versus failed verification yields. It also doesn't describe matching semantics (substring, exact, case sensitivity).

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 100% for both parameters, so the baseline is 3. The description restates the scope values (body, article, composer) but adds no format, matching, or default-scope behavior beyond what the schema already documents.

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 names a specific verb (verify) and resource (text snippet visible on X), which is distinct from every sibling tool's create/read/open action. It is clear what the tool does, though it does not explicitly contrast itself with related state-reading siblings like x_get_state.

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: the scope mention of 'active composer' hints this is used to confirm typed text after an action, but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer the verification workflow from context.

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