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

No annotations provided; the description only states the action without revealing side effects, such as whether sessions must be active, if resources are cleaned up, or if closing is reversible. Minimal behavioral disclosure.

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

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

The description is a single concise sentence with no wasted words. However, it could include additional useful information without bloat.

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 close operation with one parameter, the description is borderline adequate but lacks return value, error handling, and cross-reference to related tools like 'list_sessions' for obtaining sessionId.

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 zero description coverage for the parameter. The description only repeats the parameter name 'sessionId', adding no meaning about valid values, format, or how to obtain it.

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

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

The description uses a specific verb 'Close' with resource 'session' and clarifies it operates by sessionId. It clearly distinguishes from sibling tools like 'list_sessions' (listing) and 'disconnect_app' (disconnecting an app).

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

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

No guidance on when to use this tool versus alternatives like 'disconnect_app' or 'set_active_session'. No prerequisites or conditions for use 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?

No annotations provided, so description carries full burden. It mentions 'start log collection' but doesn't elaborate on mutability, error handling, or state changes. Provides 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?

Single sentence that is front-loaded with action and resource. Efficient, though a bit more detail could be added without losing 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?

No output schema, 3 undocumented parameters, no annotations. The description is insufficient for an AI agent to correctly invoke the tool; missing parameter details and behavioral 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?

Schema description coverage is 0%, and the description does not mention any of the three parameters (platform, deviceId, metroPort). Fails to add meaning 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?

Description clearly states the verb (connect), resource (running React Native app session), and additional action (start log collection). It distinguishes from siblings like 'disconnect_app' and 'get_connection_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?

No guidance on when to use this tool vs alternatives, no prerequisites or exclusions mentioned. With many sibling tools, this lack of context is a significant gap.

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

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

With no annotations, the description carries full burden but only states the action. It does not disclose effects (e.g., whether it ends the session), requirements for the sessionId parameter, or if it is destructive.

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 is too sparse for a tool with an optional parameter. It does not earn its place by providing sufficient 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?

Given no output schema, no annotations, and an undocumented parameter, the description is incomplete. The agent lacks critical context 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?

The description does not mention the 'sessionId' parameter at all. With 0% schema coverage, the agent gets no help understanding what value to provide or how it relates to the active session.

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 disconnects the active React Native app session. However, it does not differentiate from sibling tool 'close_session', which may have similar functionality.

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 like 'close_session'. No context about prerequisites or 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?

With no annotations, the description must carry the full burden of disclosing behavior. It only states what the tool does, without revealing side effects (e.g., read-only assumption), required permissions, or what happens if no session exists.

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, well-structured sentence with nine words. It is front-loaded with the action and clearly states the resource, containing no extraneous information.

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

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

For a simple status retrieval tool with one optional parameter, the description is minimally adequate. However, since there is no output schema, the description should specify what properties the response contains (e.g., connection state, log buffer contents) to guide 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?

The single optional parameter 'sessionId' has no description in the schema (0% coverage) and the tool description does not explain its purpose or when it should be provided. 'Current' implies a default, but ambiguity remains.

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 explicitly states 'Get current RN Inspector MCP session status and log buffer state,' which is a specific verb-resource pair. This clearly distinguishes it from sibling tools like close_session, connect_app, or get_logs, which have different purposes.

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 description does not mention prerequisites, context (e.g., after connecting a session), 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 must disclose all behavioral traits. It mentions visibility filtering ('visible elements'), matching strategy ('exact first, then contains'), and a fallback. However, it does not describe the return format, handling of multiple matches, side effects (e.g., read-only), or performance implications. This is adequate but lacks depth.

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 only two sentences, with the purpose front-loaded. Every sentence is functional: the first defines the action, the second provides usage strategy. No redundant or extraneous 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?

Given the tool's complexity (9 parameters, no output schema, 21 siblings), the description is insufficient. It omits parameter explanations, return value structure, and edge cases. The fallback guidance is helpful but does not compensate for the missing information needed to use the tool effectively.

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 has 9 parameters with 0% coverage in the description. The only hint is 'exact first, then contains' relating to testIdMatch. Parameters like maxDepth, clickableOnly, skipVisibilityCheck remain unexplained. The description adds almost no meaning beyond the schema, which is critical 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 the tool's purpose: 'Find visible elements matching a React Native testID.' It specifies the matching strategy ('exact first, then contains') and distinguishes itself from sibling tools like get_screen_test_ids and get_visible_elements by focusing on a single test ID with a fallback plan.

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: 'Use exact first, then contains. If none, call get_screen_context + get_test_id_remediation_plan.' This tells the agent the matching hierarchy and what to do when no match is found. However, it does not explicitly state when not to use this tool versus alternatives, earning a 4 rather than a 5.

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

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

