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

No annotations are provided, so the description bears full responsibility. It implies a read-only enumeration but does not explicitly state non-destructiveness or potential side effects. The behavior is inferred from the listing nature.

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 well-structured sentences: first states purpose and output, second provides usage hints. No redundancy, front-loaded with key 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?

The description covers the tool's core function and parameter usage but omits the udid parameter entirely. No output schema exists, so the description partially compensates by listing returned fields (identifier, name, pid), but could be more comprehensive.

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?

All parameters have schema descriptions (100% coverage), so the description adds marginal value. It reinforces userFacing's default filtering and runningOnly's purpose but does not clarify the udid parameter or add new detail about query behavior.

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 'Enumerate' and the resource 'apps' with output fields (identifier, name, pid). It differentiates from sibling 'process_list' by focusing on apps and mentioning default filtering. However, it does not explicitly compare to similar 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 description provides explicit guidance on parameter usage: default userFacing=true filters noisy services, runningOnly for live apps, query for substring matching. It does not, however, advise when to use app_list over other tools like process_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?

No annotations are provided, so the description must carry the behavioral burden. It correctly indicates a mutation action (clear), but does not disclose edge cases like what happens if no first responder exists or if it's not a text field.

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 extremely concise with a single sentence that states exactly what the tool does. No unnecessary 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?

Given the tool's simplicity (no parameters, no output schema), the description covers the essential action. It could mention what happens when no first responder is available, but overall it's 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?

Tool has no parameters, so the baseline is 4. The description adds no param info, which is fine since schema coverage is 100% and there are no params to describe.

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 clears the current first responder text field, using specific verb+resource ('Clear current firstResponder text field'). It distinguishes from siblings like 'type_text' and 'set_text_at_point'.

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

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

No explicit when-to-use or when-not-to-use is provided. The purpose implies usage for clearing text fields, but no alternatives or exclusions are mentioned. For a simple tool, this is adequate but 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?

No annotations provided, so description carries full burden. It discloses default behavior and a prerequisite, but lacks details on error cases or return format.

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

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

Two efficient sentences, front-loaded with purpose, no 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?

For a simple list tool with few parameters, the description covers purpose, default, and prerequisite. Missing error handling details, but adequate for low 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 coverage is 100% and already describes the only parameter. Description adds the prerequisite about frida-server but not significant additional parameter context beyond 'default USB-only'.

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

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

Clearly states the tool lists Frida devices and defaults to USB-only. No sibling tool does the same thing, so it distinguishes itself well.

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?

States prerequisite (frida-server) and default mode, which guides when to use. Does not explicitly state when not to use, but context is clear.

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

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

No annotations exist, so the description must fully convey behavioral traits. It mentions default values for gapMs (140) and resnapshot (true), but does not disclose side effects, error handling, or behavior when coordinates are invalid. The phrase 'double-tap (like)' hints at a like action but lacks detailed behavioral context.

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

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

The description is concise, with three short sentences. The main action is front-loaded. While it could be more structured (e.g., listing parameters), it avoids unnecessary verbosity.

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 5 parameters (none required), no output schema, and moderate complexity, the description is incomplete. It does not specify return values, success criteria, or how x,y and ref interact. The defaults are mentioned, but overall context for a reliable call is lacking.

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 40% (only gapMs and resnapshot have descriptions). The description adds meaning by clarifying that 'ref' is an alternative to x,y for location, and restates defaults for gapMs and resnapshot. However, it does not explain the relationship between x,y and ref (e.g., mutually exclusive) or provide 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?

The description clearly states the tool performs a 'double-tap (like)' action at a location specified by either ref or x,y coordinates. The verb 'double-tap' and resource implication are specific, but it does not differentiate from sibling tools like 'tap' or 'swipe'.

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 provided on when to use this tool versus alternatives such as 'tap' (single tap) or 'swipe'. The description implies a 'like' action but does not clarify context or 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?

