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

The description discloses the core behavior (discard) and adds the state constraint 'unexecuted prepared', which is useful context beyond the annotations. However, it does not say whether the discard is reversible, what happens to the action ID afterward, or what error occurs if the action is already executed. The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) are present but sparse, so the description carries some but not full behavioral burden.

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, tightly worded sentence with no filler or redundancy. It front-loads the verb and scope, and every word earns its place. For a tool this simple, this level of conciseness is appropriate.

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?

Although the tool is simple (one required parameter, no output schema, no nested objects), the description leaves out a crucial piece: what the `id` refers to. It also does not mention error behavior (e.g., attempting to cancel an already-executed action) or what result the agent should expect. These gaps make the definition incomplete for reliable invocation.

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

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

Schema description coverage is 0%, and the description never explains that the `id` parameter is the identifier of the prepared action to discard. The agent has to infer this from the tool name and the singular 'unexecuted prepared action'. The description should have explicitly stated something like 'id of the prepared action to discard' to compensate for the missing schema documentation.

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

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

The description uses a specific verb ('Discard') and a clear resource ('an unexecuted prepared action'), and the meaning is immediately distinct from sibling tools like x_action_execute (which would run the action) and x_action_prepare (which creates it). An agent can tell exactly what operation this performs without opening the schema.

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

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

The usage is implied: you use this when you have a prepared action that has not yet been executed and you want to cancel it. However, there is no explicit guidance on when not to use it, no mention of x_action_execute as the alternative for running it, and no stated conditions or prerequisites beyond the action being unexecuted.

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

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

Annotations already show write/destructive and non-idempotent behavior, but the description adds one-shot execution semantics, the consent caveat, the requirement for writes, and a no-automatic-retry rule. These are materially important behavioral details beyond the annotations.

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

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

The description is compact and front-loaded: purpose first, then conditions and safety rules. Every sentence adds distinct value, with no filler or repetition of schema details.

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 destructive, one-shot tool with no output schema, more detail on the expected result would help. The instruction 'read the receipt and inspect X' implies a receipt exists but does not explain what it contains or what 'X' refers to, leaving a meaningful ambiguity in the call/response flow.

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 schema only defines id as a UUID, and the description never explicitly states that id is the prepared action identifier returned by x_action_prepare. It does add some semantics ('An ID is not consent', 'Each ID can be attempted once'), but the core provenance/meaning of the only parameter is left implicit.

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 opens with a specific verb and resource: 'Submit a prepared account action.' This clearly distinguishes the tool from siblings like x_action_prepare, x_action_cancel, and x_action_receipt, and from the many read-only tools in the sibling list.

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

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

It explicitly states the precondition ('Call only with user authorization for its exact account, target and content. Requires writes enabled'), the exclusion ('never retry automatically'), and the fallback ('read the receipt and inspect X'). It also conveys that an ID alone is not consent and that each ID can be attempted only once.

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?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description adds meaningful behavioral context: it does not submit, requires the intended account handle, returns an exact preview, and produces an expiring single-use action ID. It also clarifies target type semantics by action kind. No contradiction with annotations.

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

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

Three sentences with no filler. The verb and scope are front-loaded, followed by the key non-submission trait, then the requirements and return value. Each sentence earns its place.

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

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

Given the lack of output schema and sparse annotations, the description does a good job covering purpose, non-submission behavior, return value, account requirement, and target semantics. However, it omits how the returned action ID is consumed (e.g., with x_action_execute) and does not clarify whether text/target are required for specific actions, which could leave an agent uncertain on edge cases.

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?

With 0% schema description coverage, the description must compensate. It explains expectedAccount ('Requires the intended account handle'), target ('Post targets are X post URLs; follow targets are handles'), and the action enum by listing supported verbs. Text is only vaguely implied as content for post/reply, and target requirement is not fully mapped per action, but it covers most parameter meaning.

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

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

The description uses a clear verb ('Prepare') plus a specific resource ('a specific text post/reply, like/unlike, bookmark/unbookmark, repost/unrepost, or follow/unfollow'). It explicitly distinguishes this from submission ('Does not submit') and from sibling execute/cancel/receipt tools by describing the preview and action ID.

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 clearly signals the tool is a non-submitting preparation step by stating 'Does not submit' and 'returns exact preview and an expiring single-use action ID.' This implies it should be used before x_action_execute, but it does not explicitly name the alternative or state when not to use it. The context is clear, but exclusions are not explicit.

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

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