No annotations are present, so the description bears the full burden. It discloses cursor-based pagination and that it reads 'error and fatal logs', but does not clarify if the buffer is cleared upon read, whether results are filtered to only errors/fatal by default, or if the tool is read-only. Basic transparency, but significant gaps remain.

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

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

The description is a single sentence that immediately communicates the core purpose. It is concise, but the lack of additional detail (e.g., parameter explanations) suggests it is under-specified rather than optimally 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 the complexity of 6 parameters, no output schema, and no annotations, the description is critically incomplete. It fails to explain pagination mechanics, parameter usage, return format, or error behavior, making it nearly useless 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?

The input schema has 6 parameters with 0% schema description coverage, and the description does not explain any parameter. 'Cursor-based pagination' hints at 'sinceCursor' but provides no details on its format or usage. Without any parameter guidance, the agent cannot correctly invoke the tool.

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

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

The description clearly states that the tool reads buffered error and fatal logs using cursor-based pagination. It uses a specific verb ('Read') and resource ('error and fatal logs'), and it distinguishes itself from sibling tools like 'get_logs' which may read all logs.

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 like 'get_logs' or 'get_network_requests'. There is no mention of prerequisites, limitations, or when not to use it, which leaves the agent without context for selection.

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 that the tool reads buffered non-error logs with cursor-based pagination. However, with no annotations, it fails to cover authorization, rate limits, or behavior when the buffer is empty, leaving notable gaps.

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 sentence front-loaded with the action and resource. However, it could include more detail without becoming verbose.

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 six parameters, no annotations, and no output schema, the description is insufficient. It omits parameter explanations, return format, and usage context, making it incomplete for effective tool selection.

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

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

With 0% schema description coverage, the description adds minimal parameter context, only hinting at `sinceCursor` and `limit` via 'cursor-based pagination.' It does not explain `sessionId`, `levels`, `tags`, or `sources`, leaving agents to infer meaning from names 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 specifies 'Read buffered non-error logs using cursor-based pagination,' clearly stating the verb 'read' and resource 'non-error logs.' This distinguishes it from the sibling `get_errors`, which targets error logs.

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 reading non-error logs with pagination but offers no explicit guidance on when to use this tool versus alternatives like `get_errors` 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 buffering and cursor-based pagination, which are key behavioral traits. However, it lacks details on data retention, rate limits, or what happens when no events are available, but for a read-only tool it is fairly 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 a single, front-loaded sentence that efficiently communicates the tool's purpose and key mechanism. Every word earns its place, with no fluff.

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

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

Given 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, how pagination works with sinceCursor, or the effect of filters like phases and methods. The agent would struggle to use this tool correctly without additional information.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions cursor-based pagination, which hints at 'sinceCursor' and 'limit', but does not explain any of the 8 parameters (sessionId, phases, methods, statuses, urlContains, sources). The agent gets no semantic help beyond the schema structure.

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 'Read', the resource 'buffered network request/response/error events', and the mechanism 'cursor-based pagination'. It distinguishes this tool from siblings like get_logs and get_errors by focusing on network events.

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 retrieving network events but does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_logs for logs, get_errors for errors). No exclusions or context are given.

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

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

No annotations are provided, so the description must bear the full burden of behavioral disclosure. It mentions 'inferred' context and 'remediation guidance,' hinting at heuristic nature and purpose, but lacks details about potential limitations, performance impact, or what the context actually contains.

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: two front-loaded sentences that deliver the purpose and usage condition without any filler or 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 tool with a single parameter and no output schema or annotations, the description adequately states purpose and usage context. However, it could improve by explaining the parameter and the return value to make it self-contained.

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

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