Discloses the parallel execution and the purpose of testing concurrent locks. However, no annotations are provided, and the description does not cover potential side effects, error conditions, or requirements (e.g., device 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?

Single, front-loaded sentence with no wasted words. Efficiently conveys the purpose and advanced nature.

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 zero parameters and no output schema, the description covers the essential behavior. The '[advanced]' marker implies caution, but no additional context is needed for such a simple 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?

No parameters exist, and schema description coverage is 100%. The description adds context about what the tool does beyond the schema, which is sufficient.

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 clearly states it performs parallel health pings (app + SpringBoard). The phrase 'proves dual inject + concurrent locks' adds specificity, though it is slightly technical. Distinguishes from sibling 'ping' which likely does a single ping.

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?

Only an '[advanced]' tag hints at non-standard usage. No explicit when-to-use or when-not-to-use guidance, and no reference to alternatives like the single 'ping' 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?

The description discloses almost no behavioral traits. It only mentions being blocked on TikTok and being a daily probe, which warns against use but does not describe any side effects, output, or operational 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?

The description is extremely short, but its brevity sacrifices clarity and usefulness. The phrase 'do not use' conflicts with the concept of a usable tool definition.

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 annotations and output schema, the description fails to provide sufficient context for the tool's operation. A debug tool should explain what it dumps and under what conditions.

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 zero parameters, the input schema is fully covered by default. The description adds no parameter information, but according to the rubric, 0 parameters warrant a baseline of 4.

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 vaguely indicates a debug function ('dumpModalView') but is unclear on what exactly it accomplishes. It labels the tool as blocked and not for use, obscuring its actual purpose.

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 provided on when to use this tool; instead, the description explicitly states 'do not use', which is negative guidance without alternatives or 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?

No annotations are provided, so the description carries full burden. It accurately describes a read-only inspection tool with no side effects. The information about returned fields (className, frame, canInsertText) is transparent and sufficient.

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 sentence with no wasted words. It conveys purpose, behavioral traits, and usage guidance 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?

Given no input schema, no annotations, and no output schema, the description covers the essential aspects: what the tool returns and its role in a workflow. It could mention potential error states, but for a simple info retrieval tool, it is sufficiently 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?

The tool has no parameters, so schema coverage is 100%. Baseline for 0 parameters is 4. The description adds value by explaining the purpose of the output, which is adequate.

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 retrieves first responder info (className, frame, canInsertText) and explicitly links it to a specific use case: checking focus before typing. This verb+resource specification distinguishes it from sibling action tools like type_text and set_text_at_point.

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 'Check focus before type_text' provides explicit when-to-use guidance. It does not mention when not to use or list alternatives, but the context is sufficiently clear given the sibling set.

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?

Without annotations, the description reveals basic behavior (random sleep, min/max parameters) but omits details like blocking nature, interruptibility, or side effects. It adds some value by stating it's not typing delay.

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 very concise with two sentences, front-loading the purpose and key usage hint. No unnecessary 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?

For a simple tool with two number parameters and no output schema, the description provides adequate context on usage. However, it could mention that it blocks or returns nothing, and lacks a distinction from the similar sibling 'wait'.

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 input schema covers both parameters with basic default descriptions, but the tool description adds no further meaning. The randomness is implicit from the tool purpose but not explicitly linked to parameters.

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

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

The description clearly identifies the tool as a random sleep between actions, explicitly distinguishes it from typing delay, and uses specific verbs and resource terms ('random step gap sleep').

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 advises using it between actions and clarifies it is not a typing delay, but does not discuss when not to use it or compare with sibling tools like 'wait'.

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 must disclose behavior. It mentions AFC upload but does not explain overwrite behavior, permission requirements, or the meaning of 'stage=upload 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?

The description is brief and mostly to the point, but the cryptic note 'stage=upload on failure' is unclear and could be rephrased or expanded.

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 lacks information about return values, error handling, and the overall workflow. Given the tool's complexity (AFC upload to iPhone), it is incomplete without output schema or further context.

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 only 33% schema description coverage, the description does not add meaning to the parameters. It does not explain mediaType or udid beyond the schema, despite the low 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 clearly states it uploads a PC file to a specific iPhone directory via AFC, distinguishing it from higher-level import tools like photos_import. However, the '[advanced]' tag is vague.

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 mentions prerequisites (Python + pymobiledevice3) and a cryptic failure note, but does not specify when to use this tool over alternatives or provide exclusion 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?

The description indicates a destructive action ('Clear') but does not disclose side effects, prerequisites, or any behavioral traits beyond the basic operation. With no annotations, the description carries the full burden, and it falls short.

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 extremely concise, but borderline under-specified. It communicates the core action but lacks context. The '[advanced]' tag is somewhat informative.

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 no parameters, no output schema, and no annotations, the description is minimally adequate. It tells what the tool does, but for a destructive action, more context (e.g., confirmation, reversibility) would be expected for completeness.

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 no parameters, so the schema coverage is trivially 100%. The description does not need to add parameter semantics. The baseline score for zero parameters is 4.

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 'Clear' and the resource 'captured network buffer'. It distinguishes from sibling tools like net_disable, net_enable, and net_dump, which have different purposes. However, it could be more specific about what 'captured network buffer' refers to.

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 provided on when to use this tool versus alternatives. The '[advanced]' prefix hints at a target audience but does not give explicit context or exclusions.

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

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

The description discloses the key behavioral trait that the buffer is retained until net_clear, which goes beyond a simple 'stop recording'. However, it does not mention side effects, reversibility, or permissions, which would be helpful.

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 extremely concise, using only two clauses with no wasted words. The key action and buffer retention behavior 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 simple toggle tool with no output schema and no annotations, the description covers the essential effect and buffer behavior. It is complete enough for agent 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 are zero parameters, so the schema is complete. Description adds no parameter info but none is needed. Baseline score for 0-parameter tools is 4.

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 stops recording new network entries, with specific verb 'Stop' and resource 'network entries'. It distinguishes from sibling tools like net_clear (which clears buffer) and net_enable (which resumes recording).

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 includes '[advanced]' hinting at target audience, but provides no explicit guidance on when to use this tool vs alternatives like net_clear or net_enable. Usage is implied through the action description but lacks direct exclusions or recommendations.

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 must fully disclose behavior. It mentions defaults like redact, dedupe, and dropping data URLs, but it is unclear about side effects, authorization needs, or whether it modifies state. It also omits details about the output format (e.g., rawCount, returned count) that an agent needs 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 relatively short but dense and somewhat cryptic. It front-loads the purpose but lacks clear structure. There is no wasted content, but it could be better organized for readability.

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 tool's complexity (7 parameters, no output schema, no annotations), the description does not fully equip an agent. It lacks a clear explanation of the output format (rawCount, returned entries) and does not detail how parameters interact. More context on return values and edge cases is needed.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some value by explaining default behaviors for parameters like redact, dedupe, includeDataUrls, and includeBinaryBodies. However, it does not systematically cover all parameters or add significant meaning beyond the schema descriptions.

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 it is a 'Quiet HTTP dump' and details what entries may include (stack, signHeaders, query, backtrace). The name 'net_dump' aligns well. It distinguishes itself from sibling network tools by being a dump tool, though it doesn't explicitly contrast 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?

The description provides specific example queries and tips (e.g., 'redact:false dedupe:false query:tiktokv') and mentions default behaviors. However, it does not explain when to use this tool versus alternatives nor explicitly state prerequisites or exclusions.

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 thoroughly discloses behavioral traits: capture modes' hooking behavior, signTrace backtrace attachment, response capture wrapping, NSURLSession skip condition, and opts reset on each call. No annotations were provided, so the description carries full responsibility and meets it well.

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 front-loaded with the core purpose. While lengthy, every part adds necessary detail for an advanced tool. It could be slightly more structured, but it remains effective.

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 complexity (5 parameters, no output schema, no annotations), the description is remarkably complete. It covers parameter behavior, mode differences, reset behavior, and even gives a usage flow. No output schema means return values are handled by sibling tools, which is fine.

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 100% coverage with descriptions, but the description adds significant extra meaning: it explains the ttnet mode's hooking timing, the NSURLSession wrap skipping, and the non-sticky nature of urlFilter. This goes beyond schema basics.

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's purpose: 'Start in-process HTTP capture.' It specifies modes (nsurl, ttnet, all) and distinguishes from sibling tools like net_dump and net_disable by focusing on enabling capture.

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 includes a typical usage example (session_open with options) and notes that each call resets opts, but it does not explicitly specify when to use this tool versus alternatives or provide context for 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?

No annotations are provided, so the description carries the full burden. It mentions it returns status fields but does not disclose whether it is read-only, has side effects, or requires specific permissions. The word 'status' implies a read operation, but the description lacks explicit behavioral clarity.

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 very short (one sentence) and front-loads '[advanced]' and the key fields. However, it lacks structure and could be formatted as a list or more readable. It is concise but at the expense of clarity.

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 no parameters and no output schema. The description lists the fields but does not explain what they represent or the expected return format. Given the lack of output schema, the description should provide more detail on the return value structure and possible values.

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 no parameters, so the input schema is empty with 100% coverage. The description adds no parameter information, which is acceptable since there are none. Baseline 4 is appropriate as the schema already handles this.

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 indicates the tool returns network capture status with specific fields (enabled, hooksInstalled, count, options). The verb is implied (get/retrieve), and it distinguishes from sibling tools like net_enable, net_disable by hinting at status retrieval. However, it could be more explicit about the action (e.g., 'Get network capture status').

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 includes '[advanced]' suggesting it's for advanced users but provides no guidance on when to use this tool vs. alternatives like net_enable or net_disable. No context on prerequisites or scenarios.

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 discloses that the tool trashes (deletes) media, verifies count=0, and may require retry. However, it does not detail permanence, authorization needs, or side effects (e.g., whether recently deleted items become permanently removable).

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 sentence with all key information front-loaded. No redundant words; every phrase adds value (advanced, trash, verify, optional cleanup, retry condition).

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 no output schema and destructive nature, the description covers the core behavior, verification step, and retry logic. It does not explain return values or error cases beyond retry, but it is sufficiently complete for an agent to understand the primary function.

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 50% (clearDcim described). The description adds meaning by clarifying clearDcim's default true and its role in removing DCIM sources. The udid parameter is not described, but its purpose (device identifier) is standard. Overall, description adds value beyond 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?

Description clearly states the tool trashes all untrashed image/video from Recently Deleted, verifies count=0, and optionally cleans DCIM source. This is a specific verb+resource combination that distinguishes it from sibling tools like photos_ensure or photos_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?

The description implies advanced usage and mentions 'needsRetry if leftover,' but does not explicitly state when to use versus alternatives or when not to use. It lacks exclusion criteria or alternative tool recommendations.

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 honestly discloses spawn, resume, settle time, injection, foreground stealing, and non-closure of sessions. Missing details like required permissions or error cases, but overall good 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?

The description is extremely concise (3 short sentences) with front-loaded action. Every sentence adds value, 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?

Covers main action and side effects but omits return behavior, error conditions, prerequisites (e.g., device state, app existence). Adequate but not fully informative.

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 50% (only settleMs described as 'Default 4000'). The description echoes the settle time but adds no meaning for 'udid'. It insufficiently compensates for the missing param 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 clearly states the tool's function: spawn/resume Photos.app, settle, inject agent. It also notes what it does not do (close TikTok) and a side effect (steal foreground), making the purpose distinct from 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 context (setup step, not closing sessions) but lacks explicit when-to-use, when-not-to-use, or direct comparison with alternatives like photos_import or photos_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?

Discloses that the tool imports a file and returns a localIdentifier, and mentions the terminateAfter parameter's effect (killing Photos). However, it omits behavior when paths are invalid, mediaType mismatches, or import fails. No annotations to rely on.

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 sentence that packs essential information: purpose, path constraints, host limitation, and return value. It is concise without being overly brief, though it could be slightly more structured.

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 5-parameter tool with no output schema and no annotations, the description covers the core mechanism but leaves gaps: no explanation of udid, no error behavior, and no differentiation from the sibling photos_import_file. The return value is mentioned but not the structure.

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 60% schema description coverage, the description adds minimal value beyond the schema. It reiterates path locations but does not clarify the udid parameter, the role of mediaType, or the distinction between devicePath and remotePath. The terminateAfter context is helpful but insufficient to compensate.

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?

Clearly states it imports already-on-device files from specific paths under /DCIM into Photos. The '[advanced]' and 'Host=Photos.app only' qualifiers add precision, but it does not explicitly distinguish from sibling 'photos_import_file' which might have a different scope.

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?

Specifies that file must be on device under /DCIM and that it targets Photos.app, but provides no guidance on when to use this tool versus alternatives like photos_import_file, nor any prerequisites or error handling scenarios.

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. It discloses the multi-step sequence, dependency issues (stage=afc in ≤5s), video constraints (avoid parallel sessions, expect needsRetry), and optional verify. Lacks explicit success/failure return format, but covers key behavioral traits.

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

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

Two dense sentences with front-loaded '[advanced]' and key info. The structure is somewhat run-on but packs relevant details. Could be split for readability, but 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?

Given 4 params, no output schema, and no annotations, the description covers dependencies, fallback, and constraints. However, it does not explain what the tool returns (e.g., localIdentifier or error), leaving a gap for an agent to infer behavior.

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

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

Schema coverage is 50% (udid lacks description). The description repeats 'Accepts image or small mp4' (matching mediaType enum) and mentions 'verify' default true, but adds little beyond schema. Does not explain udid or provide format details for localPath. Baseline 3 since schema covers half.

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 it performs a multi-step import (AFC upload, Photos ensure, PhotoKit import, optional verify) for images or small MP4s. It distinguishes itself from siblings like 'photos_import' by labeling itself as 'advanced' and 'preferred for AI', though the jargon may not be universally clear.

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 context on when to use ('preferred for AI'), dependency requirements, fallback behavior on missing deps, and a warning against parallel session_open for video. It does not explicitly contrast with sibling tools like 'photos_import' or 'photos_ensure', but the guidance is actionable.

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 discloses the mechanism (AFC file access), the data scope (untrashed, not Recently Deleted), and a failure mode (fast-fail if missing library). However, it does not explicitly state read-only behavior or any side effects, and lacks details on permissions or connectivity requirements.

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, no wasted words. Key information is front-loaded: 'Pull Photos.sqlite via AFC; list untrashed assets'. Optional filters and dependency are mentioned succinctly. Excellent conciseness.

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?

Despite having 4 parameters and no output schema, the description does not explain what the returned list contains, its format, or any pagination/limits. The output is crucial for a list tool, and its omission leaves a significant gap. While the sibling tools are diverse, the description fails to provide a complete picture for correct invocation.

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

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

Schema description coverage is 50% (2 of 4 parameters have descriptions). The description adds context for mediaType and idPrefix/localIdentifier, stating they are optional filters and specifying 'image|video' for mediaType (though already in schema enum). udid is left undocumented. The additional explanation partially compensates but does not fully cover all parameters.

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

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

The description clearly states it pulls Photos.sqlite via AFC and lists untrashed assets, with optional filters. It identifies the specific resource (Photos.sqlite) and action (list), and distinguishes from sibling tools like photos_ensure, photos_import, and photos_clear which perform different operations.

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 versus alternatives. It mentions prerequisites (FRIDA_MCP_PYTHON, pymobiledevice3) and a fast-fail condition, but does not clarify when listing is appropriate compared to other photo-related tools. Implied usage is vague.

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 description must disclose behavior fully. It states 'returns pong' but doesn't detail side effects, failure conditions, or the implications of using wrong RPC names. Minimal 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?

Two sentences, but the second sentence ('Do not use wrong RPC names as probes') is cryptic and may not earn its place. Concise but not optimally structured for clarity.

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 zero parameters and no output schema, the description is mostly adequate for a simple liveness check. However, it lacks details about expected response format (plain text?) and error cases. The warning hints at problematic usage but doesn't elaborate.

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?

No parameters exist, and schema coverage is 100%. Description adds no value here, but baseline is 4 as per rubric since it cannot be improved.

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?

Clear that it's a liveness probe returning pong; distinct from sibling tools like dual_ping or session_status. The warning about 'wrong RPC names' adds confusion but doesn't obscure purpose.

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?

Describes when to use as a liveness probe, but no guidance on when not to use or alternatives like dual_ping or probe_help. The warning is ambiguous and doesn't help select this tool over others.

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?

Given no annotations, the description discloses key behavioral traits: the app is suspended, not terminated, and the session may remain attached. This informs the agent about non-destructive nature and potential session persistence.

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, concise and front-loaded with the essential action and its effect. Every word earns its place 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?

For a parameterless tool, the description fully covers the purpose, effect, and important nuance about session attachment. No output schema is needed, and the context is 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?

The tool has no parameters and schema coverage is 100%. Per guidelines, baseline is 3 since the description adds no further parameter value, but no additional information is needed.

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 specific verbs 'background' and 'suspend', identifies the resource 'current app', and explains the result 'SpringBoard shows'. It clearly distinguishes from sibling tools like 'sb_close' or 'tap' by describing the home button action.

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 does not explicitly state when to use this tool versus alternatives. It implies usage for returning to the home screen but offers no guidance on when not to use it or which siblings to prefer.

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 describes the tool as providing recommendations, implying a read-only behavior. However, it does not disclose what the output looks like (e.g., text, list) or any other behavioral details.

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

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

Two sentences that are front-loaded with the main purpose and usage. No unnecessary words. Very 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?

Given no parameters and no output schema, the description is minimal but functional. It tells when and what, but lacks detail on return format or structure. Could be improved by mentioning the kind of output (e.g., 'returns tool recommendations').

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 (schema coverage 100%), so the baseline is 4. The description does not need to add parameter semantics.

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

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

The description clearly states it is a 'recommended probe loop' and provides guidance on tool preference/avoidance. It also notes to call first in a new session, giving a specific purpose. However, 'probe loop' is not explicitly defined.

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 says 'Call first in a new session,' which is clear when to use it. It does not mention when not to use it or provide alternatives, but given its unique role, this is acceptable.

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 discloses that query is a literal substring (not regex) and provides an example. This is useful behavioral context beyond the schema. It does not mention other traits like read-only nature, but that is implied by 'list'.

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 long, front-loaded with the purpose, and provides a critical constraint immediately. Every part is necessary and no words are 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?

The description lists output fields (pid, name) and explains query behavior. It lacks details on limit behavior or whether the list is complete, but the schema provides the default limit. For a simple listing tool with no output schema, it is fairly 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 coverage is 67% (limit and query have descriptions, udid does not). The description adds significant value for the query parameter by clarifying it is a literal substring and not regex, which reduces ambiguity. It does not add info for udid or limit, but the schema already covers limit's default.

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 it lists device processes with pid and name. The verb 'list' and resource 'device processes' are specific. No sibling tool performs a similar function, so it is well-differentiated.

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 notes 'advanced' and gives a query constraint but does not explicitly state when to use this tool over alternatives or when not to use it. There is no guidance on conditions that would make this tool inappropriate.

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, and the description only labels it as a 'whitelisted agent RPC' without disclosing side effects, permissions required, or what the RPC does. For a debug tool, details about its behavior (e.g., potential system modifications) are missing.

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 sentence, concise and front-loaded with the critical guidance to prefer other tools. It efficiently conveys the essential point without fluff, though a bit more structure could clarify usage.

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 tool's low specificity (no output schema, no annotations, generic parameters), the description fails to provide sufficient context. It does not explain what the RPC returns, how to use 'args', or what RPC names are valid beyond the example 'windowFrame'.

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 only 50% (name has description, args does not). The description does not add any meaning beyond the schema; it does not explain what 'args' is for or how to format it. The empty items schema for 'args' is unhelpful.

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 it is a 'whitelisted agent RPC' and advises to prefer first-class tools and probe_help, which clearly indicates it is a debug/fallback tool. This distinguishes it from sibling tools by positioning it as a last resort.

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 advises to prefer other tools ('first-class tools + probe_help'), giving a clear when-to-use guidance. However, it does not specify when exactly to use this tool or what conditions warrant its invocation, leaving some ambiguity.

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 fully discloses behavior: default policy, settle time, loop mechanics, return values (cleared/remaining/rounds/needsRetry), retry logic, and a warning against parallel tap+dismiss. This is rich and transparent.

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 concise and front-loaded with the main action, but uses dense shorthand (e.g., '~300ms settle', 'trust cleared; empty → cleared:true rounds:0') that could be clearer. Could benefit from slight restructuring for readability.

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 high schema coverage and no output schema, the description covers parameters, behavior, return values, and caveats. Mostly complete, but the settle time behavior and 'trust cleared' concept could be elaborated for full clarity.

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%, but the description adds significant extra meaning beyond the schema: explains how 'all' controls single vs stacked mode, default values for policy and maxRounds, and settling mechanics. This adds substantial value for correct invocation.

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 'Dismiss SB alert' and distinguishes between single (all=false) and stacked (all=true) modes. It uses specific verbs and resources, and the purpose is distinct from sibling tools like sb_alert_list or sb_alert_trigger.

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 explicit context on when to use all=false vs all=true, and includes instructions on retry behavior and a prohibition against parallel actions. Does not compare to alternative tools, but siblings are different actions so this is acceptable.

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?

Despite no annotations, the description explains important behaviors: live count may undercount, raw may be higher, and hasAlert logic based on either count path. It also warns about unreliable state after force operations, which aids safe usage.

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

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

The description is three sentences and includes both primary purpose and critical behavioral warnings. It is reasonably concise with no wasted words, though slightly dense.

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 explains output fields (actionViewCount, actionViewCountRaw, hasAlert) and some behavior, but does not fully describe the return format or what constitutes a SpringBoard alert. Given no output schema, more detail could be helpful.

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 no parameters (0 params, schema coverage 100% but empty schema). The description could not add parameter semantics beyond what the schema already conveys, thus baseline 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?

The description clearly states it lists SpringBoard alerts, uses specific verbs ('list'), and distinguishes from sibling tools like sb_alert_trigger, sb_alert_tap, and sb_alert_dismiss by focusing on listing rather than triggering or dismissing.

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 specific guidance after force operations ('do not trust actionViewCount===1 — use sb_alert_dismiss({all:true})') and after dismiss ('take app screen_snapshot'), but lacks broad guidance on when to use this tool versus alternatives or general use cases.

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 discloses that it's an advanced action and gives after-use instructions. However, it does not detail side effects, error behavior (e.g., if button not found), or whether it requires specific app state. This is adequate but could be more transparent.

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 extremely concise, consisting of three short sentences. Each sentence adds unique information: the action, a required follow-up, and a parallelism constraint. No unnecessary words 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?

Given the tool has one parameter and no output schema, the description covers the core action and provides important context (post-action and parallelism rule). It does not explain error handling or what happens if the title does not match, but for a simple tap action, this is largely 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?

Schema description coverage is 100% with the schema describing 'title' as 'Button title to match'. The description adds 'by title', which is redundant. No additional semantic meaning beyond the schema is provided, 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?

The description clearly states it taps a SpringBoard alert button by title. 'Tap SpringBoard alert button' is a specific verb-resource pair. It distinguishes from sibling tools like sb_alert_dismiss and sb_alert_trigger, which perform different actions on alerts.

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 guidance: call screen_snapshot after tapping, and do not parallel with dismiss. However, it does not explicitly state when to use this tool versus alternatives like sb_alert_dismiss or sb_alert_list. The context is implied but not fully differentiated.

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 description carries full burden. Describes default behavior (skip if alert present) and force parameter (stack another), which is good, but lacks details on permissions or 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?

Extremely concise: two sentences with front-loaded purpose, minimal wasted words. Efficiently communicates key info.

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 tool with one parameter and no output schema, the description covers purpose, parameter behavior, and next steps. Lacks failure scenarios but is 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 has 100% coverage for the single parameter, but description adds nuance (e.g., 'no stack' vs 'stacks another') beyond the schema's 'do not stack', improving agent understanding.

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?

Clearly states it creates a test system alert (SBAlertItemTestRecipe), distinguishing it from siblings like sb_alert_list (list), sb_alert_dismiss (dismiss), and sb_alert_tap (tap). The '[advanced]' label adds context.

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

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

Implies usage via sibling differentiation and explicit next steps (sb_alert_list → sb_alert_dismiss or sb_alert_tap), but lacks explicit when-not-to-use or alternative 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?

Despite no annotations, the description discloses the core behavior (detaching) and a key effect (app session stays open). It is transparent enough for a simple parameterless tool, though it could mention any prerequisites or 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?

The description is a single, clear sentence with no extraneous words. It is perfectly sized for the tool's simplicity.

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 no parameters, no output schema, and a simple action, the description fully covers what the tool does and the key distinction from sibling 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?

There are no parameters, so the description does not need to add parameter information. The schema coverage is 100%, earning a baseline of 4.

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 detaches a SpringBoard Frida session and specifies that the app session remains open. This distinguishes it from sibling tools like session_close, which presumably closes the app session.

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 when to use this tool (to detach SpringBoard while keeping the app session), but it does not explicitly state when not to use it or provide alternatives with specific 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, so description carries full burden. Discloses that it attaches SpringBoard and skips alert listing, but does not mention side effects, permissions, or safety. The 'advanced' tag hints at caution, but more detail would improve 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?

Two concise sentences with no redundant information. Every part adds value: '[advanced]' warns of complexity, 'Attach SpringBoard now without listing alerts' defines the operation, and the rest gives usage guidance.

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 no parameters, no output schema, and the tool's advanced nature, the description adequately covers purpose and usage. It could mention expected outcomes or whether it is blocking, but it is sufficient for a parameterless 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?

No parameters exist, and schema coverage is 100%, so the description does not need to add parameter details. Baseline 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?

The description clearly states the tool attaches SpringBoard without listing alerts, distinguishing it from sibling tools like sb_alert_list. It also specifies the purpose: to warm a dual session for parallel operations.

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?

Explicitly states when to use: to warm dual session so app tools and sb_* can run in parallel. It implies this is for advanced setup, but does not explicitly state when not to use or provide alternatives beyond 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?

With no annotations, the description carries the full burden. It discloses the tool is read-only ('Does not touch device') and explains query behavior. However, it does not describe return value, error cases, or behavior when no snapshot exists, limiting 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?

The description is very concise (two short sentences) and front-loaded with the core purpose. It efficiently conveys key information without fluff, though a bit more structure (e.g., bullet points) could improve readability.

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 tool with 2 parameters and no output schema, the description covers the purpose and primary parameter reasonably well. However, it lacks any mention of output format, error handling, or dependency on a prior snapshot, leaving gaps for the agent.

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 baseline is 3. The description adds minor value by explaining the default substring behavior and providing a regex example. However, it does not clarify ambiguous terms like 'auto' from the schema 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 clearly states the action ('Filter last snapshot') and the resource ('last snapshot'). It distinguishes from sibling tools like screen_snapshot and screen_shot by specifying that it searches within an existing snapshot and does not touch the device.

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 parameter usage hints (substring default, regex syntax) but does not specify when to use this tool over alternatives, prerequisites (e.g., need a snapshot first), or scenarios where it is not 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?

No annotations provided, so description carries burden. It mentions dependencies (pymobiledevice3, optional Pillow) and return type (image+meta), but does not disclose whether the tool is read-only or has side effects. Acceptable for a screenshot tool but could be more detailed.

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?

Concise single paragraph of ~40 words. Every sentence adds value: purpose, usage guidance, alternative, requirements, return type. No fluff, front-loaded with key 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?

Completes most needs: explains purpose, usage, dependencies, and return. Lacks detail on meta return and udid parameter, but overall sufficient for a simple tool with 2 parameters.

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 50% (only quality has description). The tool description adds no additional meaning to parameters; udid is unexplained and quality lacks context beyond schema. Does not compensate for missing schema descriptions.

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 it is a pixel screenshot via lockdown ScreenshotService, distinguishing itself from Accessibility and Frida UI dump. It also mentions preferring screen_snapshot for tap refs, differentiating from 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?

Explicitly states when to use (texts sparse/visual layout unclear) and when not to (prefer screen_snapshot for tap refs), providing clear context and an alternative 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 fully carries the burden of behavioral disclosure. It discloses the tool is read-only, specifies default behavior (onScreenOnly, limit), a platform restriction (TikTok blocks tree mode), search semantics, diff functionality, and a parallelism constraint. This is exhaustive for the given complexity.

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 extremely concise: four short sentences, each serving a distinct purpose (purpose, defaults, TikTok constraint, search behavior, diff, warning). It is front-loaded with the primary action and immediately provides differentiating 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?

Given 6 parameters and no output schema, the description covers defaults, platform constraints, search variants, diff, and a parallelism restriction. It lacks explicit mention of error handling or return format, but the combination of schema descriptions and tool description is sufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 100% already, so baseline is 3. The description adds value by clarifying default values (onScreenOnly=true, limit=40), the auto-enable of regex when search contains '|', and the purpose of showDiff. It does not repeat schema descriptions but augments them.

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 screen and returns generation-scoped refs, positioning it as the 'PRIMARY read tool.' This distinguishes it from sibling tools like screen_window, screen_search, and screen_shot, which are alternative read 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 provides explicit when-to-use and when-not-to-use guidance: it covers default parameter values, TikTok constraints (forced texts mode), search behavior (substring vs regex), comparison feature (showDiff), and a critical warning not to parallelize app acts. This leaves little ambiguity for the agent.

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. It discloses the output fields (width, height, x, y, cx, cy, className) and states it is 'safe on TikTok', implying no destructive side effects. This adds useful behavioral context beyond the empty 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?

The description is very concise: one sentence with key information. However, it could be slightly clearer with a verb, but it earns its place without 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?

Given the tool has no parameters and no output schema, the description is somewhat complete for a simple retrieval tool. However, it lacks an action verb and does not explain what the tool actually does (e.g., 'reads the current window size'). The safety hint is helpful but incomplete.

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, so baseline is 4. The description does not need to explain parameters but instead describes the output. It adds meaning by listing the fields that the tool returns, which is helpful.

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 implies the tool retrieves window size but lacks an explicit verb like 'get' or 'retrieve'. The fields listed hint at the output, but the purpose is not fully stated. It distinguishes from siblings like screen_snapshot or screen_search by focusing on dimensions, but not explicitly.

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

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

No when-to-use or when-not-to-use guidance is provided. The phrase 'Safe on TikTok' hints at a safety condition but does not clarify when to prefer this tool over alternatives like screen_snapshot or tap.

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 full burden. It explains default closing of SpringBoard and Photos side channel, and how parameters modify behavior. However, it does not disclose potential side effects like data loss or session state after closing.

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?

Description is a single, front-loaded sentence that efficiently conveys the core behavior and parameter effects without unnecessary 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?

While the description covers basic behavior and parameter effects, it omits prerequisites (e.g., session must be open), error conditions, return values, and whether the tool is destructive. Given no output schema, more context would be helpful.

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%—both parameters already have descriptions. The description reiterates defaults without adding new information beyond the schema, so it provides minimal added value.

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?

Clearly states 'Close app session' with specific verb and resource, and lists default behaviors. However, it does not distinguish from sibling session tools like session_respawn or session_force_unlock, which would help an agent choose correctly.

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

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

No explicit guidance on when to use this tool versus alternatives such as session_respawn or session_force_unlock. The description implies closing a session, but lacks context about appropriate scenarios or 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?

No annotations provided, so description carries full burden. It describes destructive actions (kill pids, detach sessions) but could be more specific about side effects. However, for an emergency tool, the level of detail 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 with no wasted words. Front-loaded with purpose, then usage, then guidance. Exceptionally concise and well-structured.

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 no parameters and no output schema, the description covers purpose, usage conditions, and a follow-up action. It is complete and sufficient for an agent to understand and invoke 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?

Tool has zero parameters, so schema coverage is 100% trivially. Description does not need to add parameter info. Baseline 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?

The description clearly states it is an emergency tool to 'reset stuck locks, detach sessions, kill in-flight/last app pid'. It specifies the resource (stuck locks/sessions/pids) and verb (force_unlock), differentiating it from sibling tools like session_open or session_close.

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?

Explicit usage conditions: 'Use when orphanFridaOpPossible or open hangs.' It also provides a follow-up action: 'Then ONE session_open.' This gives clear guidance on when to use and what to do next.

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 fully discloses behaviors: spawn lifecycle (kill→spawn suspended→inject→resume), mode override, net capture hooks, SpringBoard dual injection, process restart, and login UI reset. Also notes unreliability of attach mode.

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

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

Front-loaded with core purpose and every sentence adds value. Minor redundancy in repeating spawn mechanism, but overall efficient and well-structured for a complex 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?

Covers key aspects: spawn behavior, network capture, SpringBoard injection, timing for TikTok, and sibling differentiation. Lacks explanation of return value (e.g., session handle), but practical completeness is high given no output schema.

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?

Adds significant meaning beyond schema: explains mode is ignored unless env var, captureNet installs specific hooks, withSpringBoard attaches in parallel, and netOptions details. Schema coverage is 67%, but description compensates fully for gaps.

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 'Open long-lived Frida session (spawn-only on this stack)', specifying the action and resource. It distinguishes from sibling tools like session_respawn and session_close by detailing the spawn mechanism and constraints.

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 explicit guidance: always uses spawn mode, attach only with env var, TikTok-specific instructions (wait, avoid dump_tree/find_view), and explains spawn restarts process resetting login UI. Offers clear when-to-use and when-not-to-use.

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 fully bears the burden of disclosure. It states 'Kills the app process,' a critical destructive behavior, and describes the forceful nature of the operation. This is highly transparent.

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 concise sentences, front-loads the action, and contains zero filler. Every word 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 zero-parameter, no-output-schema tool, the description provides all necessary context: what it does, when to use it, and a key behavioral trait (kills app). No gaps remain.

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 no parameters, so the baseline is 4 per scoring rules. The description adds no parameter information because none exists.

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 action: 'Force spawn+inject+resume for current bundle' and immediately distinguishes it from siblings like session_open or session_close by specifying a forceful operation that kills the app process.

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 explicit usage guidance: 'Prefer only when session is dead.' This tells the agent exactly when to use this tool, though it does not explicitly list alternatives or 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?

No annotations are provided, so the description must disclose behavior. It lists returned fields but does not explicitly state that the tool is read-only and has no side effects. The word 'health' implies a query, but without confirmation, an agent might not be sure if it triggers any state changes.

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 concise line listing all relevant fields. It contains no unnecessary words and is easy to scan.

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 no output schema, the description is the only source for return format. It lists fields but lacks data types, structure description, or an example. For a health-check tool, it is somewhat complete but could be more helpful for agents to parse the response.

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 coverage is 100% (trivially). The description does not need to elaborate on parameters since none exist. No extra value is needed, but the description could clarify that no inputs are required.

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 it returns session health with specific fields like alive, refsValid, lastSnapshotGeneration. It distinguishes from sibling tools (e.g., session_open, session_close) which modify state, so purpose is clear: read-only status check.

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. While it's implied for checking health before actions, the description does not mention when it is appropriate, when not to use it, or how it differs from other status-like tools (e.g., probe_help).

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 only says 'Fill' without disclosing side effects, prerequisites (e.g., being on the OTP screen), or whether it clears existing text. Minimal behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the core action and target, making it easy to parse.

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 UI-filling tool with two parameters and no output schema, the description is adequate but lacks context about preconditions (e.g., requiring the OTP screen to be visible) and any return behavior.

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

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

Schema coverage is 100% and description adds value with an example ('Pass full code string e.g. 123456') and specifies the target UI elements, going beyond the schema's 'OTP digits' 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 clearly states the action ('Fill TikTok OTP'), specifies the target UI elements ('TMVerificationCodeInputView / TUXPinField'), and gives an example input. It differentiates from sibling tools that handle generic text input or other actions.

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 TikTok OTP fields but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives from the sibling list like 'type_text' for general text entry.

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 must convey behavioral traits. It only labels the tool as debug but does not explain side effects, permissions, or reliability. The agent learns little about what happens during invocation beyond setting text at a point.

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 very short and front-loaded with the debug label and alternative recommendations. However, it lacks structure and omits necessary parameter details, which slightly reduces efficiency.

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, 4 parameters (0% schema coverage), and a very brief description, the tool definition is incomplete. It fails to explain what the tool returns, how coordinates work, or what 'ref' is for.

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 adds no information about the parameters (x, y, ref, text). The agent cannot infer the meaning or expected format of these fields from the text alone.

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 'setText at point' and labels it as a debug tool, clearly indicating its purpose. It also distinguishes from sibling tools by explicitly recommending type_text / smart_type_text instead.

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 advises against using this tool for daily probes and provides clear alternatives: 'Prefer type_text / smart_type_text.' This helps the agent decide when not to use 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 reveals key behaviors: taps, waits for keyboard, types character by character (拟人逐字), handles TikTok AWESearchBar quirks, and defaults for retryOnFail and resnapshot. It does not disclose side effects or full error handling but covers the main behavior.

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

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

The description is poorly structured, starting with jargon ('PREFERRED typing: tap real input → wait typable FR → 拟人逐字') and mixing multiple ideas without clear organization. It is not front-loaded and could be more 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?

Given 8 parameters and no output schema, the description lacks information about return values, failure behavior, and full parameter details. It does not compensate for the missing output schema, leaving significant gaps for an agent.

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 63%. The description adds meaning for ref/x/y (specifying input location) and clarifies defaults for retryOnFail and resnapshot. However, parameters like perCharDelayMs and waitKeyboardMs are not explained beyond the schema, leaving gaps.

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 it is a typing tool for real input fields, distinguishing it from siblings by specifying it rejects chrome/chips and prefers wide search bars. The verb 'type' and resource 'real input' are explicit.

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 on when to use this tool (preferred typing, tap real input) and what to avoid (chrome/chips, hot-search chips). However, it does not explicitly state when not to use it or mention alternatives among 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?

With no annotations, the description carries full burden. It discloses key behaviors: duration conversion logic (seconds vs ms), clamping (0.15–2.5s), and resnapshot default. Does not mention destructiveness or side effects, but sufficient for a gesture 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?

Extremely concise; 5 sentences covering purpose, preference, mechanism, clamping, and a use case. No redundant information, front-loaded with clear purpose.

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 8 parameters and no output schema, the description covers the critical behavioral aspects (duration, resnapshot, use case). Could mention return value or effect on screen, but sufficient for a gesture tool.

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

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

Schema coverage is 38% (duration, durationMs, resnapshot have descriptions). The description adds clarity: 'Prefer durationMs (e.g. 280)' and explains the duration handling logic, which goes beyond schema. Other parameters like coordinates are not elaborated, but the main ones are covered.

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 'Swipe direction or path', which specifies the verb and resource. It distinguishes itself from sibling tools like tap and double_tap by implying a continuous gesture.

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 guidance on preferring durationMs, handling of duration in seconds vs ms, and a specific use case for resnapshot. However, it lacks explicit comparisons to alternatives like tap or when not to use swipe.

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 explicitly states the default side-effect of capturing a screen_snapshot and how to suppress it. This is a key behavioral trait that an agent needs to know. However, it doesn't mention other potential side effects or error conditions, so a 4 is given.

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 extremely concise, consisting of two clear sentences. The first states the core action and input methods, the second provides important usage guidance. No redundant information is present.

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 tap action, the description covers the essential aspects: input methods, resnapshot behavior, and results. It lacks information about handling conflicting inputs (e.g., both ref and x,y) or error cases, but the tool is straightforward and the context is well-covered.

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 50% (only ref and resnapshot have descriptions). The description adds meaning by explaining that tap uses either ref or x,y, and clarifies resnapshot's purpose. However, x and y parameters remain without additional explanation beyond the schema type. Baseline 3 is appropriate as the description partially compensates.

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 performs a tap using a reference (ref) or coordinates (x,y). It also explains the resnapshot behavior. While it distinguishes from sibling tools implicitly by name, it does not explicitly differentiate from similar gestures like double_tap or swipe, so a 4 is appropriate.

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 guidance on when to set resnapshot=false ('only when chaining many acts then one snapshot'), but does not offer broader usage recommendations or when to prefer this tool over alternatives like click or double_tap. The guidance is moderate but incomplete.

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?

Description discloses key behaviors: dryRun default, transport behavior for send_text, best-effort for messages, and how peer_conversation builds IDs. Since no annotations exist, it provides essential transparency. Lacks details on potential side effects or error states.

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?

Description is lengthy and dense with technical jargon like 'composer re-reads exact text'. Not front-loaded; key purposes are buried. Could be more structured with bullet points or clearer separation of actions.

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?

Despite 10 parameters and no output schema, the description omits details for some actions (e.g., what 'status' or 'phone_status' return). Partially explains inbox and messages returns but not comprehensively. Incomplete for a complex tool.

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

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

Schema coverage is 100% with descriptions. The description adds value by explaining dryRun default, transport defaults, and peerUid requirement (mutual follow). But much of the description restates schema info. Baseline 3 with marginal added value.

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 clearly enumerates actions (status, conversations, etc.) and states it's an IM network runtime. It distinguishes from sibling tools by focusing on IM functionality. However, the purpose is somewhat buried in technical phrasing.

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 context for some actions (e.g., inbox refreshes without UI navigation, send_text defaults to dryRun). No explicit when-not-to-use or alternatives mentioned, but the tool is the only IM tool among 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 are provided. The description indicates a 'refresh' action but does not clarify if it is read-only or has side effects (e.g., marking messages as read). It lacks details on authentication requirements, destructive potential, 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?

The description is a single sentence that efficiently conveys the tool's purpose, key benefit (no UI navigation), and return data. No unnecessary words 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?

Given no output schema, the description reasonably covers return fields. However, it lacks contextual details like prerequisites (e.g., user must be logged in), when to use this vs siblings, or behavior of parameters beyond what schema provides.

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 description does not add parameter-specific details beyond the schema's descriptions. It mentions return fields but not parameter usage, so it meets the baseline for a fully described 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 it refreshes TikTok inbox, message requests, and notification entries without UI navigation. It specifies the returned fields (username, content, conversationId, peerUid, isMessageRequest), distinguishing it from sibling tools like tiktok_reply or tiktok_im.

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 inbox contents without UI navigation, but it does not explicitly state when to use it over alternatives like tiktok_reply or tiktok_im. No exclusions or prerequisites are mentioned.

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

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

With no annotations, the description carries the full burden. It discloses that the tool retries tapping the magnifier 'a few points' and outlines the sequence of actions. However, it does not explain error handling, waiting behavior, or what happens after submission.

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 concise at two sentences, but includes vague terms like 'wide [input]' that reduce clarity. It front-loads the main action and is structured, but a slight improvement in wording would make it fully effective.

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 has a single optional parameter and no output schema. The description explains the UI steps, but does not cover preconditions (e.g., is the app already open?) or postconditions (e.g., is the search result page loaded?). It is adequate but incomplete for a UI navigation 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% for the single parameter (maxTries). The description adds 'retries a few points', which is consistent but less precise. It does not provide additional meaning beyond what the schema already offers, 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?

The description clearly states the tool's purpose: to open the TikTok search landing from the For You feed by tapping the magnifier, then typing and submitting a search. It uses specific verb+resource and distinguishes from a similar UI button ('Not the narrow 搜尋 submit button'), making it unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It only differentiates from a UI element (not a sibling tool) and lacks explicit when-to-use or 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 no annotations, the description should fully disclose behavior. It hints at authentication ('App MetaSec signs') but lacks details on pagination behavior, error states, rate limits, or what 'advanced' implies. The description is insufficient for an agent to understand side effects or requirements.

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 concise (27 words) and front-loaded with the action. However, jargon like 'in-process TTNet' and 'App MetaSec signs' may reduce clarity for some agents.

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 no output schema and no annotations, the description is incomplete. It mentions return fields but does not explain pagination parameters (cursor, count), how to handle errors, or prerequisites like being logged in. Essential context is missing for a list operation with pagination.

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?

All four parameters have schema descriptions (100% coverage), so baseline is 3. The description does not add significant semantic value beyond what the schema already provides.

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 action ('List current user's posts'), the method ('via in-process TTNet (App MetaSec signs)'), and return fields. It is specific about resource and scope, but does not explicitly differentiate from sibling tools like tiktok_inbox.

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 no guidance on when to use this tool versus alternatives, nor any instructions on prerequisites or 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?

Without annotations, the description discloses the tool's operational flow: opens chat, types, taps send, and verifies by re-reading text. It mentions the dryRun flag to control destructive behavior. However, it does not explicitly state that sending a real reply is irreversible, nor does it cover potential side effects or failure modes (e.g., what happens if the chat is not 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?

The description is two sentences: the first states the tool's purpose, the second details its behavior. It is compact, front-loaded, and every word adds value without 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?

Given the absence of annotations and an output schema, the description should cover return values, error handling, and prerequisites. It mentions success criteria (re-reading exact text) but omits what the tool returns on success or failure, required preconditions (e.g., being in conversation), and potential errors.

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 parameters are individually documented. The description adds contextual value for the dryRun parameter and explains the overall process, but it does not deepen understanding of other parameters like peerUid or confirmTimeoutMs beyond their schema descriptions.

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 is for replying through TikTok's real chat composer, specifying a verb ('Reply') and a resource. It implies uniqueness by mentioning 'real chat composer' but does not explicitly distinguish it from sibling tools like tiktok_im or tiktok_inbox.

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 no guidance on when to use this tool versus alternatives (e.g., tiktok_im, tiktok_inbox). It focuses on the internal mechanism (dryRun, chat composer) but lacks context about prerequisites or tool selection 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 provided, so the description must disclose behavioral traits. It explains that 'enable_trace' modifies net_enable settings, implying a side effect (mutation), while 'last' is read-only. However, it does not explicitly state whether 'last' is idempotent, whether 'enable_trace' is reversible, or any permission or rate-limit constraints. The description only hints at behavior without full 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 very short at around 50 words, but it packs in the essential information: purpose, actions, and a preference hint. However, the structure is somewhat run-on and uses jargon ('MetaSec', 'Argus', 'captureNet+signTrace') that might impede readability. A bulleted list would improve clarity without adding length.

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 tool has two very different actions and no output schema, the description should explain the return format for 'last' more precisely (e.g., the structure of sign headers entries) and specify the side effects of 'enable_trace' (e.g., whether it persists or is temporary). Currently, it only gives examples of header names and mentions net_enable parameters, leaving gaps in completeness.

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 input schema already covers both parameters with descriptions (limit default 20, action enum). The description adds semantic value by explaining the behavior of each action value ('last' returns recent sign headers, 'enable_trace' configures net_enable). This helps the agent understand the effect of each parameter choice beyond the schema.

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

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

The description states the tool provides 'MetaSec sign observability' with two specific actions: retrieving recent sign headers ('last') and enabling sign trace ('enable_trace'). It also notes it is 'NOT offline Argus recompute', which distinguishes from a similar but different operation. However, the term 'MetaSec sign' may be unclear without domain knowledge.

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 implicitly suggests preferring 'session_open' for captureNet+signTrace, indicating an alternative for combined functionality. It also warns against using it for 'offline Argus recompute'. However, it lacks explicit guidance on when to use this tool versus other siblings like net_enable or 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?

With no annotations, the description carries full burden. It discloses default delay with jitter and resnapshot default true, but does not mention side effects, error behavior, or whether the tool is read-only or mutating. Some transparency but not comprehensive.

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, efficient sentence that front-loads the core purpose and includes key defaults and conditional guidance. No 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?

Given no output schema and moderate complexity, the description covers purpose, usage, and key behavior. However, it lacks details on return values, error conditions, or completion semantics, leaving some 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 covers all three parameters, but description adds the concept of jitter for perCharDelayMs beyond schema, and clarifies defaults. This provides extra meaning beyond the schema descriptions.

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 types text into an already-focused field with human-like delay, and distinguishes it from smart_type_text for un-focused fields. The verb 'type' is implied and supported by the context.

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?

Explicitly states when to use this tool (field focused) and when to use an alternative (smart_type_text if field not focused), providing clear usage guidance.

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

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

No annotations provided, so description must disclose behavior. It says 'Sleep N milliseconds', which is straightforward, but doesn't detail blocking nature or 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?

Single sentence with a usage recommendation. No wasted words, front-loaded purpose.

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 delay tool, description sufficiently explains its function and provides context for alternative usage. No output schema needed.

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 parameter 'ms' described as 'milliseconds'. Description adds no extra meaning beyond 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?

Description clearly states 'Sleep N milliseconds', which is a specific verb and resource. It also distinguishes from sibling tool 'wait_until_texts' by giving a usage preference.

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?

Explicitly says 'Prefer wait_until_texts after TikTok session_open instead of blind wait', providing when-not-to-use and alternative.

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

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

No annotations provided, so description carries full burden. Discloses polling behavior, default timeout (15000), interval (800), and auto-regex for '|'. No side effects mentioned but not expected.

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, zero wasted words. First sentence defines purpose, second gives critical guidance. Highly 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?

For a tool with 6 parameters and no output schema, description covers polling behavior, defaults, and critical use-case (TikTok). Could mention when to use alternative tools like 'screen_search', but still complete enough.

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 has 100% coverage, but description adds context: default values (timeoutMs=15000, intervalMs=800), preset concept, and auto-regex for pattern. Enhances understanding beyond 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?

Description states it polls screen_snapshot until text matches pattern or preset, with specific TikTok guidance. Verb 'poll' and resource 'screen_snapshot' clearly define action. Distinguishes from siblings like 'wait'.

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?

Explicitly prefers preset for TikTok and warns against hardcoding language. Mentions custom pattern for page-specific probes. No exclusion of when not to use, but context is clear.

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