Annotations already indicate read-only and idempotent, so the description doesn't need to repeat that. It adds useful context about needing inspection before retry, but doesn't disclose other behavioral details like response format or potential delay in availability.

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 sentences with no wasted words, and the key action (read) is front-loaded. It is concise and efficient.

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 with a single parameter and no output schema, but for an action-receipt tool, it lacks details on the interpretation of different receipt states (e.g., what failed vs. uncertain means for retry), which could be important for correct usage.

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 schema has 0% description coverage, so the description must compensate, but it only mentions a receipt, not the 'id' parameter. However, with only one parameter named 'id' and a UUID format, the schema is self-explanatory; the description adds little beyond implying the id is the receipt id.

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 clearly states the tool reads the persisted outcome of an account action. It distinguishes from siblings like x_action_prepare, x_action_execute, and x_action_cancel by focusing on reading the result, though it doesn't explicitly name them as alternatives.

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

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

It implies the use case: reading a receipt after an action attempt, especially for started or failed/uncertain receipts before retrying. However, it does not explicitly state when NOT to use it (e.g., for checking action status) or name alternative tools for retries.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description only needs to add context, which it does by scoping to the signed-in account and 'currently visible' bookmarks and stating the local-snapshot destination. It does not contradict the annotations, but it adds no details about scrolling, overwrite behavior, or 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 focused sentence that front-loads the action and scope with no filler. Every word 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?

For a tool with no output schema and two undocumented parameters, the description omits parameter semantics and does not clarify what the snapshot contains or how maxScrolls affects retrieval. The rich annotations cover safety, but the operational details are too thin for confident invocation beyond defaults.

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

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