The description does not mention the 'sessionId' parameter at all, despite 0% schema description coverage. The agent learns nothing about its meaning, format, or expected values beyond the bare schema name and type.

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 gets 'inferred current Android screen context' for 'remediation guidance' and explicitly specifies usage context 'after testID lookup fails,' distinguishing it from sibling tools that also operate on screen 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?

The description explicitly states when to use this tool ('Use after testID lookup fails'), providing clear context and implying an alternative approach (testID lookup) without needing an explicit exclusion 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?

With no annotations, the description carries full burden. It only mentions 'with metadata' without specifying details, and does not disclose whether the operation is read-only, destructive, or any other behavioral traits like session requirements or error conditions.

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 efficiently convey purpose and usage guidance with no unnecessary words. Front-loaded with the core action.

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 six parameters, no annotations, and no output schema, the description is too minimal. It lacks explanation of parameters, return values, and behavioral details, leaving significant gaps for effective use.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does not mention any of the six parameters (sessionId, maxDepth, etc.), failing to add meaning beyond the schema.

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

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

The description clearly states it lists testIDs on the current screen with metadata, using a specific verb and resource. It also distinguishes from sibling 'get_elements_by_test_id' by suggesting ordering, making the purpose 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 explicitly advises to start UI interaction flows with this tool before using 'get_elements_by_test_id', providing clear usage context. However, it does not mention when not to use it or alternatives for other 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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'deterministic patch/remediation guidance' but does not explain side effects, required permissions, or output format. The agent is left uninformed about return values or 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 two sentences long, with the first stating the core purpose and the second providing a practical workflow. Every sentence adds value with no redundancy or fluff.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is inadequate. It fails to describe the remediation plan's structure or return type, and does not cover all parameter contexts. The workflow reference is helpful but insufficient.

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

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

Schema description coverage is 0% and the description does not explain any parameter. While parameter names (sessionId, desiredAction, desiredTestId, matchMode) provide hints, the agent has no formal guidance on valid values or semantics, especially for required parameter desiredAction.

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: building deterministic patch/remediation guidance when a desired testID is missing. It uses a specific verb ('build') and resource ('remediation guidance'), and distinguishes itself from sibling tools like get_screen_test_ids and get_elements_by_test_id.

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

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

The description provides a recommended flow (get_screen_test_ids -> get_elements_by_test_id -> this tool -> reload_app -> retry lookup), which gives clear context on when to use this tool. However, it does not explicitly state when not to use it or list alternatives.

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. The description implies a read operation but does not disclose potential side effects, performance impacts (though maxDepth/maxNodes hint at risks), or required permissions. For an unannotated tool, more transparency is needed.

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 sentence, which is efficient but omits critical information about parameters and usage. It achieves brevity at the expense of completeness.

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 three parameters with 0% schema coverage, no output schema, and no annotations, the description fails to provide adequate context. It does not explain return value, parameter constraints, or when to apply maxDepth/maxNodes.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters ('sessionId', 'maxDepth', 'maxNodes'). The schema provides no meaning beyond types and 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 verb ('read'), the resource ('accessibility hierarchy'), and the platforms ('Android UIAutomator or iOS WDA'). It effectively distinguishes from siblings like 'get_visible_elements' or 'take_screenshot'.

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 the 21 sibling tools (e.g., 'get_visible_elements'). The description does not mention context, prerequisites, or excluded 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?

No annotations provided, so description bears full burden. It states what is returned but does not disclose important behavioral traits such as performance impact, visibility filtering logic, or effects of parameters like maxDepth. Essential context is 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 concise with two focused sentences, no fluff. However, given the complexity of the tool (9 parameters), it may be overly concise, but it is well-structured and front-loaded.

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

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

Incomplete for a tool with 9 parameters and no output schema. It does not explain parameter meanings, return value format, or performance considerations. Multiple sibling tools exist but only one alternative is mentioned.

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

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

With 0% schema description coverage, the description must compensate but provides no information about any of the 9 parameters. Parameter names alone are insufficient for an agent to correctly use 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 it returns flattened visible accessibility elements from the UI tree, and explicitly positions it as a fallback after testID-first lookup, distinguishing it from siblings like get_elements_by_test_id.

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

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

Provides explicit usage guidance: use as fallback after testID-first lookup. Does not elaborate on when not to use or compare with other siblings like get_ui_tree, but the primary use case 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?

