Argent
OfficialServer Quality Checklist
Latest release: v0.24.0
- Disambiguation4/5
Descriptions are unusually explicit about boundaries — describe vs native-describe-screen vs debugger-component-tree each state their exact niche and when to use which. Two genuine ambiguities remain: the text/key tools look like duplicates of keyboard (a sub-function split into separate tools), and rotate (device orientation) vs gesture-rotate (two-finger rotation) share near-identical names, forcing the description to spell out the distinction.
Naming Consistency3/5Several strong families exist (gesture-*, debugger-*, react-profiler-*, native-*, flow-*, screen-recording-*), but conventions mix heavily: single-word imperatives (describe, paste, shake, button), hyphenated verb_noun (launch-app, list-devices), and standalone nouns (keyboard, key, text). The text/key pair is particularly confusing since they are keyboard's own functions surfaced as separate tools with inconsistent naming with their parent.
Tool Count2/5At 75 tools this is far over the comfortable threshold, even accounting for the genuinely broad multi-platform scope (iOS/Android/Chromium/Vega/TV). Much of the surface is fragmented rather than earned: text and key as clones of keyboard, several near-duplicate native view-inspection tools (native-view-at-point vs native-user-interactable-view-at-point), and many separate profiler-query modes that could be parameterized.
Completeness5/5The surface is remarkably complete for its stated purpose of driving and instrumenting mobile apps: full device lifecycle (list/boot/launch/restart/reinstall/stop), every interaction gesture, multiple observation paths, JS and native debugging, dual profilers with analysis and query tools, network inspection at two layers, and a flows capture/replay system. No obvious dead ends or missing lifecycle phases.
Average 4.6/5 across 75 of 75 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 33 of 43 community issues answered or closed in the last 6 months
- 268 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses normalized coordinates, auto-generated frames at ~60fps, angle parameter, optional centroid drift, return value, and failure condition. Explains distance relationship for zoom direction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with ~7 sentences, front-loading purpose and coordinate system. Concise overall, but could be slightly more structured (e.g., bullet points for parameters). No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and no output schema, the description covers coordinate system, gesture mechanics, typical values, optional behavior, return format, and failure condition. Leaves little ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: repeats coordinate normalization, gives typical values, explains drift mechanism, and clarifies start/end distance relationship. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it executes a pinch-to-zoom gesture with specific verb and resource. Distinguishes from sibling gesture tools by noting same coordinate space as gesture-tap and gesture-swipe, but could be more explicit about when to use vs. gesture-rotate or gesture-custom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'Use when you need to zoom in or out on a map, image, or zoomable view.' But does not specify when not to use or mention alternatives beyond coordinate space hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 transparently describes the platform-specific behaviors (iOS vs Android), signals, polling, and pull operations. It discloses the failure condition (no active session). However, it does not describe side effects like whether profiling is terminated or any cleanup, but given the nature of stop, this is acceptable. It adds context beyond the simple stop action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with three sentences covering purpose, method, and usage. It front-loads the action. It includes platform details and return value info, but the length is moderate. It is structured well; the platform breakdown is clear. Slight improvement would be trimming redundant details, but it's acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (platform-specific stops), the description covers key behaviors: signals, packaging, polling, exporting, return fields, and failure. It lacks an output schema, so it properly explains the return value. It's complete for an agent to select and invoke this tool, especially with the precondition 'Call native-profiler-start first.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for device_id. The description reiterates the parameter's origin ('from list-devices') and platform-specific formats, which slightly adds value beyond the schema. It doesn't explain any additional parameter aspects, but with one parameter well-covered, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: stop native profiling and export trace data. It distinguishes from siblings like native-profiler-start and native-profiler-analyze by specifying the stop/export action. It is not just a verb+resource, but it does not explicitly mention that it is the inverse of start, though it says 'Call native-profiler-start first.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: 'Call native-profiler-start first' sets a precondition, and 'Use when the user has finished the interaction to profile and you need to export the trace' gives a clear scenario. It doesn't explicitly mention when not to use or alternatives, but the 'call start first' is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavior. It discloses failure conditions and that it works on a live app, but does not mention read-only nature or performance impact, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words; front-loaded with action and main value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, failure conditions, and output format (markdown table). Lacks details on response structure but is adequate for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It adds no extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan' and the resource 'live React fiber tree', and it explicitly distinguishes from sibling profiling tools by noting 'no profiling session required'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for 'quick snapshot...without a full profiling session', but could clarify when not to use it or contrast with specific siblings like react-profiler-analyze.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pruning of off-screen components, normalized coordinates in [0,1], and failure condition (Metro debugger not connected). No annotations exist, so description carries full burden—adequate but could mention potential performance impact or other constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded with clear structure including workflow steps. Some redundancy (last sentence echoes earlier points), but overall efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers tool purpose, output format (text tree with coordinates), workflow, and failure case. No output schema needed as description explains what is returned. Adequate for a read-only diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters are well-described in the schema. Description reinforces usage context (e.g., includeSkipped) but does not add significant new meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it fetches the current screen as a compact component text tree with tap coordinates, distinguishes from siblings by being the preferred element discovery tool for React Native apps, and notes pruning behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed workflow and explicit use case (getting tap coordinates), advises re-calling after navigation/state changes, and mentions includeSkipped option. Lacks explicit when-not-to-use or comparison to all alternatives but is clear overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return value format, failure conditions (negative hours, persistence failure), and the side effect of suppressing notifications. Adequate for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no unnecessary words. Every sentence adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no nested objects, the description covers purpose, usage, behavior, and failure conditions completely. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for 'hours' including minimum and purpose. The description adds 'given number of hours' and 'suppression duration', but does not provide new meaning beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Clear the Argent update notification', which is a specific verb+resource. It defines the tool's action well but does not explicitly differentiate from siblings like 'update-argent', though the purpose is clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use when the user asks to postpone or silence update reminders.' It does not list alternatives or when not to use, but the context is clear and the failure conditions are noted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral details: it finalizes the mp4, handles early termination, returns specific fields, and fails if no recording exists. It lacks explicit mention of side effects (e.g., stopping capture process) but is otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. It contains three sentences, each serving a distinct purpose: main action, when to use, return value explanation. Slightly dense but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return structure (video, durationMs, etc.) and failure case. It covers the start-stop pattern context. Could mention dependency on screen-recording-start, but the first sentence implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'udid' is already described in the input schema as 'Target device id from list-devices'. The tool description repeats this verbatim, adding no new meaning beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool stops the recording started by screen-recording-start and retrieves the video, clearly distinguishing it from its start counterpart and other siblings like flow-finish-recording. It also covers edge cases like automatic termination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: 'Use when the interaction being captured is finished, or a tool-result note reminds you a recording is still running.' While it doesn't list explicit exclusions or alternatives, the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it thoroughly: it discloses interpolation at ~60fps, direction semantics, physical iOS quirks, momentum behavior, return shape, failure conditions, and the reactivated field. This goes far beyond a basic 'performs a swipe' statement and gives an agent concrete expectations for execution and results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation, but it quickly becomes a dense, run-on block of edge cases and empirical observations (e.g., '2 of 47 runs still flung backwards'). It also repeats much of the schema's momentum/duration text nearly verbatim, which adds length without new value. Every sentence carries some information, but the structure is not clean and the redundancy hurts conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex gesture tool with no annotations and no output schema, the description is remarkably complete: it explains platform support, coordinate normalization, return value, failure behavior, timing constraints, momentum semantics, and physical-device caveats. An agent has enough context to invoke the tool correctly and interpret its result in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 genuine extra meaning for parameters, notably that fromY > toY means swipe up to scroll down, that physical iOS edge gestures require fromX exactly 0, and that momentum:false requires durationMs >= 150. Much of the momentum and duration detail is redundant with the schema, but the unique insights push it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: executing a smooth swipe/drag touch gesture between two normalized points. It names use cases (scroll, dismiss modal, navigate) and even an alternative for Chromium, but it does not fully differentiate from the sibling gesture-drag, which the description also claims to cover with 'drag an element.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists when to use the tool ('Use when you need to scroll a list, dismiss a modal, drag an element, or navigate between pages') and gives a clear when-not with an alternative ('Not supported on Chromium — use gesture-scroll there instead'). However, it does not clarify when gesture-drag or gesture-tap should be preferred, leaving some sibling differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses the prerequisite, failure condition ('Fails if native-profiler-analyze has not been run'), iOS-only restriction for leak_stacks, and return format (markdown report). It doesn't explicitly state read-only or side effects, but 'Query' and the failure discussion make it clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded: prerequisite first, then bulleted modes, usage guidance, return type, and failure condition. Every sentence contributes meaningful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no annotations and no output schema, the description covers prerequisites, mode behavior, filters, output type, and error cases. It could be slightly more complete with an example invocation or more detail on the iterative workflow, but it is nearly sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces mode semantics and adds small details (e.g., function_callers shows what a function calls, leak_stacks is iOS-only), but it does not significantly expand on the parameter schema, which already documents behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Query' with clear resource 'native profiler trace data' and enumerates four distinct modes with precise behaviors. It clearly distinguishes from sibling profiler tools by specifying that native-profiler-analyze must have been called first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite chain ('Requires native-profiler-stop → native-profiler-analyze') and gives a clear use case: 'Use when drilling into native hang stacks, thread CPU breakdown, or memory leaks after native-profiler-analyze.' However, it does not name alternatives or explicitly state when not to use this tool versus other profiler query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the output structure (name, tag, actualDuration, etc.) and failure cases (missing DevTools hook or no committed roots). This is sufficient transparency for a read-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each adding distinct value: purpose, usage guidance, output format, failure conditions. No fluff, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description explains the output structure and failure modes adequately. It could benefit from an example or note about performance, but overall it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect the React fiber tree and return a JSON representation of the component hierarchy.' This is a specific verb (inspect) and resource (fiber tree) that differentiates it from siblings like react-profiler-analyze or react-profiler-renders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when tracing ancestry of a library component or checking for useMemoCache hook'. It also states failure conditions. While it doesn't list when not to use it vs alternatives, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that frame coordinates change, that the tool returns `{ orientation }`, and that it fails if the device is not booted. Since no annotations are provided, the description carries the full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with purpose and allowed values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, side effect, failure condition, and return value. For a simple two-parameter tool with no output schema, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add further meaning beyond what the schema provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set device orientation), lists the four allowed values, and sets it apart from sibling tools like gesture-rotate which handles rotation gestures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use before testing layout in a different orientation and to re-run `describe` afterwards. Does not mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that HttpOnly cookies are included, the actions are destructive (e.g., 'clear removes ALL browser cookies'), and failure cases (non-Chromium device, missing params). It also describes return values for each action. Missing details on idempotency or rate limiting, but covers major behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introduction, bulleted action list, usage guidance, return types, and failure conditions. It is front-loaded with the core purpose. A minor reduction for length, but every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 4 actions, no output schema, and no annotations, the description covers purpose, usage, parameter roles by action, return values, and failure conditions. It lacks details about the format of returned cookie objects, but overall provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by grouping parameters per action (e.g., 'action="get" (url?)... defaults to the active page'), which provides context beyond the schema's individual parameter descriptions. It clarifies which parameters apply to which actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read and write') and resource ('cookies of a Chromium (CDP) app'), and enumerates four distinct actions (get, set, delete, clear). It clearly distinguishes the tool's scope from siblings like 'chromium-storage' which handles other storage types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use when seeding an authenticated session before a flow... or asserting cookie state after one.' It also notes Chromium-only requirement and failure conditions. However, it does not mention alternative tools for related tasks (e.g., localStorage), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details runtime environments (Hermes, V8), that results are serialized by value, that cyclic objects cause a serialization error (not silent), and that evaluation fails if the expression throws or runtime is not connected. It does not explicitly clarify whether evaluation is read-only or can have side effects, but the caveats are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: first states purpose and return, second lists caveats. It is front-loaded with the main verb and resource. Slightly lengthy but no wasted words, and all information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no output schema, the description covers return value (JSON-serializable plus deviceName, appName, logicalDeviceId) and failure modes. It does not mention expression length limits, timeouts, or security restrictions, but for a development tool this is sufficient. Sibling tools are not compared, but overall completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds value beyond the schema: for device_id it clarifies it is the same id from list-devices or debugger-connect, preferring list-devices. For port, it notes it is ignored for Chromium. Expression parameter description is redundant with schema but consistent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary JavaScript in the app's runtime via CDP, specifying the engine per platform (Hermes on iOS/Android/Vega, V8 on Chromium). It lists specific use cases: read app state, call functions, test logic, and describes the return value. This distinguishes it from sibling tools like debugger-status or debugger-component-tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance: 'Use when you need to read app state, call app functions, or test logic at runtime.' It also mentions limitations (cyclic objects fail). However, it does not explicitly state when not to use this tool or suggest alternatives among the many sibling tools, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return shape ({ message, stepCount, savedTo }) and the failure condition (no recording in progress). It also explains the side effect of echoing a message when replayed. Absent are details about mutations to the flow file, but the behavior is adequately characterized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the purpose in the first sentence, then provides usage guidance, return information, and failure condition in a few sentences. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this tool's complexity: it explains what the tool does, when to use it, what it returns, and a key error condition. Even without an output schema, the return shape is explicitly stated, making the tool's behavior fully comprehensible in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter described (name, project_root, message). The description's mention that `name` + `project_root` identifies the flow is already embodied in the project_root schema. Thus the description adds no significant semantic value beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Record an echo step in the flow named by `name` + `project_root`' and explains that echo steps print a message on replay, distinguishing it from flow-add-step. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use when you want to annotate a recorded flow with a human-readable label or checkpoint message.' It also notes the failure condition when no recording is in progress. However, it doesn't explicitly name alternatives like flow-add-step, so it stops short of a full alternatives comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return shape, how the MCP adapter renders the image, the effect of includeImageInContext, and a key failure condition when the backend is unreachable. It does not over-claim or contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first defines the action and result, the second gives usage guidance, and the third states a practical failure mode. The most important information is front-loaded and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers the supported platforms, the return value representation, the adapter rendering behavior, the primary use cases, and the main failure scenario. This is sufficient for an agent to decide when and how to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 5 parameters with 100% coverage, so the baseline is 3. The description adds some context around includeImageInContext by tying it to whether the MCP adapter renders the image, but it does not meaningfully enrich the meaning of the other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Capture a screenshot of the device screen,' and enumerates all supported device types. This clearly distinguishes it from screenshot-diff and other inspection tools by stating exactly what it produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use when you need a baseline image before an interaction or to inspect the current screen state after a delay.' It does not explicitly list when-not-to-use cases or point to alternative tools, but the stated use cases are clear enough for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains idempotent behavior (returns existing connection if already connected), platform-specific differences, and failure modes. Could mention if any state is mutated, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, then structured by platform. Each sentence adds value. Slightly verbose but efficient for the complexity. Could be more concise, but still well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains return fields, failure conditions, and the tool's role relative to siblings. Covers platform differences and id usage, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value: explains that 'port' is ignored for Chromium and provides extra context for 'device_id' (stable id, logicalDeviceId informational). This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Connect to a JS runtime CDP debugger.' It details platform-specific behaviors (iOS/Android vs Chromium) and distinguishes from siblings by being the prerequisite for other debugger-* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when starting a debug session or before calling other debugger-* tools.' It also mentions failure conditions (Metro down, CDP terminated). Lacks explicit 'when not to use' but context implies it's the initial step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses internal mechanisms ('Uses getInspectorDataForViewAtPoint + _debugStack + Metro /symbolicate') and explains behavior of parameters like maxItems and resolveSourceMaps. It does not explicitly state read-only nature but implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with multiple paragraphs, but each sentence serves a purpose. Front-loaded with the core function, then details. Could be slightly tighter but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains return value: 'components... each with its source file:line and a code fragment', including hierarchy ordering. It also covers failure conditions, parameter effects, and internal details. Comprehensive for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 significant value beyond schema, explaining the ordering of returned items ('first items are most specific') and the purpose of maxItems (covers app-specific code vs navigation structure). This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect the React component hierarchy at a screen coordinate (x, y)' with a specific verb and resource. It differentiates from siblings by focusing on React component inspection via coordinates, unlike tools like native-view-at-point or debugger-component-tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use when you need the source file and line for a component at a tap coordinate' and 'Fails if the app is not connected or the coordinate is outside the screen'. While explicit about when to use and failure conditions, it does not mention specific alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden, and it delivers excellently. It discloses that the tool never fails when the runtime is unreachable but returns a discriminated result, enumerates all failure reasons, and explains nuances like 'sourceMapReady always true - waits for pending source maps' and 'port omitted on Chromium.' This is far beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured with bullet-like enumeration of result variants. It opens with a concise summary of purpose and usage, then dives into necessary detail. Every sentence contributes value, though the length is on the upper edge, making it not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must fully explain return values, and it does so thoroughly. It covers the connected and not_connected variants, all failure reasons, optional fields, and important behavioral details. For a tool with this complexity, the description is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for both parameters, including the relationship to debugger-connect and preference for list-devices id. The tool description adds no additional parameter-level semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('JS runtime debugger connection status and diagnostic info'). It distinguishes this tool from sibling debugger tools (debugger-connect, debugger-evaluate) by focusing specifically on status/connectivity verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you need to verify connectivity before using other debugger tools,' providing clear context. It also advises following the 'guidance' field and not retrying in a loop, but does not explicitly mention when not to use or alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, and it does so thoroughly. It explains side effects (leaving other recordings untouched), the return shape, failure conditions, and the nuanced warning propagation/dropping behavior for hand-edited YAML, cross-tree warnings, unmet waits, and UNKNOWN conditions. It even notes that the YAML can still be edited afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, with no filler. Core purpose, return value, and usage guidance are front-loaded in the first paragraph, while the later paragraphs explain important warning and replay semantics that genuinely affect how the result should be interpreted. It could be tightened, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the absence of annotations, and the absence of an output schema, the description is remarkably complete. It covers the return keys, the failure condition, the subtle warning behavior, what to read before replaying, and the option to edit the YAML afterward. An agent has enough context to invoke the tool and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters, with 100% coverage. The description reinforces that `name` and `project_root` together identify the recording and must match the values passed to flow-start-recording, but this adds only marginal meaning beyond the schema's own wording. Schema coverage does the heavy lifting here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Finish recording the flow named by `name` + `project_root`' and distinguishes this from related recording tools by stating it finalizes the flow and returns the recorded steps plus final YAML. It also gives the exact use case: 'Use when you have added all desired steps and want to finalize the flow file.' This clearly separates it from siblings like flow-add-step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: after all desired steps have been added and the flow file should be finalized. It also states a precondition/failure mode: 'Fails if that flow has no recording in progress.' It does not explicitly enumerate alternatives or when-not-to-use cases, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 discloses platform-specific analysis behavior, the markdown report format, severity indicators, tables, actionable suggestions, and the follow-up interaction of asking the user before deeper investigation. It could be slightly more explicit about side effects, but for an analysis tool this is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and logically organized, covering platform details, output format, usage condition, and follow-up workflow. There is some redundancy: 'Call native-profiler-stop first...' and 'Fails if native-profiler-stop has not been called first...' repeat the same prerequisite. This minor duplication prevents a perfect score but the description is still concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers input, platform-specific behavior, output format, prerequisite, failure mode, and recommended next action. This is sufficient for an agent to decide when to use the tool, invoke it correctly, and handle the resulting markdown report appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single device_id parameter is already well described with its source: 'Target device id from list-devices (iOS UDID or Android serial).' The main description does not add further parameter-specific meaning beyond what the schema provides. Therefore the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Analyze exported native trace data and return an LLM-optimized markdown report.' It further specifies iOS XML parsing and Android Perfetto querying, giving clear resource and platform scope. This clearly distinguishes it from sibling tools like profiler-stack-query and react-profiler-analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use when you need to interpret a completed native profiling recording.' It also gives a prerequisite and failure condition: 'Call native-profiler-stop first' and 'Fails if native-profiler-stop has not been called first.' The reference to profiler-stack-query as a downstream drill-down option adds useful usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses terminating and relaunching, refreshing native-devtools injection, tvOS focus-driven interaction, return value, and failure condition. Missing potential side effects like persistence of app data, but the tool's purpose (restart) implies no data loss beyond state. Overall transparent for the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: action, usage scenario, platform-specific behavior, outcome/failure. Front-loaded with main purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description specifies return format '{restarted, bundleId}', which is sufficient. Covers parameters (all in schema) and platform specifics (tvOS vs iOS). Could mention that app data persists, but not required for basic understanding. Complete for a simple restart tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context like 'udid' from 'list-devices' and notes 'activity' is Android-only, which is already in schema. No additional semantics beyond schema that significantly aid selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Terminate then relaunch' and the resource 'app by bundle id / package name'. It distinguishes from sibling tools like 'reinstall-app' by noting 'without a full reinstall' and from 'launch-app' by implying a restart rather than fresh launch. Also mentions tvOS-specific behavior, differentiating from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you need a clean in-memory state without a full reinstall', providing when-to-use guidance. Also advises on tvOS to use 'tv-* tools rather than coordinate taps', which is an exclusion. States failure condition 'Fails if the app is not installed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits: the tool server restarts automatically, failure conditions (no update available or update in progress), and return value structure. Given no annotations, the description carries full burden and does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: front-loaded with main action, then details on usage, parameter, side effect, and failure modes. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description is complete. It covers purpose, when to call, parameter details, behavior, and return value. Little room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining the default behavior of the 'target' parameter and the meaning of each option. Schema coverage is 100%, but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Apply a pending Argent update.' It specifies the resource (Argent update) and action (apply), and distinguishes from the sibling tool 'dismiss-update' by indicating when to apply vs. dismiss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Only call this tool when the user has explicitly consented to updating Argent in this conversation.' It also specifies conditions (update notification, user agreement) and default behavior. However, it does not explicitly mention the alternative sibling 'dismiss-update' for cases where the user declines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that sensitive headers are redacted, large response bodies are truncated, and includes optional body parameter. Also mentions return type for error (error message string). Given no annotations, this adequately describes behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: core definition, returned data details, usage guidance, and error handling. No redundant or tangential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers essential aspects: purpose, parameter source, return types (including error), and limitations (truncation, redaction). Could mention that network logging must be active, but overall sufficient for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%), but description adds value: device_id linked to list-devices and debugger-connect, requestId sourced from view-network-logs, and includeBody clarifies '(if captured)'. This enriches understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets full details of a specific network request by requestId, which distinguishes it from sibling tool view-network-logs that lists requests. The verb 'get' and resource 'details of a specific network request' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when you need headers, body, or timing for a specific request after listing logs. Also explains error case: if requestId not found, use view-network-logs to get valid IDs. Provides clear context but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers key behaviors: no native restart, failure condition if Metro not running, and return fields. Missing potential side effects like state reset, but implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: purpose, use-case, then return/failure conditions. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return shape, failure conditions, and usage context. Distinguishes from siblings like 'restart-app' and 'stop-metro'. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameters (100% coverage). Description adds essential usage context for 'device_id' (must match debugger-connect's id), adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Restart' and noun 'Metro JS bundle', clearly differentiating from sibling tools like 'restart-app' (whole app restart) and 'stop-metro' (stop, not reload).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'apply code changes or reset JS state'. Does not explicitly state when not to use, but context is clear given siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does well: it explains the four query modes, states that output is a markdown table or tree, and discloses failure conditions ('Fails if react-profiler-stop has not been called or no commit data is stored'). It does not explicitly state that the tool is read-only, but 'Query' and the output/return framing imply no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a required precondition, a compact mode list, a use-case pointer, an output summary, and a failure condition. Every sentence contributes useful information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested time_range object, 4 modes, no output schema), the description provides a complete picture: purpose, preconditions, mode semantics, return type, and failure modes. It complements the 100% schema coverage well and leaves no major operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema by explaining each mode's behavior and result shape, e.g., 'by_component: All commits where a specific component rendered, with causes and durations.' It also clarifies the mode-specific meaning of top_n through the schema description, which is reinforced conceptually by the mode list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Query React commit data for iterative investigation of render performance.' It clearly distinguishes the tool from siblings by focusing on commit-level query modes (by_component, by_time_range, by_index, cascade_tree) and explicitly frames it as follow-up drilling after react-profiler-analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Requires react-profiler-stop to have been called first' and 'Use when drilling into specific components or time windows after react-profiler-analyze.' It also states failure conditions. It lacks an explicit excluded-alternative statement, but the context is sufficiently clear to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers the core disk-to-memory restore behavior, return types for each mode, failure cases when data is missing, and the special app_process handling for older Android sessions. It stops short of specifying what happens to previously loaded sessions or cache keys, but the main operational behavior is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the main purpose is stated first, followed by differentiation, usage guidance, a scannable mode list, and failure conditions. Each sentence contributes operational or decision-making value without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, three modes, no output schema, and no annotations, the description is sufficiently complete. It explains what the tool does, when to use it, what each mode does, what inputs are required for each mode, what it returns, and when it fails. This gives the agent enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even with no extra parameter semantics in the description. The description does add some mode-level context around session_id, device_id, and app_process, but most parameter meaning is already fully captured in the input schema. It does not significantly go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch and restore a previously captured profiling session from disk into memory.' It clearly distinguishes itself from sibling tools by naming the write-side tools (react-profiler-stop/native-profiler-stop) and the read-side query tools (profiler-cpu-query, profiler-commit-query, profiler-stack-query), and by listing its three modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use when you need to revisit past session data without capturing a new recording.' It also provides mode-specific prerequisites (session_id for load_react/load_native, device_id for load_native, app_process for older Android sessions) and describes failure conditions, giving the agent clear decision guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns found:false for node_modules components, handles multiple matches with otherMatches[], returns 50 lines of source and memoization status. No destructive actions mentioned; for a read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Only two sentences, front-loaded with primary function and output, then usage instruction and edge cases. Every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly covers return values (file path, line number, memoization, 50 lines of source, found status, otherMatches). Also explains the not-found case and ambiguity handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds context like component_name for lookup and project_root for file system. Also explains how parameters are used in the context of multiple matches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and resource 'React component's source', listing exact return fields. It distinguishes itself from siblings like debugger-component-tree by stating its specific role in the profiling workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this per-finding after react-profiler-analyze to inspect source before proposing a fix.' Provides clear context but no explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly discloses key behaviors: uninstalls first, clears data and permissions, return value shape, and failure conditions (path existence, platform mismatch).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading the main purpose, with no unnecessary words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return value shape, failure conditions, and platform-specific details. Without an output schema, the description provides sufficient context for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The main description does not add extra parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('install or reinstall') and resource ('app on the device'), and distinguishes from siblings like 'launch-app' and 'restart-app' by emphasizing reinstallation and data clearing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'full reinstall after rebuilding' or 'start from a clean app state'. Does not explicitly mention alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format '{ stopped, port, pids }', states behavior when no process found (stopped=false), and mentions failure conditions (timeout, cannot kill). Explicitly labels the tool as DESTRUCTIVE, which compensates for absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a warning. Front-loaded with purpose in the first sentence. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, return value, failure modes, and destructive nature. Despite no output schema, the description fully explains the return shape. Adequate for a simple tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (port) with 100% schema coverage. Description adds little beyond what the schema provides: mentions default 8081 (already in schema) but no extra semantic depth. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specifically states 'Stop the Metro bundler process listening on a given port', with verb 'Stop' and resource 'Metro bundler process'. Clearly distinguishes from sibling tools like 'stop-simulator-server' and 'stop-all-simulator-servers' which target different server types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when ending a React Native session or when Metro must be restarted', and includes a mandatory confirmation note. Does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 on Apple TV simulator, media-transport and volume keys are rejected due to HID stack limitations. It also explains the behavior of repeat and multi-step paths, and the return value {pressed, count}. However, it does not mention error handling, concurrency, or rate limits, though these are less critical for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core action, then details usage, examples, and return value. Every sentence adds value. While it is somewhat lengthy, it is appropriate given the complexity of explaining multi-platform behavior and path usage. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use cases, platform differences, and best practices. It explains the return value and advises using describe for screen reading. It does not explicitly mention error handling or timeouts, but given the tool's simplicity and the schema's coverage, it is fairly complete. Missing output schema is compensated by describing return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by explaining how to use single buttons, repeat, and multi-step paths. It includes platform-specific caveats (Apple TV simulator rejecting certain keys) and examples. This helps the agent understand parameter usage beyond enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool presses TV remote/D-pad buttons on specific TV devices (Apple TV, Android TV, Vega). It distinguishes itself from gesture-tap/swipe by explicitly noting that those do not apply on a TV. The verb 'press' and the resource 'TV remote button' are specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'use this instead of gesture-tap/swipe (which do not apply on a TV)'. It also advises to 'strongly prefer this over multiple tv-remote calls' for multi-step navigation and recommends reading the screen with `describe` before and after. This clearly tells the agent when and how to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits. It details the returned data (method, URL, status, size, duration), pagination (up to 50 entries per page), platform-specific differences (React Native vs Chromium), and failure cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 100 words) and well-structured. It starts with a clear purpose statement, then provides details about the output, platform differences, usage guidance, and failure conditions without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return format (paginated list with fields). It also covers purpose, usage context, failure modes, and platform variations, making it complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 minimal extra context beyond the schema, such as mentioning that each page contains up to 50 entries (relevant to pageIndex) and that port is ignored on Chromium.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves captured network requests from the running app. It distinguishes from related sibling tools like view-network-request-details by noting that each entry includes a requestId for further details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use when inspecting outbound HTTP traffic or debugging API calls in the running app.' It also mentions failure conditions. However, it does not explicitly state when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details return contents (path, counts, clusters), empty-state semantics including the note about stop-all-simulator-servers, the not_connected response shape with guidance, and the dead-socket caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, covering many edge cases. It is front-loaded with core purpose, though the single-paragraph format is dense. Every sentence earns its place given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description thoroughly explains return values, error states, and caveats, providing a complete picture for an agent to use the tool correctly and know when to choose alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for both parameters (port and device_id), including the Chromium ignore and device-id preference. The description adds no new parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get a summary of all console logs captured from the app's JS runtime.' It clearly distinguishes from sibling network-log tools by scoping to console logs and mentions supported runtimes (Hermes/V8).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use when investigating warnings, errors, or unexpected output — call this first for an overview.' It also names an alternative: 'use debugger-status, not this tool, to judge debugger health,' and warns against retry loops when not connected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description must fully disclose behavior, and it does: gesture-tap conversion to tap, restart-app to launch, await-ui-element re-probing against a different tree, returned fields, the two success-with-no-recording cases, and the warning semantics. It even covers mid-recording edits and remote vs host mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is accurate and front-loaded, but it is extremely long and dense, with nested clauses and repeated warnings. It would benefit from bullets or segmented edge-case sections; the current monolithic paragraphs make it easy to miss the core while parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating recording tool with no annotations and no output schema, the description is remarkably complete: it states success return shape, error behavior, when `recorded` is omitted, what to do for directives, and how to undo a mistaken step. Nothing an agent needs to safely decide and invoke the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by detailing command-specific recording behavior for gesture-tap, restart-app, and await-ui-element, and by explaining that `name`+`project_root` jointly identify the recording. It does not add much on args/delayMs, but those are already well documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Execute a tool call and record it as a step in the flow', and it anchors the flow identity to `name` + `project_root`. This clearly distinguishes it from recording siblings like flow-start-recording and flow-add-echo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use when recording a flow and you want to run and capture each action', and it instructs the agent to see flow-start-recording if no recording is open. It also delineates when a call is refused (directives, recording tools) and even lists directives with no recording tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses partial data behavior: 'Returns partial data if workspacePath does not exist or is not readable; missing items are represented as null or empty collections.' Also states failure conditions: 'Fails if the workspacePath is not an absolute path or the directory cannot be accessed.' No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient, starting with a one-line summary, then detailing returned data, usage instructions, and behavior. It avoids redundancy, though it is slightly long due to the extensive list of returned fields; each field adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (returns many data points) and no output schema, the description fully enumerates all returned items and covers edge cases (partial data, failure modes). No gaps in what the agent needs to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, providing an absolute path example. The tool description does not add additional semantics beyond the schema, which is already adequate. Baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch a structured snapshot of a mobile app project's workspace.' It enumerates the specific data returned (package.json, metro config, etc.), and distinguishes itself from siblings, which are mostly device interaction and debugging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (inspect project configuration) and when not to: 'DO NOT RUN THIS TOOL IF YOU ARE THE MAIN AGENT AND THIS TASK CAN BE DELEGATED TO A SUBAGENT.' Provides a clear usage sequence: 'If you are a subagent... run this as the first step.' Also recommends follow-up tools (Read/Glob/Grep).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the event type, coordinate space, return value, and failure condition (CDP session unreachable). Lacks details on default delta values or error messages, but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured with clear, informative sentences. It is appropriately sized for the complexity, though could be slightly more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description covers usage, platform, coordinates, return format, and failure. However, it does not specify default values for optional delta parameters (defaults to 0?), which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The tool description adds value beyond schema by explaining normalization, coordinate space shared with other tools, and delta direction (positive scrolls down). Enhances understanding for all 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls content by dispatching mouse-wheel events. It specifies the coordinate system (normalized 0.0-1.0) and platform (Chromium). It distinguishes from sibling 'gesture-swipe' by noting Chromium-only vs iOS/Android.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (content below/above fold, lists needing scrolling) and when not (use gesture-swipe on iOS/Android). Provides clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 return format (status + view with class, frames, identifier, label, layer name, ancestor chain, subviews on request), the coordinate system (raw points, not normalized), and detailed error-handling for statuses (restart_required, service_stale, connect_pending, init_failed) and failure modes (system apps rejected). No contradictions with annotations since none are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: it opens with the core purpose, then contrasts with a sibling, gives a use case, describes return structure, and concludes with status handling. Every paragraph covers a distinct aspect and includes necessary operational details. It could be slightly trimmed but remains efficient given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 4 required) and the absence of an output schema, the description is exceptionally complete. It covers the return value structure, all expected statuses with recovery steps, coordinate system specifics, and Edge cases (system app rejection). It leaves no major gaps for an agent to successfully use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all 10 parameters, including descriptions for x/y coordinates and field lists. The description adds a warning about raw coordinates and clarifies default behavior (e.g., includeAncestors defaults true), but these are already in the schema. It does not significantly add value beyond what the schema documents, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects the deepest visible UIView at a raw native window point, and explicitly contrasts with native-user-interactable-view-at-point, distinguishing it as answering 'what is visually here?' rather than 'what would receive the touch?'. This makes the purpose specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Use when a screenshot shows something the accessibility tree does not name — an unlabeled icon, a decorative overlay, a custom-drawn cell'. It also names the sibling alternative and explains the difference, fulfilling the when/when-not requirement fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: reads from stored cpuProfile, requires prior call to 'react-profiler-stop', returns a markdown table, and fails if prerequisites are not met. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear purpose, usage, prerequisites, and return format. It is slightly repetitive (e.g., 'do NOT call' is implied by alternatives) but every sentence adds value. Few words could be trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return value format (markdown table with self-time, total-time, location). It covers prerequisites, failure conditions, and source. Tool complexity is moderate (4 params, no output schema), and description is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters have descriptions). The tool description does not add significant new semantics beyond the schema, except for describing the overall return format (markdown table with fields). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a raw Hermes CPU flamegraph summary with top hotspot functions by self-time. It distinguishes from sibling tools by specifically naming 'react-profiler-analyze' as the alternative for broader React performance analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (dedicated CPU investigation for non-React hotspots) and when not to use (normal profiling session). Recommends 'react-profiler-analyze' as alternative and lists prerequisite: call 'react-profiler-stop' first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, description carries full burden. It discloses delegation to in-app backend, returns already_running payload without clobbering, force reclaim behavior, and failure conditions (Hermes unreachable, Metro connection fail). However, does not mention potential performance impact or state modifications beyond profiling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: main action, delegation, special case, usage guidance, return values, failure conditions. Well-structured with logical flow. Slightly longer than minimal but no dead content. Could be condensed slightly but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and moderate complexity, the description covers purpose, usage workflow, behavioral edge cases, failure modes, and integration with sibling tools. It fully addresses the information gap needed for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 4 parameters described in schema). The description adds context for the force parameter (user approval before overtaking), which goes beyond the schema description. For other parameters, schema suffices, so description adds moderate extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Start CPU profiling + React commit capture on the connected Hermes runtime,' which clearly states the verb (start) and resource (profiling on Hermes runtime). It distinguishes from siblings like native-profiler-start and react-profiler-stop by mentioning delegation to React DevTools backend and the parallel native profiling recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: ask user about native profiling before calling, recommend running both in parallel, ask user to perform interaction after starting, then call react-profiler-stop. Also explains when to use force=true and warns to get user approval before overtaking another session. No alternative guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it reads from the in-app React DevTools backend, stores results, and details the return structure. It also explains edge cases with unattributed data when fibers unmount before stop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured with logical flow: action, source, storage, sequence, return, edge case. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (100% schema coverage) and no output schema, the description comprehensively covers purpose, usage, return fields, and edge cases. It also positions the tool within the profiling workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. However, the description adds context: port defaults to 8081, device_id must be the same as passed to debugger-connect. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stops CPU profiling and collects the cpuProfile + React commit tree. It specifies the action (stop), resource (CPU profiling), and outcome (collect data). It distinguishes from siblings like native-profiler-stop by mentioning React-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage sequence: call react-profiler-start first, then exercise the app, then call this. It also mentions failure conditions (no active session or CDP lost). It does not explicitly state when not to use, but the sequence is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses polling behavior, thresholds, return object fields (settled, waitedMs, polls), and explains that settled=false means timeout reached. It also references the same tree as 'describe'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient (~100 words), well-structured with purpose first, then mechanism and usage advice. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return value thoroughly. Complex tool with 4 parameters all covered. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by explaining default values, roles of each parameter, and the polling mechanism shared with 'describe'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool blocks until screen content settles or timeout, using a specific verb 'Block until' and resource 'screen content settled'. It distinguishes itself from siblings like 'describe' and 'await-ui-element'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use after a launch/navigation to wait for the UI to render before screenshotting or tapping', providing clear when-to-use context. No explicit when-not, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it explains polling intervals, defaults, return shape, and the crucial nuance that success=false is not always a verdict on the condition, with cause values of unmet, unreadable, and cancelled. It also discloses selector matching pitfalls, reading order, hidden zero-area semantics, and the underlying accessibility/DOM sources. This is exemplary 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with headings and front-loaded purpose. Some condition details are repeated from the schema, which adds length, but the additional context about selector resolution, failure causes, and polling justifies most of the content. It is dense but organized enough for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, a nested selector object, multiple conditions, and no output schema or annotations, the description is remarkably complete. It explains the return value shape, failure semantics, when a failure licenses rewriting the check, and even the environmental tree types. There are no critical gaps that would prevent correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains reading order for visible text matches, the loose-selector trap, the unqualified Android resource-id matching behavior, and the exact meaning of each condition. It clarifies expectedText and textMatch behavior contextually rather than merely restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Block until a UI element reaches an expected state or a timeout elapses.' It clearly distinguishes itself from polling screenshot/describe by stating it removes that need, and the conditions section further defines exact behavioral scope. This is much more than a tautology and stands apart from sibling tools like describe and await-screen-idle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives explicit usage guidance: 'Use this after a tap/navigation to wait for the next screen, or before tapping an element that appears asynchronously.' It also explicitly contrasts with polling screenshot/describe yourself. It does not formally enumerate when not to use it or name all sibling alternatives like await-screen-idle, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so thoroughly. It discloses that the tool waits until the target is ready, returns a tagged payload, can take 2–10 minutes on Android, hot-boots from snapshots with cold-boot fallback, and terminates spawned devices on Android/Electron boot failure. This is unusually rich operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is dense and well structured: core action first, then platform selection, usage timing, return shapes, and operational caveats. Every sentence carries information needed to invoke the tool correctly, and the critical selector rule is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex four-platform tool with 10 parameters, no annotations, and no output schema, the description is complete. It explains return payloads for every platform, mutual exclusivity of platform-selector parameters, boot durations, snapshot behavior, and failure cleanup. The schema handles remaining platform-specific parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 cross-parameter meaning by explaining that the passed argument selects the platform, that Android assigns a serial automatically, and that a CDP port is auto-picked unless electronPort is supplied. This is more than a per-field schema listing provides centrally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: start an iOS simulator, launch an Android emulator, start a Vega VVD, or spawn an Electron app. It also explains that each platform is selected by a specific argument, which makes the tool's purpose distinct from siblings like list-devices and launch-app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use at the start of a session once you have picked a target.' It also explains that the choice of platform is determined by which argument is passed. However, it does not explicitly name when-not-to-use cases or contrast with post-boot tools like launch-app or restart-app.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses platform-specific event injection behavior (iOS Down/Up vs Android adb keyevent), unsupported-button rejection, the return value shape, and failure conditions when the backend is unreachable. This is exceptionally transparent for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence earns its place: platform behavior, supported buttons, usage intent, return value, and failure modes. It is front-loaded with the core action and structured logically, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers return format, failure conditions, platform specifics, and supported values. Given the moderate complexity of this tool, nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters with useful descriptions. The description goes beyond the schema by explaining platform-specific meaning of the button enum, which buttons are rejected on which platforms, and how the press is actually injected. This adds genuine value beyond the structured field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Press') and resource ('device hardware button'), with platform scope explicitly covered. It clearly distinguishes itself from sibling gesture and keyboard tools by focusing on hardware buttons and even gives platform-specific examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage sentence: 'Use when you need to trigger hardware button events.' It also clarifies platform-dependent behavior and which buttons are rejected, giving practical guidance. It does not explicitly mention alternatives like gesture-tap or keyboard, but the hardware-button focus makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description covers all behavioral traits: lists actions, return values, failure conditions (non-CDP, missing keys), per-origin scope. Comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, front-loaded main purpose, no fluff. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains return shapes for all actions, constraints (Chromium-only), and failure reasons. Complete for a 5-param, 4-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with descriptions. Description adds return format details and action behaviors beyond schema, e.g., value vs entries+count, status objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read and write localStorage/sessionStorage of a Chromium (CDP) app's active page.' Specific verb and resource, distinct from siblings like chromium-cookies or chromium-tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when seeding feature flags / auth tokens before a flow or asserting persisted app state after one.' Provides context but no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses all behavioral traits: actions, tab stability, default active tab, closure behavior, return format, and failure cases. No annotations so description carries full burden, which it meets thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points for each action, clear and efficient language. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: all four actions, preconditions, return value, failure modes, and Chromium-only restriction. No output schema, but return structure is described. Complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable context such as tabId stability, label interchangeability, and default for close. Exceeds baseline of 3 by providing extra information beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists, switches, opens, and closes tabs/windows of a Chromium (CDP) app, distinguishing from sibling tools by specifying the target platform and actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (multiple windows/tabs, to inspect/drive a different page, open/close during flow) and failure conditions. Does not explicitly mention alternatives but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses platform-specific implementation details, coordinate normalization, lack of z-order/occlusion information, Vega's empty-tree retry behavior, TV focus-driven output, and the physical iOS device limitation. It also explains the return shape { description, source } and how to compute tap coordinates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place given the multi-platform complexity. It is front-loaded with the core purpose, then organized by platform, return format, caveats, and alternatives. There is no redundant filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must fully compensate. It covers platform-specific behaviors, return format, coordinate system, tap calculation, limitations, fallback suggestions, and sibling alternatives. Nothing an agent needs to invoke and interpret this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The main description does not add much parameter-specific meaning beyond the schema, but the schema itself already documents udid and bundleId, including bundleId's fallback behavior and platform limitations. Thus the description adds no significant extra value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the accessibility / DOM element tree for the current screen.' It then clarifies what this means across iOS, Android, Chromium, and Vega, and explicitly distinguishes itself from native-describe-screen and debugger-component-tree, so an agent can select it correctly among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use native-describe-screen for app-scoped UIKit inspection, use debugger-component-tree for React Native component names, and use tv-remote on TV targets. It also provides platform prerequisites such as launching com.apple.springboard before reading system dialogs on physical iOS devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so extensively: it discloses the destructive reset behavior, the exact return shape, the co-located vs. remote mode difference, concurrency semantics, live execution of steps, and file-edit conflicts. This is far beyond a basic invocation-level description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured and front-loaded with the core purpose. Each block earns its place: return value, mode differences, concurrency, next steps, and file-editing caveats. It is somewhat dense and includes details that could arguably live in flow-add-step's docs, which prevents a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the absence of annotations, and the lack of an output schema, the description is remarkably complete. It covers invocation, return values, failure behavior, environment-specific behavior, concurrency, next steps, and post-recording editing rules. An agent has enough context to call this tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds real semantic value: it explains that name and project_root together key each recording, that names should be unique per task, that executionPrerequisite is for fragments only, and how restart-app relates to launch steps. This meaningfully exceeds the raw schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the exact action: 'Start recording a new flow, resetting .argent/flows/<name>.yaml to an empty flow and replacing any existing one.' It names the resource, the verb, and the side effect, and clearly differentiates this from sibling tools like flow-add-step, flow-finish-recording, and flow-execute by framing it as the entry point for capturing a recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you want to capture a reusable sequence of device interactions for later replay' and gives concrete next-step guidance ('After starting, use flow-add-step...', 'Call flow-finish-recording when done'). It also distinguishes e2e flows from reusable fragments. It does not explicitly list when-not-to-use or name a direct alternative for starting a recording, so it misses the full 'exclusions' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It details the Down/Up event sequence, Chromium CDP behavior, clickCount semantics across platforms, physical iOS reactivation behavior, return values, and failure conditions. This is far more transparent than typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is long, it is dense with necessary operational detail and every sentence adds value. The core action and coordinate system are front-loaded, followed by platform behavior, usage guidance, return values, and failure modes. The length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it covers coordinate interpretation, event semantics, double-tap behavior, platform-specific execution, return payload, failure modes, and how to choose discovery tools. With no output schema or annotations, this level of detail is exactly what an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 4 parameters with descriptions, so baseline is 3. The description adds meaningful semantics beyond the schema: it explains normalized coordinates, clickCount behavior for double-tap/double-click, cross-platform differences, and the guarantee of proper click counting. This raises it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it presses the screen at normalized coordinates and sends a Down/Up event to tap a button, link, or tappable element. It clearly differentiates tap behavior from multi-tap and provides platform-specific semantics, making it distinguishable from sibling gesture tools like gesture-swipe or gesture-custom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('Use when you need to tap a button, link, or any tappable element') and gives strong platform-specific guidance on which discovery tools to use before tapping. It does not explicitly name sibling alternatives like gesture-swipe or gesture-drag, but the usage context is clear enough for an agent to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It thoroughly discloses return contents (flat list of leaf elements, frames, tapPoints, normalized fields, traits, labels) and behavioral quirks (statuses for not-connected apps, restart logic, service_stale requiring tool-server restart, connect_pending meaning do not restart, init_failed requiring simulator reboot, rejection of Apple system apps). This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being long, every sentence adds valuable information. It front-loads the core purpose, then details output, usage context, and error handling in a logical order. No fluff or repetition; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (low-level native inspection with multiple statuses and failure modes) and lacks an output schema. The description fully compensates by explaining return values, usage scenarios, and detailed error recovery steps. It also clarifies the relationship with the describe tool, ensuring complete context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all four parameters have descriptions in the schema (udid, bundleId, skipClasses, skipClassPrefixes) with helpful examples. The description does not add extra parameter semantics beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the running app's native accessibility screen description via injected devtools, and distinguishes it from the sibling 'describe' tool by calling it a low-level native inspection tool with raw point-space geometry. It explicitly mentions the separate public describe contract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when you are evaluating or debugging the lower-level native data behind the public describe tool, or when you need its raw point-space geometry rather than describe's normalized contract.' It also provides detailed status handling instructions (restart_required, service_stale, connect_pending, init_failed) and failure modes (Apple system app rejection), making when-to-use and how-to-handle conditions very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it meets it thoroughly. It explains every returned field, each possible state, the meaning of requiresRestart, terminal non-injectable behavior, and the init_failed alternative return. It also discloses failure conditions such as the simulator server not running and remote simulator limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, return contract, state semantics, then actionable decision rules. It is front-loaded with the core purpose and structured so the agent can quickly locate the branch relevant to its observed state. There is no filler or redundant framing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is effectively a complete operational spec for a two-parameter diagnostic tool. It defines all return fields, enumerates every state and its remedy, distinguishes terminal from recoverable conditions, and documents the failure return. Since there is no output schema, this in-description documentation is essential and fully supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with 100% description coverage: udid is 'Simulator UDID' and bundleId is 'Bundle ID of the app to check.' The description references bundleId and the simulator server context but adds little semantic detail beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether native devtools are connected to a specific app and whether the next launch is prepared for injection.' It clearly names the downstream native tools that depend on this readiness check, so an agent can distinguish it from siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Call this before using app-scoped native hierarchy tools or native-network-logs') and a detailed decision tree covering each state. It also names non-native alternatives like describe and screenshot, and explicitly forbids retrying native feature tools when injectable is false. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the method (wall-clock time alignment), output format (markdown report), and behavior on failure (fails if prerequisites not met). No contradictory annotation exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-organized, and front-loaded with the main purpose. Every sentence contributes value—purpose, method, prerequisites, usage context, output, and failure condition—without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, its prerequisites, its output, and its failure modes. For a tool with only two simple parameters and no output schema, this is complete and sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description adds no parameter-specific meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a cross-correlated report combining React Profiler and native profiler data. It distinguishes itself from siblings by specifically combining both data sources and mapping native hangs to React commits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states prerequisites (both profiler analyze tools must have been called first), when to use it (when both profilers ran in parallel on the same session), and failure conditions. This provides clear guidance on proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It explains platform-specific differences (iOS discrete shake vs. Android accelerometer bursts with orientation restore), how `count` affects sustained motion, the return value, and supported local/remote iOS simulators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action verb and resource, then efficiently covers usage, platform behavior, parameters, return value, and supported targets. Each sentence is informative and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is comprehensive. It explains the gesture's purpose, platform-specific mechanics, `count` behavior, return value, and device compatibility, leaving no critical gap for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage for both parameters. The description reinforces `count` semantics ('Set `count` above 1 when a detector needs sustained motion') and adds context for `udid` by specifying supported simulator types, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Shake the device (iOS simulator or Android emulator).' It clearly distinguishes this from sibling tools like gesture-tap or gesture-swipe by focusing on the shake gesture and its use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use to trigger anything bound to the shake gesture') and gives concrete examples (iOS undo/redo, React Native dev menu, shake-to-report). It also notes platform limitations ('Only phone/tablet simulators and emulators are supported'), though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does so thoroughly. It discloses the silent-failure behavior, the return shape, platform-specific resource cleanup (including TV daemon reaping), what is deliberately left running on iOS/Android/TV, and the Chromium-specific cascade where the CDP session and console history are terminated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although longer than average, every sentence earns its place by covering a distinct aspect: core action, usage trigger, exclusions, platform exception, return value, and failure mode. The information is logically ordered and front-loaded with the primary purpose before caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-platform complexity, no output schema, and no annotations, the description is remarkably complete. It explains what happens per platform, what is preserved, what is destroyed, how to reconnect if needed, what is returned, and how failure behaves. An agent has enough information to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage: the single required `udid` is described as 'Target device id (iOS UDID, Android serial, or Chromium id) whose transport session to stop.' The description adds only the phrase 'given id' and the context that it refers to a specific device, which matches the schema rather than extending it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Stop') and resource ('transport session for a specific device') and immediately disambiguates across iOS, Android, physical iOS, Chromium, and TV. It clearly differentiates from the sibling stop-all-simulator-servers by emphasizing 'specific device' while keeping others running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: use when done with one device but want to keep others alive, or to restart a wedged transport. It also gives an explicit exclusion and alternative—use stop-all-simulator-servers with `devices` to drain native-devtools, accessibility, profiler, and debugger services on iOS/Android/TV.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses side effects like native-devtools injection, registration behavior on physical iPhones, failure when the app is not installed, the no-op behavior on Chromium, and the note about runner signing readiness. It even explains special cases like com.apple.springboard and Spotlight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with the core launch semantics front-loaded and platform-specific details separated into paragraphs. The common bundle id/package name list is lengthy but practical, and every section serves a distinct purpose. It is not perfectly concise, but the detail is justified given the cross-platform complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description discloses the return shape ({ launched, bundleId, note? }), failure modes, installation requirements, platform differences, and side effects. This makes the tool's behavior predictable across iOS, Android, Chromium, tvOS, and Vega, which is a complete picture for an agent selecting and invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 real value by listing common iOS bundle ids and Android package names, explaining Chromium's arbitrary bundleId tag as a no-op, and adding the Vega Fire TV manifestation. It could have also elaborated on the activity parameter, but the schema already covers it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Open an app by its bundle id (iOS) or package name (Android), or confirm the running renderer (Chromium).' It clearly distinguishes the tool from alternatives by naming open-url for changing Chromium routes and positioning this as the preferred way to start apps over launcher icons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use when starting any app.' It also provides platform-specific guidance, including using tv-* tools on tvOS and using open-url for Chromium route changes. This gives clear context and names the relevant alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses several behavioral traits: the tool returns a status field that can be 'restart_required', 'service_stale', 'connect_pending', or 'init_failed', each with a specific recommended action (e.g., restart app, restart server, wait, or re-boot simulator). It also explains that non-connected or non-running apps are returned as statuses rather than failures, and that certain failures (Apple system app rejection) are terminal and should never be retried. This goes beyond a simple description and provides concrete operational guidance, enhancing transparency significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long but well-structured: it starts with the purpose, then differentiates from sibling, provides a use case, and then dives into status handling. While it's verbose, every section serves a purpose—especially the detailed status handling which is critical for correct usage. It front-loads the core purpose and comparison, then provides valuable conditional logic. It's not overly redundant, and the length is justified by the complexity of the tool's response statuses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (handling various statuses, failures, and retry logic), the description is remarkably complete. It covers what the tool does, when to use it, how to interpret different statuses, and what failure scenarios look like. There is no output schema, but the description explicitly states the return structure: { status, count, events } and lists what each event contains (URL, method, status code, headers, and timing). This provides enough information for an agent to fully utilize the tool without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all four parameters (udid, bundleId, clear, limit) with clear descriptions. The tool description does not add much param detail beyond the schema, but it does provide context on how the tool uses them (e.g., 'Clear the log after reading' and 'Maximum number of events'). Given the high schema coverage baseline is 3, the description's mention of limit default of 50 and the status handling provides slight added semantics, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves network requests captured at the NSURLProtocol level, clearly distinguishing it from the JS-level network inspector (view-network-logs). It specifies the resource (network requests), the scope (native-level, all traffic including native modules and background transfers), and explicitly names the sibling alternative, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: when needing to inspect native-level HTTP traffic invisible to JS fetch interception. It also contrasts with an alternative tool (view-network-logs) and gives a clear use case. Additionally, it details action paths for various status values (restart_required, service_stale, connect_pending, init_failed) including when to avoid restating the tool or restart the server, and explains that not-connected or not-running app cases come back as statuses, with separate failure scenarios (system app rejection, missing host dependency, invalid udid). This is comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses auto-detection behavior, return shape ({ status, pid, traceFile }), failure conditions, platform-specific behavior, and detailed trade-offs for malloc_stack_logging including app restart, overhead, Xcode limitations, and environment variable interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place. It is well-structured with platform breakdown, usage flow, return value, failure modes, and parameter-specific caveats, making it dense but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two platforms, four parameters, no output schema, no annotations), the description is remarkably complete. It covers return values, failure conditions, platform differences, and operational workflow, leaving no major gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant value beyond the schema: it explains when to provide app_process (only if auto-detection picks wrong app), that template_path defaults to a bundled Argent template and is ignored on Android, and gives extensive context for malloc_stack_logging including when to leave it off and when the call is rejected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts native profiling on a booted device, with platform-specific details (iOS Instruments via xctrace, Android Perfetto). It distinguishes itself from sibling tools like react-profiler-start and native-profiler-stop by specifying native CPU, hang, and memory capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when you want to capture native CPU, hang, and memory data for a running app' and instructs to call native-profiler-stop after user interaction. It does not explicitly contrast with react-profiler-start, but the native vs. React distinction is implied by tool naming and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden and does so thoroughly. It discloses return shape, null behavior, ancestor/subview defaults, raw coordinate semantics, all special statuses with concrete recovery steps (restart app, restart tool-server, wait), and failure cases such as Apple system apps being rejected outright.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence earns its place: purpose, comparison, use cases, return contract, coordinate warning, and detailed status handling. It is front-loaded with the core purpose and then moves into operational details, though the status block is dense and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex 10-parameter tool with no output schema and no annotations. The description fully compensates by covering return values, coordinate semantics, defaults, status codes, recovery actions, and error boundaries. An agent has enough information to select, invoke, and interpret results correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 real value beyond the schema by explaining that x and y are raw iOS window coordinates NOT normalized [0,1] tap coordinates, and by clarifying default behaviors for ancestors and subviews that affect includeAncestors/includeChildren interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: inspecting the deepest UIView at a raw native window point that would actually receive touch input. It explicitly distinguishes itself from the sibling native-view-at-point by noting it respects userInteractionEnabled and follows UIKit hit-testing semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use guidance: 'Use when a tap lands somewhere unexpected or does nothing' and names the sibling alternative native-view-at-point as a contrast point. It also provides explicit do-not-retry/restart guidance for error statuses, which helps the agent decide whether to invoke or recover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of transparency. It details the output structure, that raw data is saved to disk for later reload via profiler-load, the report's focus on hot commits, and the prerequisite of react-profiler-stop. It also explains the annotations parameter's calculation. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: first sentence states purpose and output, followed by report structure, annotations explanation, prerequisites, and usage flow. At around 180 words, it is concise but could slightly reduce repetition (e.g., offsetMs explanation appears twice). Still, it efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, multiple sibling tools), the description is highly complete. It covers prerequisites, output shape, report structure, failure conditions, workflow after report, and relationship to other tools. The absence of an output schema is compensated by detailing the return fields. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by thoroughly explaining the 'annotations' parameter, including how to compute offsetMs using other tool outputs (tap/swipe and react-profiler-start). For other parameters, it largely repeats schema descriptions but provides helpful context (e.g., linking device_id to debugger-connect). This additional guidance justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze stored profiling data and return a markdown performance report.' It specifies the output fields and report structure, and distinguishes itself from sibling tools by outlining the workflow and mentioning related profiler tools for drill-down, such as profiler-cpu-query and profiler-commit-query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use when the profiling session is complete and you need to interpret the collected data.' It states the prerequisite ('Requires react-profiler-stop to have been called first'), describes the post-report workflow (ask user about further investigation), and explains how to compute the optional annotations parameter. It also mentions failure conditions, offering complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side-effect-free nature, server-side ownership verification, absence of token-threading, return fields, and the taken_over behavior after process restart. This is comprehensive for a status check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise with no redundant information, but slightly dense. Each sentence adds meaningful context. Could be more structured (e.g., bullet points) but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return shape and important states (taken_over). Also clarifies ownership verification and token handling. Fully addresses likely agent questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 value by linking device_id to debugger-connect and noting port's default, but does not elaborate further. Slight improvement over baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Check' and resource 'state of the React profiler session', with the critical qualifier 'without side effects'. Distinguishes from sibling tools like react-profiler-start/stop by focusing on status inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (after interruption) and provides decision guidance: continue with stop, start new session, or reconnect. Even gives a concrete alternative command (react-profiler-start { force: true }) for the taken_over case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: default trimming of static stretches, touch markers, recording lifecycle across calls, return format, and platform limitations. It also clarifies that outputFile is not to be read directly. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but efficient; each sentence serves a purpose. It front-loads the core action and then elaborates on behaviors. Slightly longer than minimal but justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details the return value and its usage. It covers the tool's lifecycle, defaults, and failure scenarios, providing a complete picture for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have schema descriptions (100% coverage), but the description adds practical context beyond the schema: e.g., 'By default every tap... drawn as an on-screen touch marker' for showTouches, and 'Set it to slightly more than the interaction' for timeLimitSeconds. This enhances understanding despite high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Start recording the device screen to a video file' with specific format and resolution details. It distinguishes from the sibling tool 'screenshot' for still frames, making the purpose clear and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit usage advice: 'Use when the user wants a video... for a single still frame use screenshot instead.' Also explains lifecycle (keeps running, set a reminder) and lists failure conditions, providing clear guidance on when to use and what to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and excels. It discloses per-app requirement, platform differences (iOS TCC store vs Android permissions), termination of running app on permission change, return format with applied/skipped fields, and failure conditions. This is comprehensive 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a complex tool, well-structured with a high-level purpose first, then per-platform details, and finally return value. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (applied/skipped). It covers all necessary aspects: actions, parameters, platform specifics, error conditions (e.g., failure if nothing applied). The tool is complex, but the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant value beyond the schema. For action, it explains per-app reset behavior; for bundleId, it clarifies per-app reset; for permission, it provides platform-specific notes (e.g., notifications Android-only, reminders iOS-only). This extra context is critical for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear statement of what the tool does: 'Grant, deny, or reset a runtime permission for an app without navigating the system Settings UI.' It specifies the verb (grant/deny/reset), resource (runtime permission), and clearly distinguishes the tool from siblings, none of which manage permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use during test setup to pre-authorize or deny permissions before the app asks, or to reset the permission dialog. It covers platform-specific behaviors but does not explicitly state when not to use the tool, though it implies limitations (e.g., notifications unsupported on iOS, app must be installed for location).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden—and it delivers. It discloses execution order (launch, tool, tap, swipe, scroll-to, etc.), side effects (iOS pinning, instance teardown, baseline updates), failure semantics (hard-stop, skipped later steps), and the exact structure of the returned report. It even explains edge cases like how selector-less gestures handle unreadable tree sources and how warnings differ from errors. This is exceptional 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the tool is exceptionally complex—8 parameters, many step types, many edge cases. It is front-loaded with the primary use case and then systematically walks through each step kind. Some sentences are densely packed and use nested parentheticals that could be easier to parse, but every sentence adds factual content; there is no filler. For the complexity, this level of detail is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values—and it does: "Returns a structured report ({ flow, device, executionPrerequisite, ok, aborted?, passed, failed, skipped, errored, steps })" plus details on device field semantics. It also covers prerequisites, device selection, chromium-specific behavior, and error conditions. Given the tool's complexity and the absence of an output schema, the description is fully complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, yet the description still adds substantial meaning beyond the schema. It clarifies that device auto-detection only works when exactly one booted device matches, that platform=chromium selects a self-boot branch with fallback rules, that project_root resolves flow files/baselines differently depending on name vs flow_path, and that updateBaselines alters snapshot behavior. These operational details are not fully captured in the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states precisely what the tool does: "Run a saved flow from the .argent/flows/ directory, or an explicit boundary-managed flow_path." It names the resource (flows, YAML) and the action (run), and later distinguishes itself from siblings by saying to use individual gesture tools when nothing is authored and run-sequence for ad-hoc lists. This is a clear, specific description that an agent can act on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool versus alternatives: "Use when a scenario is already authored as YAML and the whole of it should replay in one call... reach for the individual gesture tools when nothing is authored yet, and for run-sequence when the steps are an ad-hoc list rather than a stored flow." It also provides rules for choosing between name and flow_path, and warns about the prerequisiteAcknowledged flow. This leaves no ambiguity about invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does so thoroughly. It discloses the return shape, the empty-result behavior when no prerequisite is declared, the fact that no device is touched, that no simulator/emulator needs booting, that it is just a file read, and that it fails if the file does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and logically ordered, with no filler, but it is somewhat dense and repeats the name/flow_path distinction and the flow location. These repetitions reinforce important constraints, so the slight redundancy costs only one point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description covers all essential context: what is returned, what empty means, what a prerequisite represents, failure behavior, cost/risk profile, and parameter constraints. An agent can decide whether to call it and construct a correct call without needing extra information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description adds critical cross-parameter semantics: name and flow_path are mutually exclusive, supplying both or neither is rejected, name resolves under project_root/.argent/flows/, and flow_path must be supplied through the file-input boundary. This materially improves correct invocation beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Read the execution prerequisite of a flow without running it', and clearly scopes the resource to a saved flow from .argent/flows/ or a boundary-managed flow_path. It also distinguishes itself from siblings by repeatedly stressing that executing the flow is not what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: before committing to a run, to check whether the device is already in the expected state, or to relay a precondition to a human. It ties addressing to flow-execute ('Address the flow exactly as you will address it in flow-execute'), giving the agent a clear alternative and preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the normalized coordinate system, the 1.0 edge-case behavior, the ~60fps interpolation, and the nuanced momentum/deceleration characteristics. It also states the return value and the failure condition when the CDP session is unreachable, leaving little to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the core operation, then covers coordinate semantics, use cases, alternatives, momentum behavior, and return/failure conditions in logical order. There is no filler or repetition that does not add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex gesture tool with no annotations and no output schema, the description is fully complete. It covers coordinate mapping, edge cases, use cases, alternative tools, momentum semantics, the return value, and a failure mode. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, which sets a baseline of 3. The description adds meaningful extra context beyond the schema: the shared coordinate space with gesture-tap and describe, the specific edge case where coordinate 1.0 lands one pixel inside the window, and the interaction between durationMs and momentum:false. While the schema already documents momentum and durationMs in detail, the description's coordinate-space clarifications elevate it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise, actionable definition: 'Press the left mouse button at a start point, move to an end point, and release — a desktop mouse drag in a Chromium app.' It names the exact resource and action, and immediately differentiates from sibling tools like gesture-tap (same coordinate space), gesture-scroll (does not scroll), and gesture-swipe (platform-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use for slider thumbs, drag-and-drop, text selection, or draggable UI elements.' It also gives direct alternatives: 'Dragging never scrolls content on desktop — use gesture-scroll for lists/pages' and 'on iOS/Android use gesture-swipe.' The momentum:false guidance adds a clear condition for a specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden — and it delivers exhaustively. It discloses failure modes and their ordering (text+key rejected before anything is typed; unsupported key rejected up front; un-typeable text partially applied on iOS sim/Chromium but pre-checked on Android/Vega/TV), non-rollback semantics, retry guidance ('read the field's actual contents'), secret resolution behavior (server-side, echoed as placeholder, auto-screenshot skipped), and the reactivated flag on physical iOS.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but nearly every sentence earns its place given the tool's platform matrix, failure semantics, and secrets handling. It is front-loaded with purpose and organized into clear sections (usage, returns/failures, parameter details, TV specifics). It loses one point only because the density of caveats could tax an agent's parsing, and a few points (e.g., repeated 'one call does one action' admonitions) appear in both the prose and the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, multi-platform tool with no output schema and no annotations, the description is remarkably complete. It covers the return shape ({ typed, keys }), all failure modes with retry implications, platform-specific behaviors, the text OR key constraint, and cross-tool coordination with tv-remote and run-sequence. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (baseline 3), the description adds substantial meaning beyond the schema: the secret placeholder mechanism with its full source-resolution order, the per-platform ignored conditions for delayMs, platform-specific key restrictions (TV targets, physical iOS limited to enter/backspace), and the character-set limitation on text. This materially changes how an agent would populate parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource pairing ('Type text or press special keys on the device') and enumerates the exact target surfaces (iOS simulator, Android emulator/device, Chromium app, Vega, TV). It distinguishes itself from sibling tools by naming what it is not — D-pad navigation belongs to remote tools — so an agent can differentiate it from tv-remote and the gesture family without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use when you need to enter text or trigger a named key') and clear exclusions ('On Vega and Apple TV / Android TV, prefer the remote tools for D-pad navigation'), plus a platform-specific rule ('NOT supported on TV targets; move focus with tv-remote instead'). It also instructs when to pair with run-sequence for multi-step actions, giving the agent a complete decision procedure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and delivers extensively: it discloses return shape ({ devices, avds }), platform discriminators, states (running/stopped/connected/paired), headless behavior for additional CoreSimulator devices, silent omission of platforms with unavailable CLIs, and empty-result meaning. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Although long, the description is front-loaded with the core purpose and usage, then organized in clear platform-specific paragraphs. Each sentence adds operational detail (discovery mechanism, state semantics, alternatives) rather than filler, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-platform inventory tool with no output schema or annotations, and the description covers all the context an agent needs: return format, target-id selection, per-platform behaviors, prerequisites, state/ordering semantics, and failure interpretation. It is effectively self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4; there are no parameter semantics to document. The description instead adds meaning to the returned fields (udid/serial/id, kind, state, runtimeKind), which is more relevant than parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a precise verb ('List') with an explicit resource scope: iOS simulators, Android emulators, connected physical Android devices, running Chromium apps, and Vega/Fire TV devices. It also distinguishes the tool from interaction-focused siblings like boot-device and tv-remote by saying it returns target ids to pass to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it at the start of a session to pick a target id and see running targets. It names alternatives and conditions: use boot-device to boot stopped Vega devices and AVDs, no boot-device needed for physical phones, boot-device with electronAppPath for Chromium, and tv-remote/keyboard/describe for TV targets instead of gestures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It explains return shape, each possible status with specific recovery actions, the fact that not-connected/running apps surface as statuses rather than failures, and failure cases such as Apple system app rejection and hierarchy query errors/timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded: purpose, when-to-use, return shape, constraint, then operational statuses. It is long due to complex runtime behaviors, but every sentence adds necessary guidance; the troubleshooting block is justified because there is no output schema or annotations to cover it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 10 parameters, and no output schema, the description is remarkably complete. It specifies the return format, optional ancestors/children, required search criteria, status-specific recovery flows, and terminal failure cases, so an agent has enough context to invoke and recover from failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all parameters with 100% coverage, so the description does not need to repeat them. It adds meaningful cross-parameter semantics by stating that at least one of className, identifier, label, tag, or nativeID is required, which is not encoded in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search for specific UIViews in the running app' and enumerates all search criteria (class name, accessibility identifier, label, tag, or nativeID). It differentiates from the closest sibling by stating 'Much more targeted than native-full-hierarchy.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: 'Use when you need to locate a specific view by its properties without dumping the entire hierarchy.' It also names the alternative native-full-hierarchy and emphasizes the at-least-one search-criterion requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it succeeds. It discloses platform-specific behavior (Chromium renderer navigation, iOS Universal Links vs Android App Links, physical iPhone Safari default), the return shape { opened, url, note? }, and failure conditions when no app is registered or the renderer rejects navigation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but not bloated; every sentence covers an operational distinction. It front-loads the core action and use case, then adds platform caveats, return values, and failure behavior in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is fully self-contained: it covers all parameters implicitly, platform differences, the return object, the note caveat, and failure modes. Nothing an agent needs to invoke this correctly and interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaning beyond the schema by explaining the deep-linking caveat for https URLs and detailing which schemes are valid on each platform, which helps agents choose the right url value and understand when bundleId is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Open a URL or URL scheme on the device.' It clearly distinguishes this tool from launch-app by stating that launch-app is the reliable route for opening installed apps, while open-url handles web pages and deep links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives usage context: navigate to web pages, deep-link into apps, and which schemes are supported per platform. It also names the alternative (launch-app) and tells the agent when to use it instead: 'To reliably open an installed app, use its custom scheme (scheme://path) or launch-app with its bundle id.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so exceptionally well. It discloses that only the device clipboard is affected (host clipboard untouched), that a paste shortcut is triggered, that it returns `{ pasted: true }`, and it lists specific failure conditions (TV target, clipboard failure, missing simulator-server support). It also explains the secret placeholder behavior and that secrets are never echoed back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core behavior, and every sentence earns its place: mechanism, usage boundaries, prerequisites, return value, failure modes, and secret handling. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity. It covers what happens, when to use it, prerequisites, return shape, failure conditions, and security-relevant secret behavior. The absence of an output schema is mitigated because the return value is explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with detailed per-parameter descriptions, so the baseline is 3. The tool description adds organic context beyond the schema: the text parameter's clipboard-vs-host behavior, the same-source relationship with `keyboard` for secrets, and the requirement that the target field have focus. This adds meaningful conceptual value, though the schema already documents the main mechanics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Paste text into the focused field', and explains the mechanism clearly (device clipboard + platform paste shortcut). It explicitly distinguishes itself from the sibling `keyboard` tool, both in purpose and in the user-action model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use `paste` only where a real user would paste, such as 2FA codes, long links/tokens, or testing paste handling. It also gives a clear negative instruction: 'Do NOT use this in place of `keyboard`', and provides a prerequisite step ('Tap the field first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 a crucial sampling behavior (self-times are summed sampling intervals and do not change when widening a window), states that every table shows covered samples and idle fraction, and notes the fatal failure condition. This goes well beyond a generic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and prerequisite, then presents modes in a compact bullet-style list, adds the nuanced sampling explanation, and ends with a usage hint and failure condition. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, no output schema, and no annotations, the description is remarkably complete: it explains modes, parameter roles, return format ('markdown table'), preconditions, and failure behavior. The subtle sampling caveat fills a gap that could mislead users into thinking wider windows increase data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema provides detailed per-parameter descriptions. However, the description adds extra semantic context for key parameters beyond the schema: it explains the meaning of time_window_ms (the clock reference 'same clock profiler-commit-query prints') and connects function_name/component_name to their modes. Slight deduction because not every parameter is explicitly tied to a mode in the description (port, top_n), but the schema covers those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Query') and resource ('Hermes CPU profile data'), enumerates the four modes (top_functions, time_window, call_tree, component_cpu), and explains what each returns. It clearly distinguishes from sibling profiler tools by scoping to CPU ('CPU profile data', 'CPU hotspots') vs the react-profiler-* / native-profiler-* / profiler-commit-query / profiler-stack-query siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use when investigating JS CPU hotspots or correlating CPU cost with specific components') and names the required prerequisite ('Requires react-profiler-stop (and ideally react-profiler-analyze) to have been called first'). It also warns of failure mode if the prerequisite is not met ('Fails if no CPU profile is stored — run react-profiler-stop first').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it delivers extensively. It discloses the return contract ({ summary, diffPath, contextDiffPath }) and the coordinate normalization scheme ([0,1] screen locations matching describe coordinates). It also reveals important behavioral quirks: the fixed top status-bar band is ignored for both pixel and OCR comparisons, and live captures on physical iPhones are device-wide. It explicitly lists failure conditions (invalid sources, unreadable PNGs, unwritable outputDir, unreachable simulator-server/emulator backend), which is exactly the kind of behavioral context an agent needs and that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, and each subsequent sentence adds distinct information: input modes, when to use, live-capture configuration, physical-device caveats, return format, ignored band, and failure conditions. It is dense but earned; every sentence carries a different fact. It loses a point only because it is longer than strictly necessary, and a couple of details appear twice in slightly different forms (the exactly-one live-capture rule appears in the body and again in the schema descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter comparison tool with no output schema and no annotations, this description is remarkably complete. It covers all input modes, the return value shape, coordinate conventions, the ignored status-bar band, device-specific behaviors, and failure modes. There is no obvious category of information an agent would need to invoke this tool correctly that is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter coverage, so the baseline for this dimension is 3. The description adds significant semantics above that baseline: it explains the pipeline rule (exactly one of captureBaseline or captureCurrent; the common flow is baselinePath + captureCurrent), clarifies the role of outputDir (defaults to temp directory, artifacts still returned), and gives the physical-iPhone caveat that rotation is ignored. It also ties udid to backend resolution ('Always provide udid so the capture backend can be resolved'). These are real additions beyond the schema field comments, not repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object pair ('Compare two PNG screenshots') and identifies the tool as a visual-diff operation distinct from the many sibling tools. It explicitly enumerates what the comparison covers (layout, spacing, color, typography, rendering, clipping, overflow, text rendering), so an agent can clearly distinguish this from screenshot or other capture tools. The sibling list contains many capture/gesture tools, but this one is unambiguously the diffing/comparison tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does 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 when stable before/after screenshots exist and the expected result is pixel-visible'), and provides concrete guidance on how to configure live captures ('set exactly one of captureBaseline or captureCurrent; use baselinePath + captureCurrent for the common visual-regression flow'). It also gives device-specific guidance (physical iPhones need no registered app, keep baselines per device model) and documents a key limitation (different aspect ratios fail). This is among the most usage-rich descriptions possible for a tool with no separate usage-hints annotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains coordination normalization, delay defaults, interpolate behavior, return values, platform-specific limitations on physical iOS, and failure conditions. This is exemplary transparency for a gesture automation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: purpose, alternatives, key parameter semantics, physical iOS caveats, return values, failure modes, and four illustrative examples. It is front-loaded with the most important routing information and organized so an agent can quickly understand when to use it and how to construct events.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description thoroughly explains what the tool returns, when it fails, and how platform differences affect behavior. The examples cover the main complex gesture types and the interpolate option, making the tool's expected invocation and results fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema already documents all parameters, the description adds substantial semantic meaning beyond that. It explains how to compose event sequences for long-press, drag, smooth scroll, and pinch, gives concrete examples, and clarifies the meaning of delayMs and interpolate in the context of real gestures. This goes well beyond the baseline schema-provided information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: sending a sequence of touch events for complex gestures. It further distinguishes itself from siblings by naming specific use cases like long press, drag-and-drop, custom scroll, and two-finger pinch, while also calling out simpler alternatives. This makes the tool's purpose unambiguous and easy to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use for: long press, drag-and-drop, custom scroll, pinch' and then explicitly routes simple taps to gesture-tap, straight-line scrolling to gesture-swipe, standard pinch to gesture-pinch, and rotation to gesture-rotate. It also provides physical iOS-specific constraints and failure conditions, leaving little room for incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full weight. It discloses normalized coordinates, auto-generated ~60fps interpolation, return value structure, failure conditions, radius override behavior, and rejection criteria for partially specified radiusX/radiusY. It even explains the physical ellipse vs. circle nuance—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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence adds value. It opens with purpose, then covers normalization, direction, typical values, parameter relationships, and failure modes. Structured logically with each paragraph addressing a key aspect. Despite length, it is tightly packed and front-loaded, with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex gesture with 9 parameters and no output schema, the description covers all necessary aspects: physical interpretation of radius, angle semantics, coordinate space, failure rejection, return value, and frame rate. It fully compensates for the lack of annotations and enriches the schema. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema. It explains the coordinate space (normalized fractions), gives typical values (radius 0.15, startAngle 0, endAngle 90), clarifies that endAngle > startAngle is clockwise, and details how radiusX/radiusY interact with radius and override it. This aids correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Send a two-finger circular arc gesture to rotate on-screen content by a specified angle.' It specifies the verb (send/gesture), resource (on-screen content), and scope (rotate by angle). It also distinguishes from sibling gesture-pinch by noting it 'orbits fingers in an arc to change orientation' vs. linear zoom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use when you need to rotate a map, image picker, or any rotateable UI element.' It directly differentiates from gesture-pinch and notes the coordinate space shared with gesture-tap and gesture-swipe. Failure conditions are also mentioned (backend unreachable), giving clear guidance on when it may not work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, and it does so thoroughly. It warns about extremely large output (100KB–500KB+), lists statuses (restart_required, service_stale, connect_pending, init_failed) with exact recovery actions, and clarifies that non-connected apps return statuses rather than failures. This goes far beyond the schema's static parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, every section earns its place: warning first, then alternatives, parameter tuning advice, and careful status handling. The structure is front-loaded with the most critical information, and the status guidance is exhaustive enough to prevent dangerous retry loops.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is remarkably complete. It covers expected return shape, failure modes, status-value semantics, terminal cases, and advice about scaling output. An agent can invoke this tool correctly and know what to do after almost every possible result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful guidance on top: skipClasses/skipClassPrefixes examples, a concrete SwiftUI prefix value, a warning against broad prefixes like '_UI', a default for maxDepth, and a recommendation to use the fields parameter to limit output. This materially helps an agent pick and fill the right parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: 'Get the complete UIKit view tree for the running app.' It also distinguishes itself from the sibling tool by saying 'Prefer native-find-views for targeted queries' and notes when this tool is useful (deep layout debugging, accessibility label checks). This is unambiguous and avoids confusion with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus native-find-views and gives concrete use cases: 'deep layout debugging, finding views with no accessibility labels, or verifying view structure not exposed through the accessibility tree.' It also explains when not to retry, including terminal conditions for Apple system apps and specific instructions for each status code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses stop-on-first-error behavior, partial results, the automatic single screenshot after the sequence, the secret-suppression interaction with that screenshot, physical iOS step restrictions, and the platform compatibility matrix. This is extensive behavioral disclosure well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but every section earns its place: summary, usage guidance, per-tool argument matrix, platform tags, examples, and failure semantics. It is front-loaded with the core purpose and usage rule before the detailed tool matrix, and the examples are compact and targeted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description states the return shape ({ completed, total, steps }), error behavior, screenshot behavior, secret handling, and per-step tool contracts. For a complex multi-step orchestration tool, this is a complete and self-sufficient definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning: a complete allowed-tools and args reference, the note that udid is auto-injected and must not appear in args, keyboard text/key exclusivity, TV-specific restrictions, and concrete examples for common sequences. It greatly exceeds what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Execute multiple device interaction steps in a single call' across a defined set of platforms. It clearly distinguishes from sibling individual gesture/keyboard tools by positioning itself as the batched sequential alternative, and even names the key constraint that differentiates it: you do not need to observe the screen between steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Use when you need sequential actions and do NOT need to observe the screen between them.' It also gives an explicit when-not-to-use rule: 'ONLY use this when every step is known in advance. If any step depends on the result of a previous one... use individual tool calls instead.' Platform-specific limitations for physical iOS devices are also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 thoroughly discloses destructive scope (spawned processes, sockets, ports), cross-agent side effects (unscoped call tears down other agents' devices), and return-field semantics (stopped, unmatched, left_running, aborted). It even notes the call always succeeds and reaping nothing is a result, not failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, the description is dense and front-loaded with the action and scope; every sentence addresses a distinct concern (what is stopped, when to use, scoping pitfalls, return value interpretation). The length is justified by the tool's complexity and high-stakes destructive behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides a full account of the return object and its edge cases. It also covers safety warnings and scoping restrictions, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one documented `devices` parameter, but the description adds substantial meaning: omit vs empty array distinction, logicalDeviceId alongside device id, duplicate handling, and unmatched semantics. This goes far beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Stop the services a device owns' and enumerates a specific list (simulator-server processes, native devtools, iOS accessibility service, TV-control daemons, Chromium CDP sessions, screen recordings, profilers, debugger sessions), clearly distinguishing it from a generic stop. It also differentiates device-scoped from machine-wide cleanup, separating it from the sibling stop-simulator-server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this when your session ends or the user says they are done.' It also tells when to omit devices ('only when a machine-wide cleanup is what you actually want') and warns against empty-array misuse. This is explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/software-mansion/argent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server