Schema description coverage is 0%, and the description does not explain limit or maxScrolls. While 'currently visible' hints at scrolling through the bookmark list, the agent gets no explicit meaning for these parameters beyond their names and defaults.

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 ('Read'), a specific resource ('the signed-in account's currently visible bookmarks'), and a clear target ('a local snapshot'). This distinguishes it from snapshot-reading siblings like x_snapshot_read, which operate on existing snapshots rather than populating them from bookmarks.

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 is given about when to use this tool instead of alternatives, and no exclusions or prerequisites are stated. The intended context (e.g., before x_snapshot_compare or x_export) is only implicit from the sibling list.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond annotations: the result is 'bounded,' only 'visible' connections are included, and completeness is explicitly disclaimed.

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

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

Two tightly written sentences with no filler. The core action and scope are front-loaded, and every clause adds meaningful 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 tool with four parameters and no output schema, the description is too high-level to fully guide invocation. It omits how limit and maxScrolls control the sample, any pagination behavior, and what the response contains. Annotations cover safety but not operational details.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It only loosely maps to handle ('named account'), tab ('followers or following'), and boundedness (limit/maxScrolls), but it does not explain parameter semantics, defaults, or the meaning of maxScrolls, leaving a substantial gap.

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

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

The description states a specific verb ('Read'), a clear resource ('the named account’s visible followers or following list'), and adds a crucial scope qualifier: 'bounded sample.' The sentence 'Does not claim a complete graph' explicitly separates this from snapshot-style tools that promise full data.

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

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

The description implies usage for scenarios needing a limited or approximate view of connections, and the 'does not claim a complete graph' caveat hints that a full snapshot tool would be the alternative. However, it never names a sibling tool or states explicit when-to-use vs. when-not-to-use conditions.

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

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

With all annotations set to false, the description carries the behavioral burden, and it does disclose two meaningful behaviors: the tool returns an absolute local file path (implying a persisted file artifact) and it protects CSV cells against formula execution. It stops short of specifying overwrite behavior or file location, but for a simple export tool this is adequate transparency.

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

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

Three sentences, no filler, with the core action and formats front-loaded. Every sentence contributes either a constraint (existing snapshot), an output promise (absolute path), or a security-relevant detail (CSV formula protection).

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

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

For a two-parameter tool with no output schema, the description covers the key invocation facts: what it exports, in which formats, and what it returns. The main gap is usage guidance (when to prefer x_export over x_review_export), but the operational behavior is sufficiently complete for an agent to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters. It clarifies the format dimension by enumerating JSON, CSV, and Markdown, and adds a CSV-specific safety note, but it never names snapshotId or explains how to obtain/validate it beyond calling it an 'existing local snapshot'. The schema already provides enum/default values, so the added value is modest.

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 operation ('Export'), a specific resource ('existing local snapshot'), and the supported output formats (JSON, CSV, Markdown), making the tool's job unambiguous. It also distinguishes itself from sibling snapshot tools by emphasizing the export/file-creation role rather than read/compare/list.

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 provided, and no alternative sibling is mentioned, despite x_review_export being a closely named export candidate. The only usage signal is implied by the verb 'Export', which is not enough to help an agent choose between export tools.

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?

The description explicitly discloses the side effect that visiting the page can mark notifications as seen, which explains the readOnlyHint=false annotation. This adds valuable context beyond the annotations and warns the agent about state mutation.

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 concise sentences with the primary purpose front-loaded and the side effect stated immediately afterward. Every sentence contributes meaningful information with no 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?

The core purpose and important side effect are covered, and the return shape is hinted at, but the behavior of maxScrolls and how 'visible' notifications are determined remains underspecified. For a simple optional-parameter tool this is acceptable but not 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 0%, so the description carries the burden of explaining parameters, but it does not mention tab, limit, or maxScrolls at all. The enum and bounds in the schema give some clues, but the description adds no parameter-level meaning.

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 clearly states the tool reads visible notifications/mentions and returns text, links, and timestamps. This is specific enough to distinguish it from the sibling tools, though it does not explicitly name an alternative or contrasting 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 description implies the tool should be used to read notifications or mentions, but it provides no explicit guidance on when to use it over sibling tools like x_timeline or x_search. There are no exclusion criteria or alternative routing instructions.

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

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

Annotations already establish readOnly, idempotent, non-destructive, and open-world behavior; the description adds meaningful behavioral detail: 'visible' limits scope and 'Counts are returned as displayed' warns that follower/following numbers may not be exact. This is valuable beyond the annotations and does not contradict them.

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 tight sentences with no filler; the primary action and key fields are front-loaded, and the display-count caveat is a standalone second sentence that 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?

For a simple one-parameter read tool with strong annotations, the description covers the returned content and the important display caveat. It does omit edge cases (private/nonexistent profiles) and the meaning of 'visible', but the tool is otherwise adequately 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?

With schema description coverage at 0%, the description needed to explain the 'handle' parameter, but it never mentions it. The property name and tool name make 'handle' partially inferable, but the description provides no format, identity, or usage nuance.

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?

Description uses a specific verb ('Read') and a bounded resource ('profile header, biography, location, website, displayed follower/following counts'), which clearly separates it from siblings like x_user_posts or x_timeline. The scope is unambiguous and actionable.

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 is given on when to choose this tool over alternatives, nor are any exclusions or prerequisites stated. The only context is implied by the description's name and wording, so an agent must infer when profile-read is appropriate.

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?

The description discloses critical behavioral traits beyond the annotations: operations are local declarations, not proof of human approval or truth, never contact X, and never open a session. It also reveals that preview mode surfaces partial-result warnings and that export requires explicit acknowledgment, giving the agent a strong safety model.

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 dense but well organized into without-review and with-review paths, followed by a crucial safety caveat. Every sentence adds distinct value, and no space is wasted on restating the tool name or input schema.

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 is sufficient for a complex nested-parameter tool with no output schema: it covers both modes, prerequisites, output formats, and local-only behavior. It does not describe the exact export response shape, but the main workflow an agent needs to invoke correctly is fully explained.

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?

With 0% schema description coverage, the description must carry parameter meaning. It explains the review workflow components: snapshotDigest is required for export, acknowledgedPartial must be true, note and format are involved, and recordIds correspond to the user-reviewed IDs. It could more explicitly define snapshotId, but context makes it clear enough.

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 clearly states both operational modes: a read-only preview of a local snapshot without review, and a reviewed export that writes user-approved IDs as JSON or CSV. It also differentiates itself from nearby tools like x_export by emphasizing that all operations are local and never contact X.

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 explicitly tells the agent when to preview (without review) versus when to export (with review), and states required conditions such as snapshotDigest and acknowledgedPartial=true. It does not explicitly name an alternative tool for the no-review export case, but the mode-based guidance is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about local scope and the return content, but does not disclose potential behavioral traits such as ordering, pagination, or how absent snapshot IDs are handled.

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 one concise sentence with no filler. The verb and resource are front-loaded, and the output detail is included 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 zero-parameter, read-only list tool whose annotations already cover the safety profile, the description is complete. It states what will be listed and what output fields are included, which is sufficient for correct invocation.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. This matches the baseline of 4 for parameterless tools.

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

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

The description uses a specific verb ('List') with a clear resource ('local saved search definitions') and adds the output detail ('last successful snapshot IDs'). This distinguishes it from sibling tools like x_saved_search_save and x_saved_search_run by its read-only listing nature.

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 provides enough context to infer that this tool is for viewing saved searches, but it does not explicitly state when to use it instead of alternatives or mention exclusions. Sibling tools like x_saved_search_save/run are not referenced.

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

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

Annotations already establish non-read-only, non-idempotent, non-destructive behavior, and the description adds meaningful side-effect context: it saves a snapshot and compares it. It also clarifies that repeated calls are safe for research automation and that no background schedule persists. It does not cover edge cases like what happens when no previous successful sample exists, but with annotations present this is adequate.

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 sentences, each earning its place: the first covers run/snapshot/compare behavior, the second covers repetition and scheduling. It is compact, front-loaded, and contains 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 one-parameter tool, the description covers purpose, side effects, and scheduling clearly. However, there is no output schema, and the description does not explain what the caller receives back, whether the operation is synchronous, or what happens when there is no previous successful sample. Those are meaningful gaps for an agent that needs to invoke this tool and use its result.

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 only parameter, 'name', has 0% schema description coverage, and the description never explicitly maps 'name' to the saved search identifier. However, 'Run a saved search' strongly implies that the required parameter is the name of the saved search to execute, so the core semantics are inferable. More explicit parameter-level guidance would have been better given the low schema coverage.

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 action ('Run') on a concrete resource ('saved search') and adds exact side effects: saving a snapshot and comparing it with a previous successful sample. It also explicitly excludes background scheduling, which helps distinguish it from recurring automation tools. This clearly differentiates it from siblings like x_saved_search_save and x_snapshot_compare.

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 clear context for usage: run once, then repeat calls to automate research, and no background schedule is created. This is an explicit when-to-use and when-not-to-use signal. It does not name alternative sibling tools or direct the agent to a different tool for scheduled runs, so it falls just short of a 5.

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

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

Annotations indicate this is not read-only, not idempotent, and not destructive. The description adds that replacing resets the comparison baseline, which is useful behavioral context beyond annotations. It does not mention side effects like overwriting existing definitions or any dependencies, but the baseline reset is a key disclosure.

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

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

The description is two sentences with no filler, front-loading the primary action ('Save or replace') and immediately stating the key side effect (baseline reset) and a limitation (does not schedule runs). Every sentence adds value.

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 5 parameters and no output schema, the description is somewhat complete but lacks details on parameter semantics and return behavior. Since it's a mutation-like tool, knowing the response format would be helpful, but the annotations already indicate it's not read-only, so the description is minimally 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 0%, so the description is the only source for parameter meaning. The description names 'search definition' which implies 'query' and 'name' are the core parameters, but it provides no details on 'tab', 'limit', or 'maxScrolls' beyond schema defaults and constraints. The description partially compensates but not fully.

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 clearly states the verb 'Save or replace' and the resource 'local reusable search definition', distinguishing it from siblings like x_saved_search_run which executes searches. It is concise and specific, though it doesn't fully differentiate from x_saved_search_list which is about listing saved searches.

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

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

The description implies usage in the context of managing saved searches, and the note 'This does not schedule runs' clarifies what the tool does not do. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, but the sibling list gives context.

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

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

Annotations already establish read-only/idempotent safety, and the description adds genuinely new behavioral detail: refusal on login/checkpoint pages and the instruction to treat image content as untrusted data. This goes well beyond what the schema or annotations reveal.

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 concise sentences with the core action front-loaded. Every sentence adds value: what the tool does, its refusal behavior, and the security caveat. 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-parameter, annotation-rich tool this is nearly complete: target, purpose, refusal behavior, and security posture are all stated. It could specify image format or dimensions, but these are not essential for a diagnosis-oriented screenshot 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?

There are zero parameters and schema description coverage is 100%, so the baseline is 4. The description adds no parameter semantics, but none are needed for this tool.

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

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

States a specific verb ('Return'), an exact resource ('viewport screenshot of the signed-in X tab'), and a purpose ('for diagnosis'). The scope clearly distinguishes it from the snapshot, export, and search sibling 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?

Provides clear context: use when a viewport screenshot of the signed-in X tab is needed for diagnosis. It adds an exclusion ('refuses login/checkpoint pages') but does not name alternative tools or explicitly state when not to use it.

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

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

Annotations already establish read-only, idempotent, open-world behavior, and the description adds meaningful non-obvious traits: the result is bounded, a local snapshot is saved, and tab selection changes the record type returned. This goes beyond the structured metadata without contradicting it.

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

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

Three compact sentences each carry distinct information: purpose, output/side-effect behavior, and tab-specific semantics. No filler or repetition; key facts are front-loaded.

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

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

For a tool with four parameters and no output schema, the description gives a good overview but leaves gaps: limit and maxScrolls semantics, what 'bounded sample' means in practice, and how the snapshot relates to snapshot sibling tools. It is adequate for basic selection but not fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the tab parameter's effect on return type and hints at query syntax, but limit and maxScrolls are only indirectly covered by 'bounded sample' and receive no concrete semantic explanation.

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

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

The description uses a specific verb-resource pair ('Search X through the browser') and adds concrete behavioral details: native operators, bounded sample, local snapshot, and tab-dependent result types. This clearly distinguishes the tool's purpose from snapshot-read and thread/profile sibling 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?

The description implies usage for live X searches and explains how tab choices change results, but it does not explicitly state when to prefer x_search over siblings like x_saved_search_run or x_trends, nor does it mention exclusions. Usage context is present but not contrastive.

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

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

Annotations are all false and provide no behavioral signal, so the description carries the burden. It discloses meaningful behavior: closing the browser/tab, discarding prepared actions, and persisting login in the local profile. It does not contradict annotations, though it could add reversibility or failure-condition details.

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

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

Two focused sentences with the primary action first and the persistence caveat second. No filler, repetition, or unnecessary detail.

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 no-parameter close operation, the description adequately covers what happens and the key persistent-login caveat. It does not mention return values or behavior when no session exists, but those are minor for such a simple 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?

The tool has zero parameters and the schema is empty. With no parameters to explain, the description cannot add parameter-level value, so the baseline of 4 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 action ('Close the MCP-owned browser/tab') and a clear side effect ('discard prepared actions'). This distinguishes it from sibling tools like x_session_status, x_session_open, and x_action_cancel.

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 guidance on when to use this tool vs alternatives. It does not mention 'use instead of x_action_cancel' for discarding prepared actions, nor does it state prerequisites like requiring an active session. Usage context is only implied by the name and description.

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

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

Annotations already indicate this is a write-like operation (readOnlyHint=false) and not idempotent. The description adds value by specifying that it opens a browser profile or tab and that user sign-in is manual, which is critical for an agent to set expectations. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences and reasonably compact. It states the core action and a key nuance about CDP, but the second sentence about manual sign-in is somewhat tangential and could be condensed. Overall, it is well-structured and front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is mostly complete. It covers what the tool does and the manual sign-in aspect. However, it lacks details on what the agent should do after calling it (e.g., wait for user input) or how the session is identified. Given the complexity is low, a score of 3 reflects the minor gap in usage flow.

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 has zero parameters, so the schema provides no parameter semantics. The description mentions the browser profile and CDP browser, but it does not add detail on how to specify those. Since there are no parameters, the baseline is 4, but the description's vagueness about configuration reduces it to 3.

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

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

The description states a specific verb ('Open') and resource ('a dedicated browser profile'), which distinguishes it from sibling session tools like x_session_status and x_session_close. However, it is somewhat ambiguous because it also mentions opening a new tab in a CDP browser, which could be a different operation, and it doesn't clarify the primary purpose compared to other session-related 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?

The description gives a brief context for when to use the tool (to open a session before user manual sign-in), but it does not explicitly state when to use it over alternatives like x_session_status or x_session_close. The mention of 'explicitly configured CDP browser' hints at a condition, but there is no clear differentiation from siblings.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds a meaningful behavioral detail — 'Does not open a browser' — which goes beyond the annotation hints and helps the agent understand 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 no wasted words. The core action and resource are front-loaded, and the clarifying behavioral note is concise.

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 low-complexity, no-parameter read tool with annotations already covering its safety profile. The description tells the agent what statuses are readable and the key behavioral boundary, leaving no essential gap for correct invocation.

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

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

The tool has zero parameters, so there is no parameter ambiguity for the description to resolve. With no parameters, the baseline is high and nothing is missing.

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 ('Read') and a clear resource: login/checkpoint/rate-limit status and the visible signed-in account. It also distinguishes itself from browser-opening actions by explicitly noting it does not open a browser.

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 clearly implies this is the tool for inspecting session state rather than changing it, and the sibling list includes x_session_open and x_session_close, making the contrast inferable. However, it does not explicitly name alternatives or state when not to use it.

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?

The description contradicts the annotations: annotations set openWorldHint=false, while the description states that not-observed records are not proof of deletion or unfollowing, which is an open-world claim about absence. This is a serious inconsistency that could mislead an agent about how to interpret results.

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 two sentences with no unnecessary filler. The core purpose is front-loaded, and the interpretational caveat is brief yet valuable.

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 description of what the comparison returns, so an agent cannot know the result shape. The tool is simple, but the absence of return semantics, usage guidance, and the open-world contradiction leave 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 0%, so the description must compensate, but it only says 'two snapshots' without mapping to the 'before' and 'after' parameters or explaining their ordering. The parameter names imply meaning, but the description adds little beyond the schema.

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

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

The description clearly states the tool compares two snapshots of the same source, which names a specific verb and resource. It does not explicitly contrast itself with sibling tools like x_snapshot_read or x_snapshot_list, but the 'compare' action makes its distinct purpose fairly apparent.

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 is given about when to use this tool instead of related snapshot tools, nor are prerequisites like snapshot ordering or validity discussed. The only usage constraint is that both snapshots must be of the same source.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the valuable behavioral fact that the tool never contacts X — meaning no network latency, no auth or rate-limit failure modes, and purely local data — which is not captured in the annotations.

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

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

A single 8-word sentence with the verb and resource front-loaded; every word contributes meaning. No filler and no repetition of schema or annotation content.

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

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

For a one-optional-parameter list tool with a robust annotation profile, the description is nearly complete. The main gap is that it doesn't note the limit default behavior, though the schema covers that; return format is unaddressed but no output schema exists to anchor 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 0%, so the description carries the burden, but it never explicitly names the limit parameter. 'Recent' only hints at the ordering/recency that limit interacts with; the parameter's meaning is mostly conveyed by the schema's own default/min/max 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 and resource — 'list recent locally saved snapshots' — and adds the distinctive scope 'without contacting X.' This clearly separates it from siblings x_snapshot_read and x_snapshot_compare, both of which operate on specific snapshots rather than listing 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?

The phrase 'without contacting X' implies the tool is for offline/local listing when no network call is desired, but no alternative tools are named and no explicit when-not-to-use guidance is given. An agent must infer when to choose this over x_snapshot_read or x_snapshot_compare 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context by stating that this reads a local snapshot and that the result includes records and coverage warnings, which goes beyond the structured annotations without contradicting them.

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

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

A single sentence front-loads the action and resource, then adds the most important return detail. Every word contributes meaning, with no redundancy or fluff.

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 read operation with strong annotations, the description is sufficient to select and invoke the tool correctly and to know what the result contains. It could be more complete by explicitly noting that x_snapshot_list can be used to discover snapshot UUIDs, but that is not essential to 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?

There is only one parameter, id, and the schema merely specifies UUID format. The description clarifies that the id is the UUID of the local snapshot being read, which provides the necessary conceptual mapping and compensates for the 0% schema description coverage.

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 action (read), a resource (local snapshot), and a selector (UUID). Also indicates the contents returned (records and coverage warnings), which distinguishes it from siblings like x_snapshot_list and x_snapshot_compare at a glance.

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

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

The description implies use when you have a specific snapshot UUID and need its contents, but it never explicitly says when not to use this tool or points to alternatives like x_snapshot_list or x_snapshot_compare. An agent must infer the routing from the sibling list rather than from the description.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, lowering the bar. The description adds valuable specifics: the page may include recommendations/promoted content and may return posts not belonging to the thread. This meaningfully clarifies the open-world behavior beyond the annotations.

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

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

Two sentences with the core action front-loaded and the important caveat immediately after. No filler, no repetition of schema details, and every sentence earns its place.

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

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

For a read tool with strong annotations, the core behavior and open-world caveat are covered. However, there is no output schema and no description of how limit and maxScrolls shape the returned conversation, which leaves an agent with limited guidance for non-default calls. It is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description needed to explain the parameters, but it does not mention url, limit, or maxScrolls semantics. The schema provides names, defaults, and bounds, but the description adds no meaning to help an agent choose values or understand how scrolling affects results.

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 ('read') and resource ('post and visible conversation page'), and the caveat about recommendations/promoted content and non-thread posts distinguishes it from a strict thread-retrieval tool. This is clear and useful given sibling tools like x_timeline and x_user_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 explicit statement of when to choose this tool over alternatives, no exclusions, and no mention of related tools like x_user_posts or x_timeline. The caveat about recommendations is useful but does not tell an agent when to use this tool versus another.

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

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

Annotations already cover safety (read-only, idempotent, non-destructive), and the description adds a useful behavioral detail: it validates the English tab label and fails rather than silently reading the wrong tab. This fail-fast behavior and UI dependency go beyond the structured metadata.

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 no filler; the core purpose is front-loaded and the safety/validation caveat is placed second. Every sentence earns its place.

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

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

For a read-only tool with no output schema, the description gives the essential target and a useful failure behavior, but it omits what the returned timeline data looks like and what limit/maxScrolls actually control. An agent can start using it but may mis-estimate pagination or result size.

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

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

Schema description coverage is 0%, so the description should define parameter meaning. It only partially maps to the tab parameter by naming 'Following or For you'; limit and maxScrolls are never explained, leaving their behavior to inference from names and schema defaults.

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 ('Read') and a specific resource ('Following or For you home timeline'), which clearly distinguishes it from sibling tools like x_user_posts or x_notifications. The tab selection is named explicitly, so an agent knows exactly which view this tool targets.

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

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

The description implies the tool is for reading the user's home timeline and contrasts the two tab options, but it does not explicitly state when to choose this over sibling read tools like x_search or x_user_posts. There is no when-not-to-use guidance beyond the English-label caveat.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds behavioral context beyond annotations by stating the data is tied to the signed-in account and that location/personalization are controlled externally, which is not visible in annotations.

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

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

The description is a single, tightly scoped sentence. It front-loads the core action and resource, and every phrase ('signed-in account', 'Trends surface', 'controlled by X') earns its place by conveying or constraining meaning.

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 low-complexity, read-only tool with rich annotations, the description is nearly complete. It explains the scope and a key limiting trait (external controls). Minor gaps include parameter behavior (limit, maxScrolls) and return format, but these are not critical given defaults and the simple nature of the tool.

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

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

Schema description coverage is 0%, so the description should compensate for parameter meaning. It does not mention 'limit' or 'maxScrolls', though the parameter names and schema constraints (defaults, min/max) provide some inferable meaning. The description adds no value here.

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 ('Read'), a clear resource ('trend cards'), and a specific surface ('Trends surface'). It also notes the account-scoped, platform-controlled nature of the data, which differentiates it from siblings like x_search or x_timeline without needing to open those schemas.

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

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

The description implies a narrow use case: reading the signed-in account's Trends surface. It does not explicitly name alternatives or state when not to use this tool, but the mention of 'controlled by X' implies that user-controlled personalization is not available, suggesting a distinction from search-like tools.

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?

The annotations already cover the read-only, idempotent, non-destructive profile. The description adds that results are a 'bounded sample', which is useful context, but it does not explain pagination/scroll behavior, staleness, or whether some tabs may return empty for certain profiles.

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 definition is a single front-loaded sentence with no filler, earning high marks for conciseness. The phrasing is slightly awkward and the sentence is terse enough that it misses opportunities to add usage/parameter context.

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 four parameters, no output schema, and zero parameter descriptions, the description leaves important invocation details ambiguous—especially maxScrolls behavior and the return shape. The annotations mitigate safety concerns but do not make the tool fully self-explanatory.

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

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

Schema description coverage is 0%, so the description needed to explain the parameters. It only maps tab to the three surfaces and hints at boundedness; it does not clarify the meaning of limit vs maxScrolls, handle format, or how the sampled boundary is determined.

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

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

The description uses a specific verb ('Read') and identifies the resource as a profile's Posts, Replies, or Media surface, so an agent can tell it is a content-reading tool rather than a profile-metadata tool. It is slightly awkward grammatically and does not explicitly name sibling tools, 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?

The intended use is implied: call it when you want a bounded sample of a profile's posts, replies, or media. There is no explicit guidance on when to prefer x_profile, x_timeline, or x_search instead, and no exclusions are stated.

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