With no annotations provided, the description should disclose behavioral traits. It only states 'List all active...' but does not mention if sessions are returned with IDs, details, or any potential limitations like pagination. The read-only nature is implied but not explicit.

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 one sentence and no fluff. However, it could be slightly expanded to include what the list returns without losing 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?

Given no parameters, no output schema, and no annotations, the description is minimal but covers the basic purpose. It does not describe the return format or behavior, which is acceptable for such a simple tool but could be more 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?

No parameters exist in the schema, so there is no need to describe parameter semantics. The baseline score of 4 is appropriate as per the rule for zero 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 the verb 'List' and the resource 'all active MCP device sessions', which is specific and distinguishes it from siblings like 'close_session' or 'set_active_session' that operate on individual sessions.

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

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

No guidance on when to use this tool versus siblings. Does not mention alternatives, prerequisites, or context where listing all active sessions is appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without describing side effects, return behavior, or safety implications (e.g., whether it might close a session or cause data loss). This is insufficient for an agent to understand the tool's 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 a single sentence, which is concise. However, it is under-specified for a tool with one parameter, missing crucial details. The structure is not optimized for quick comprehension because it does not front-load the most important information (e.g., required 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 the tool's simplicity (one optional parameter, no output schema), the description should still cover basic context like what 'back navigation' means, whether it requires an active session, or what happens on failure. It fails to provide a complete picture for an agent to use the tool reliably.

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 description coverage is 0%, and the description does not explain the 'sessionId' parameter at all. The agent cannot infer what sessionId refers to or how to use it. The description adds no value beyond the schema, which itself lacks 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 action ('trigger back navigation') and the resource ('on the current platform'), which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'reload_app' or 'scroll' that also manipulate navigation. The purpose is clear but lacks sibling distinction.

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

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

No guidance is provided on when to use this tool vs alternatives. There is no mention of prerequisites, conditions, or when not to use it. The description simply states the action without any contextual usage cues.

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 carries full burden. It mentions fallback behavior but fails to disclose side effects, state loss, or error cases. 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?

The description is concise (one sentence) but omits important information, making it underwhelming rather than efficient. Under-specification is not 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?

For a simple one-parameter tool, the description lacks details on return value, success/failure indicators, and error conditions. Incomplete for an agent to reliably use.

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

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

Schema description coverage is 0%, and the description does not mention the sessionId parameter at all, leaving its purpose and constraints undocumented.

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 (reload) and the target (active app session), with method hints (Metro, ADB fallback). It distinguishes from sibling tools like close_session or connect_app, though does not explicitly differentiate.

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

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

No guidance on when to use this tool versus alternatives (e.g., close_session or disconnect_app), nor any prerequisites like running Metro server.

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 mentions 'via swipe gesture' which suggests simulation of a user gesture, but it lacks details on the behavior: e.g., whether it simulates a full swipe or a partial swipe, whether it works on all platforms, or what happens if the content cannot be scrolled. No annotations exist to fill this gap.

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

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

The description is very short (one sentence), which is concise but at the expense of completeness. It does front-load the core purpose but omits important details. It is well-structured for a brief definition but could include more information without being verbose.

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 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not cover return values, preconditions, side effects, or parameter semantics. The tool is part of a UI automation context, and the description lacks context needed for correct invocation.

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

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

The description does not explain any of the four parameters beyond what is obvious from the schema (e.g., direction is self-explanatory). The meanings of 'sessionId', 'distanceRatio', and 'durationMs' are not clarified. With 0% schema description coverage, the description should have compensated but did not.

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 scroll screen content via a swipe gesture. It specifies that it does so in a direction, which aligns with the 'direction' parameter. While it doesn't explicitly distinguish from siblings, the verb 'scroll' is unique among the listed siblings, so the purpose is sufficiently 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?

No guidance is provided on when to use this tool instead of others, or when it should not be used. There is no mention of prerequisites, contexts where scrolling might fail (e.g., no scrollable content), or comparison with alternatives like tapping or pressing back.

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 does not disclose behavioral traits such as side effects, authentication requirements, or rate limits. It only states the action without explaining what happens to the previous active session or whether the change is persistent.

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 sentence that is front-loaded with the action. It contains no unnecessary words, but may be overly brief given 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 the tool has one required parameter, no output schema, and no annotations, the description should explain the effect of setting the active session and how it impacts subsequent operations. It does not address these, leaving the agent with an incomplete understanding.

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

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

With 0% schema description coverage, the description adds no meaning to the 'sessionId' parameter beyond its name and required status. The agent receives no guidance on what constitutes a valid sessionId or where to obtain it.

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: setting the active session for when sessionId is omitted. It uses a specific verb ('Set') and resource ('active session'), and implicitly distinguishes from siblings like 'list_sessions' or 'close_session' by focusing on session selection.

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 explicit guidance on when to use this tool versus alternatives. It lacks context about prerequisites, when not to use it, or how it compares to related tools like 'close_session' or 'get_connection_status'. The agent must infer usage from the short description alone.

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

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

With no annotations, the description must disclose behavioral traits. It doesn't mention output format (base64/blob), side effects, or prerequisites. Minimal behavioral info.

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, no wasted words. Could be improved by adding important details without becoming verbose.

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

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

No output schema and no annotations, yet the description omits crucial details like what the tool returns, error scenarios, or usage context. Incomplete for a tool with one parameter.

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

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

Schema description coverage is 0%, and the description does not explain the sessionId parameter or its constraints beyond the schema definition. No added semantic meaning.

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

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

The description clearly states the verb 'capture' and resource 'screenshot from the connected device', distinguishing it from sibling tools like get_screen_context. However, it lacks specificity about the output format.

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

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

No guidance on when to use this tool versus alternatives like get_screen_context or get_ui_tree. No when-to-use or when-not-to-use information.

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 full burden. It describes the basic action but does not disclose side effects, requirements (e.g., active session), or error handling. Adequate but minimal.

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

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

Two short sentences with no wasted words. Front-loaded with the action, achieving maximum information density.

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 tool, the description covers purpose and usage well, but lacks details on prerequisites (session activation), return values, and error scenarios. Reasonably complete given 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 0%, and the description does not explain parameters beyond their existence. x and y coordinates are not described (e.g., coordinate system, units), and sessionId purpose is unstated. Fails to 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 the tool taps at absolute coordinates and positions it as a fallback, distinguishing it from sibling tools like tap_element which use testID/element targeting.

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 'Final fallback only when testID and element-based targeting fail,' providing clear guidance on when to use and when to consider alternatives.

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 states the action (tap) and dependency on element IDs from other tools, but does not disclose behavioral details such as whether the tap is a single tap, if it waits for element visibility, or side effects like triggering events. The behavior is somewhat obvious but not fully 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 sentences, front-loads the core action, and contains no redundant information. Every word earns its place.

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

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

For a simple tap tool, the description covers the primary task and source of element IDs, but omits explanations of optional parameters (maxDepth, maxNodes) and sessionId. It also lacks details on return values or error conditions, leaving gaps for an agent to infer.

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

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

The input schema has 4 parameters (sessionId, elementId, maxDepth, maxNodes) with 0% schema description coverage. The description only mentions elementId conceptually and does not explain the purpose of sessionId, maxDepth, or maxNodes. It fails to add meaning beyond the raw schema.

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

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

The description clearly states the verb ('tap'), resource ('visible element'), and method ('by element id from get_visible_elements/get_ui_tree'). It also distinguishes from sibling tools by noting it's a preferred fallback before coordinate tapping.

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 using this tool as a preferred fallback before coordinate tapping, providing clear guidance on when to use it. However, it does not specify scenarios where this tool should not be used or alternative methods.

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. Only mentions basic action and optional submit. Missing details: behavior if no field focused, character support, waiting, clearing existing text, or specific submit 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?

Single efficient sentence with no fluff. Front-loaded with action and scope.

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

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

No output schema and no annotations. Missing important context: role of sessionId, preconditions like focused field, and behavior on error. Only covers basic action, leaving gaps 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?

Schema coverage 0% and description only explains 'submit' implicitly ('optional submit/enter key press') but does not mention 'sessionId' at all. Adds minimal value beyond parameter names.

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 action: 'Type text into the currently focused input field' with optional submit. Distinguishes from sibling tools like tap and tap_element which are for clicking.

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 use for text input into focused fields, but no explicit guidance on when to use vs alternatives (e.g., when to use type_text vs tap_element). No preconditions or context mentioned.

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