Argent
OfficialServer Quality Checklist
Latest release: v0.20.0
- Disambiguation4/5
Most tools have clear distinct purposes, but some overlap exists between gesture tools (tap, swipe, scroll, drag, pinch, rotate) and describe tools (describe, native-describe-screen, debugger-component-tree, native-full-hierarchy). However, detailed descriptions help agents differentiate them.
Naming Consistency3/5Naming uses hyphens consistently, but mixes verb-first (e.g., boot-device, dismiss-update) and noun-first patterns (e.g., chromium-cookies, gesture-tap). Within domain groups (e.g., debugger-*, native-*, gesture-*, profiler-*) it is consistent, but overall pattern is mixed.
Tool Count4/570 tools is high but justified by the broad scope: device management, UI interaction, debugging, profiling, network, flow recording, etc. Each tool serves a specific need, though some consolidation could be possible.
Completeness5/5The tool surface covers the full lifecycle of mobile app testing: device booting, app installation/launch, UI inspection, interaction (taps, gestures, keyboard), debugging (profiling, network, logs), screenshot diffing, and flow recording. No obvious gaps for the stated purpose.
Average 4.5/5 across 68 of 70 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 30 of 38 community issues answered or closed in the last 6 months
- No commit activity data available
- 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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses failure conditions (stop not called, no data) and return type (markdown table or tree). No annotations provided, so description carries full burden. Does not address side effects, auth, or rate limits, but as a query tool these may be minimal.
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?
Concise with logical flow: purpose, prerequisites, modes, usage note, return type, failure condition. No superfluous sentences; front-loaded with core 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?
Covers prerequisites, failure conditions, return type, and mode descriptions. Without output schema, the description adequately outlines what to expect. Lacks some details on parameter interactions but schema fills gaps.
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?
All seven parameters are described in the schema (100% coverage). The description adds high-level mode explanations but adds little beyond schema details for individual parameters, staying at baseline for full coverage.
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 queries React commit data for render performance investigation, listing four specific modes with brief descriptions. Differentiates from sibling profiler tools by mentioning its use after react-profiler-analyze, though not exhaustively.
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?
Explicitly requires react-profiler-stop to have been called and warns of failure if not. Advises using after react-profiler-analyze. Lacks explicit exclusion of other modes or alternatives among the many sibling profiler 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?
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.
- 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: iOS sends Down then Up, Android injects adb keyevent, return value, and failure condition when backend unreachable. 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 concise (approx. 80 words), front-loaded with the main action, and well-structured with platform info, supported buttons, usage, return, and error. Slight redundancy in mentioning return 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 simple tool with 2 parameters and no output schema, the description covers all necessary context: purpose, platform differences, supported buttons, usage guidance, return format, and error conditions. No gaps.
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 the description does not add significant meaning beyond what is already in the schema. The button enum is listed in both, and udid description is same. 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?
The description clearly states the tool's purpose: to press a device hardware button on iOS simulator, Android emulator or device. It distinguishes from sibling tools by focusing on hardware buttons and mentioning platform-specific differences.
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 you need to trigger hardware button events.' It also lists supported buttons and notes that unsupported buttons are rejected with a clear error. Does not explicitly state when not to use, but implies 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 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.
- 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 and does well: it discloses non-destructive behavior for other recordings ('leaving recordings under any other key untouched'), the return value structure, the failure condition, and that the YAML can be edited afterwards. It could have clarified whether the in-progress recording state is removed, but it says 'finalize' which implies completion.
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 three sentences, each earning its place: purpose, return value, usage condition, failure case, and post-editing note. It is front-loaded with the main action and contains no redundant wording or 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?
The tool is part of a recording workflow (siblings include flow-start-recording and flow-add-step). The description covers the finalization step well, including return fields, failure mode, and follow-up action. Without an output schema, it lists the return fields but doesn't explain each; however, the complexity is low enough that this is sufficient.
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 clear descriptions for both parameters. The description adds a bit by reiterating that the parameters must match those passed to flow-start-recording and that together they identify the recording. However, this largely echoes the schema, so the added value is marginal; 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 a specific verb ('Finish recording') with a specific resource ('flow named by `name` + `project_root`'). It distinguishes from sibling tools like flow-start-recording and flow-add-step by focusing on finalization, and notes it leaves other recordings untouched, making the scope explicit.
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 have added all desired steps and want to finalize the flow file.' It also notes the failure condition ('Fails if that flow has no recording in progress') and post-usage option (edit YAML afterwards). No explicit alternatives are mentioned, but the workflow 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 provided, the description fully carries the burden of behavioral disclosure. It explains that the tool maps native hangs to React commits using wall-clock time alignment, returns a markdown report correlating hangs with React commits and memory leaks, and fails if prerequisites are not met. This is adequate, though it could mention if the tool has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only 5 sentences. Each sentence serves a purpose: stating the output, explaining the mechanism, listing prerequisites, usage context, and failure condition. No unnecessary 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?
For a tool that combines two profilers and returns a report, the description covers what it does, how it works, prerequisites, when to use, and failure condition. It lacks details on the report format beyond 'markdown', but given no output schema, this is sufficient. Minor gap: does not explain the role of the port parameter in the correlation.
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 covers 100% of parameters with descriptions, so the description does not add extra meaning beyond what the schema already provides. Both port and device_id are documented in the schema, and the description does not elaborate on them further.
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 generates a cross-correlated report combining React Profiler and native profiler data. This distinguishes it from sibling tools like react-profiler-analyze and native-profiler-analyze, which are individual analyses.
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 to call this tool when both profilers were run in parallel on the same session, and it requires both react-profiler-analyze and native-profiler-analyze to have been called first. While it doesn't explicitly state when not to use it, the prerequisites and usage context are 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?
Since no annotations are provided, the description carries full burden. It discloses that the tool returns a markdown table, fails if no profile is stored, and describes each mode's behavior. It implies read-only access by being a query tool. However, it does not mention potential side effects, rate limits, or auth requirements, but these are not critical for a CPU query 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 appropriately sized and front-loaded with the purpose. It has a clear structure: introduction, prerequisites, mode list with explanations, usage guidance, and failure condition. Every sentence adds value, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions returns a markdown table but does not detail the format for each mode. It does not clarify how top_n applies to non-top_functions modes. The time_window_ms object is described in schema but not elaborated in description. For 8 parameters and multiple modes, the description is adequate but leaves some behavioral details implicit.
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 with modes (e.g., function_name for call_tree, component_name for component_cpu) and explaining the time_window_ms nested object context. It provides usage context that the schema alone does not, such as the effect of include_callers in call_tree mode.
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 queries Hermes CPU profile data with targeted modes for iterative investigation. It lists four specific modes (top_functions, time_window, call_tree, component_cpu) with their purposes, making the tool's function and scope immediately clear. It distinguishes itself from sibling tools like profiler-commit-query and profiler-stack-query by focusing on CPU profiling.
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 prerequisites: 'Requires react-profiler-stop (and ideally react-profiler-analyze) to have been called first' and 'Fails if no CPU profile is stored — run react-profiler-stop first'. It also indicates when to use the tool: 'Use when investigating JS CPU hotspots or correlating CPU cost with specific components.' While it does not explicitly list when not to use it versus alternatives, the mode descriptions provide sufficient 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?
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, the description correctly carries the burden of behavioral disclosure. It discloses that the operation does not execute the flow (read-only), returns a prerequisite description, and fails if the flow file does not exist. However, it does not detail the return format beyond 'description' or mention any auth/permission requirements, which might be relevant for a tool reading from the filesystem.
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 four sentences but each provides necessary context: the core function, return value, usage guidance, and failure condition. It is front-loaded with the verb+resource and does not include filler. Slightly longer than the minimal ideal but still efficient.
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 absence of an output schema, the description explains what is returned (a prerequisite description) and a key error condition. It also addresses the parameter relationship with flow-execute. However, it leaves some ambiguity around the 'boundary-managed flow_path' concept and does not elaborate on the structure of the returned prerequisite description. For a simple read tool with detailed schemas, this is close to complete.
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 semantic value by explicitly connecting name/flow_path to the flow-execute invocation: 'pass the same flow source (name or flow_path) you will pass to flow-execute.' It also clarifies that flow_path is 'boundary-managed,' hinting at the file-input boundary distinction. This goes beyond the schema's per-parameter 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 opens with 'Read the execution prerequisite of a flow without running it,' clearly specifying the verb (read) and resource (execution prerequisite of a flow). It distinguishes from sibling flow-execute by explicitly stating it does not run the flow, and explains the two valid sources (saved flow or flow_path).
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 it: 'Use when you need to check what app/simulator state is required before executing a flow.' It also gives a concrete recommendation to pass the same flow source as flow-execute to ensure the prerequisite read matches the flow that will run. It does not explicitly mention alternatives or when-not-to-use, but the 'without running it' contrast with flow-execute provides implicit exclusion.
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 details disk-to-memory loading, caching behavior, failure conditions (missing session_id/XML files), and special handling for Android .pftrace. It does not mention side effects like overwriting existing loaded data.
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 mode breakdown. It is slightly verbose but information-dense. 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 5 parameters, no output schema, and many sibling profiling tools, the description covers the lifecycle and prerequisites well. It lacks details on the return format of the summary.
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%. The description adds context beyond schema: required modes for session_id, caching under port+device key, and app_process for older sessions.
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 (fetch/restore), resource (profiling session), and outcome (into memory for query tools). It distinguishes itself from sibling tools like capture (react-profiler-stop) and query tools (profiler-cpu-query).
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 ('revisit past session data without capturing a new recording') and describes the three modes. It references sibling tools as counterparts but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, description fully covers traits: auto-detection of app process, fail conditions, workflow steps, and detailed trade-offs for malloc_stack_logging (cold launch, overhead, Xcode restrictions). 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?
Well-structured with clear paragraphs for each platform. Every sentence adds value, but the long paragraph for malloc_stack_logging could be slightly trimmed. Front-loaded with core purpose.
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 4 parameters and no output schema, the description covers purpose, usage, behavior, failure conditions, and return value shape ({ status, pid, traceFile }). All essential aspects are addressed.
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 highly detailed descriptions for each parameter. The main description adds minimal extra param context beyond summarizing auto-detection, which is already in schema. Baseline 3 is correct.
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, specifies iOS/Android methods (Instruments/Perfetto), and captures CPU, hangs, memory. It distinguishes itself from siblings like native-profiler-stop and native-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?
Explicitly states when to use: 'Use when you want to capture native CPU, hang, and memory data for a running app.' Provides workflow instruction to call native-profiler-stop after user interaction. However, no direct comparison to sibling profiler tools (e.g., react-profiler-start) is given.
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 disclosing behavioral traits. It discloses that the tool respects userInteractionEnabled, uses UIKit hit-testing, uses raw window coordinates, and may return restart_required status. It does not cover edge cases like no view found or performance implications, but it is reasonably transparent for a non-mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences plus an imperative note about restart. The first sentence states the purpose, the second differentiates from a sibling, the third clarifies coordinate semantics, and the note handles an error case. No filler, each sentence earns its place.
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 has 10 parameters, no output schema, and no annotations, the description covers the most critical aspects: differentiation from sibling, coordinate system, and error recovery. However, it does not explain what the return value contains (no output schema) and doesn't add context for optional parameters like fields or skipClasses beyond what the schema provides. Still, it is reasonably complete for its complexity.
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 only adds context for x and y parameters (raw window coordinates), but the schema already describes them similarly. Other parameters like fields, skipClasses, etc., are not elaborated beyond their schema definitions. No significant added 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 clearly states the tool inspects the deepest UIView at a raw native window point that would actually receive touch input. It distinguishes itself from 'native-view-at-point' by explicitly mentioning that it respects userInteractionEnabled and uses UIKit hit-testing semantics, which differentiates it 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?
The description provides explicit guidance on when to use this tool versus 'native-view-at-point' (when respecting userInteractionEnabled and UIKit hit-testing). It also warns about the coordinate system being raw iOS window points, not normalized, and instructs to call restart-app if status is restart_required. This covers both selection criteria and error handling.
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 behavioral burden. It discloses prerequisites, failure conditions (if analyze not run or no trace data), and return type (markdown report). It does not mention idempotency or permissions, but covers key aspects adequately.
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 logically structured: purpose, prerequisites, modes, usage, return, failure. It is concise and front-loaded with the main action. Minor improvement could be bullet-pointing modes for readability.
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 type (markdown report with call stacks, weights, or leak details). It covers prerequisites and failure conditions. It is complete for the tool's complexity, though more detail on output format could be added.
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 for all parameters. The description adds value beyond the schema, e.g., for the 'thread' parameter it advises running thread_breakdown first to see exact names. Each mode is explained in detail.
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 'Query native profiler trace data' for iterative investigation, with specific modes (hang_stacks, function_callers, etc.). It distinguishes itself from sibling tools like native-profiler-analyze by focusing on post-analysis queries.
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 calls (native-profiler-stop → native-profiler-analyze) and when to use ('drilling into native hang stacks...'). Provides good context for usage, though it could be more explicit about scenarios where the tool should not be used.
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?
With no annotations, description bears full burden. Discloses return format (image object with MCP rendering), includes details on Chromium scaling and optional dependencies, and describes failure modes. Could add more depth on image encoding but 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?
Highly concise: three sentences cover core purpose, usage, return value, and failure condition. No wasted words, front-loaded with key action.
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 5-parameter tool with no output schema, description explains return shape and rendering, mentions environment variables, and covers failure cases. Could clarify image format (e.g., PNG base64) but is generally complete.
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 description adds value beyond schema by explaining default scale behavior (env var fallback), Chromium-specific downscaler algorithm, and the purpose of includeImageInContext. This extra context aids correct parameter 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?
Description clearly states 'Capture a screenshot of the device screen' and lists supported device types (iOS simulator, Android emulator, Apple TV simulator, Vega, Chromium app). It is unambiguous and distinguishes from sibling tools, none of which duplicate this function.
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 when-to-use guidance: 'when you need a baseline image before an interaction or to inspect the current screen state after a delay.' Also mentions failure condition when backend unreachable. Lacks explicit when-not-to-use, but the tool is straightforward.
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 fully covers behavioral traits: it ignores the status-bar band, explains failure conditions (invalid inputs, unreachable backend), and describes return values with coordinate normalization. This adds significant transparency beyond the bare schema.
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 well-structured paragraph that front-loads the main purpose in the first sentence. It covers all key aspects without excessive verbosity, though some bullet points could improve readability for complex parameter logic.
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 7 parameters, no output schema, and high complexity, the description is remarkably complete: it explains input modes, status-bar exclusion, failure conditions, output structure (summary, diffPath, contextDiffPath), and coordinate system normalization. No critical 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?
All 7 parameters have schema descriptions (100% coverage), but the description adds valuable context: the mutual exclusivity of captureBaseline/captureCurrent, the optional nature of outputDir, and the typical usage pattern (baselinePath + captureCurrent). This aids correct parameter combination.
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 'Compare two PNG screenshots and return a compact visual-diff summary' with specific verb, resource, and output. It further elaborates on use cases like layout, spacing, color, etc., which distinguishes it from sibling tools like 'screenshot' that only capture images.
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 on when to use ('Use when stable before/after screenshots exist...') and how to configure parameters for baseline/current paths or live captures. It offers a recommended workflow ('use baselinePath + captureCurrent for the common visual-regression flow') but does not explicitly list alternative tools to avoid.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool injects native devtools, explains the return format in detail, and describes an error condition. However, it lacks information about potential side effects, authentication needs, or other failure modes like app not running.
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 with a clear opening sentence, a list of return fields, context about its purpose, and a usage hint. Every sentence adds value, and it is front-loaded with the main action. There is 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?
Given the moderate complexity (4 parameters, no output schema), the description explains the return values comprehensively, provides error handling guidance, and contextualizes the tool's role relative to the public describe tool. It covers all essential aspects for effective use.
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 description adds value by explaining the usage of skipClasses and skipClassPrefixes with examples, which goes beyond the schema descriptions. For udid and bundleId, the description does not add much, but overall the parameter semantics are well covered.
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 reads the native accessibility screen description and specifies the return format. It distinguishes from the sibling 'describe' tool by noting that the public describe contract is separate, making the purpose specific 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool (debugging lower-level native data) and includes an error handling hint (restart_required -> restart-app). However, it does not explicitly compare to alternatives like 'describe' or 'native-find-views', nor does it state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds behavioral context: captures ALL network traffic, returns specific shapes, and describes failure modes ('restart_required', devtools not connected). Adequate transparency for a read 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?
Five concise sentences, front-loaded with purpose, clearly structured with 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?
The description covers all necessary aspects: purpose, differentiation, usage context, return format, failure states, and follow-up actions. No output schema but return format is described in detail.
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, so baseline 3. Description does not add significant parameter semantics beyond the schema, but the schema already clearly defines 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 it retrieves network requests at the native NSURLProtocol level, distinguishing it from the JS-level 'view-network-logs' sibling. The verb 'Retrieve' and resource 'network requests' 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'to inspect native-level HTTP traffic that is invisible to JS fetch interception'. Also provides guidance on failure handling: call 'restart-app' if 'restart_required' is returned.
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?
No annotations provided, so the description fully handles transparency. It discloses wait-until-ready behavior, hot-boot fallback, boot time ranges (Android 2-10 min, Vega ~10s), and termination on failure for clean retries. This is comprehensive for a boot 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 with separate paragraphs for key behaviors, but it is somewhat verbose. Every sentence adds value, though a few could be tightened. Overall efficient for 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 9 parameters, no output schema, and no annotations, the description covers all necessary aspects: purpose, parameter selection, platform-specific details, timing, and return payload format. It is fully self-contained 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 mutual exclusivity clarification, default boot timeouts, headless behavior for iOS, and Electron-specific details (args, port). This adds meaningful context 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?
The description clearly states the tool starts an iOS simulator, Android emulator, Vega virtual device, or Electron app and waits until ready. It lists each platform and the corresponding argument, distinguishing this boot operation from sibling tools that perform other 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?
The description explicitly says 'Use at the start of a session once you have picked a target.' It also explains which parameter to use for each platform and notes Android's hot-boot behavior. While it doesn't state when not to use it, 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.
- 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, the description carries the full safety/behavior burden and does so richly: it discloses that gesture-tap may be rewritten to a portable selector (with a warning when coordinates are kept), that restart-app becomes a launch step with a chromium limitation, that failures record nothing, and that in-memory state is authoritative on remote clients. This provides significant context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, with the purpose and use-case in the first sentence and each subsequent sentence addressing a distinct operational issue (portability, launch-step handling, return value, edit/recovery). A few details could be tightened, but no sentence is purely 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?
This is a complex mutation tool with no output schema, yet the description covers the return shape (`{ message, toolResult, stepCount, recorded, savedTo }`), failure atomicity, recording prerequisite, YAML editing rules, and special command transformations. The only minor gap is not explaining each return field, but the key structure is 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?
Schema coverage is 100%, so the baseline is 3; the description adds extra meaning by explaining that name + project_root jointly identify the open recording and by giving command-specific behavior (gesture-tap/restart-app). It does not need to restate arg/delayMs semantics, which the schema already documents.
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 specific action ('Execute a tool call and record it as a step') with explicit scope (`flow named by name + project_root`). This clearly distinguishes the tool from sibling flow tools like flow-start-recording and flow-finish-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 includes an explicit usage directive ('Use when recording a flow and you want to run and capture each action') plus a prerequisite pointer ('recording must already be open — see flow-start-recording'). It also gives conditional guidance (record a restart-app launch FIRST; chromium fragment caveat), but it does not explicitly contrast with flow-add-echo or name 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 this description carries full burden—and it delivers. It discloses hard-stop failure semantics ('Every step hard-stops the flow on failure'), device lifecycle behavior (kills/retires owned instances, tears down at run end), idle's never-fail warning behavior, and prerequisite notice behavior. This goes far beyond a basic read/write characterization.
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 and dense, but the tool is complex and the text is organized by step type with a clear front-loaded opener. Some repetition and a very long selector parenthetical make it less crisp than ideal, but each major behavior earns its place. Score 4.
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, but the description explicitly enumerates the structured return report and prerequisite behavior. It also covers run semantics, device selection, chromium edge cases, and failure/skipping. For a tool of this complexity, this is comprehensive.
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, and the description adds contextual parameters: it explains device auto-detection failure with multiple booted devices, the chromium self-boot branch vs fallback, and flow_path co-location rules. It reinforces schema descriptions without repeating them verbatim. This additional context 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 opening sentence states a specific action: 'Run a saved flow from the .argent/flows/ directory, or an explicit boundary-managed flow_path.' This clearly identifies both the operation and the resource, and the focus on execution distinguishes it from sibling recording/utility flow tools. The rest of the description elaborates on execution semantics but the purpose is immediately 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 gives substantial context: when a flow is self-contained vs runs against current state, how device/platform selection works, and prerequisite acknowledgment. It even notes step-level alternatives like the rotate gesture vs the rotate tool. However, it never explicitly compares flow-execute to sibling tools like run-sequence or the gesture/tap tools, so exclusion guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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?
With no annotations, the description fully carries the burden of behavioral disclosure. It explains the mechanics (two fingers, radius, angles), normalized coordinates, ellipse vs. circle for non-square screens, auto-generated ~60fps frames, return value, and failure condition. It could mention prerequisites like device boot status, but the failure condition partially covers that.
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, starting with purpose then details. It is somewhat long but every sentence adds value, including usage guidelines and behavioral details. It could be slightly more concise, but it's 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 complexity of a multi-parameter gesture tool with no output schema, the description is remarkably complete: it covers coordinate space, angle semantics, radius handling, elliptical distortion, comparison to sibling, typical usage, return value, and failure mode. No gaps are evident.
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 extra meaning: explains coordinate system (normalized 0-1), rotation direction (endAngle > startAngle = clockwise), typical values (radius 0.15, startAngle 0, endAngle 90), and the trade-off between radius and radiusX+radiusY for non-square screens.
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, specific verb+resource: 'Send a two-finger circular arc gesture to rotate on-screen content by a specified angle.' It explicitly distinguishes the tool from gesture-pinch, which is present in sibling tools, by noting that pinch moves fingers linearly while rotate orbits fingers.
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 you need to rotate a map, image picker, or any rotateable UI element.' It also contrasts with gesture-pinch, providing clear alternative guidance.
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 provided, the description fully discloses behavioral traits. It explains each return field (envSetup, appRunning, connected, etc.) and their meanings, including edge cases like non-injectable apps (Apple system apps) and failure states (init_failed with attempts). It also describes required preconditions (simulator server running) and consequences of different statuses.
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 verbose but well-structured. It is front-loaded with the core purpose, then provides detailed behavioral guidance and conditional logic. Every sentence adds value, though some redundancy could be trimmed. Still highly 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?
The description is complete given no output schema and full parameter documentation. It covers all possible states (injectable, appRunning, requiresRestart), return field semantics, failure modes, and explicit guidance for each state. It also references sibling tools 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% (both parameters have descriptions: udid as 'Simulator UDID' and bundleId as 'Bundle ID of the app to check'). The description does not add additional semantics beyond what the schema already provides. 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's purpose: 'Check whether native devtools are connected to a specific app and whether the next launch is prepared for injection.' It specifies the resource (app) and action (check status), and distinguishes from sibling tools by mentioning dependent tools like native-full-hierarchy, native-describe-screen, and native-network-logs.
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 when-to-use guidance: 'Call this before using app-scoped native hierarchy tools or native-network-logs.' It also details conditional actions (e.g., if injectable is false, use standard describe or screenshot; if requiresRestart, call restart-app) and warns against using native-devtools feature tools when injection is not possible.
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 fully covers behavioral traits: large output warning, failure conditions (devtools not connected, app not running), pruning via skipClassPrefixes, and return statuses. Minor omission of detailed response structure for 'windows'.
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?
Six sentences with no redundancy: purpose, warning, pruning advice, use cases, return info, failure conditions. Front-loaded with purpose, each sentence essential.
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 6 params, no output schema, and complexity, the description covers purpose, warnings, use cases, failures, and return status. Lacks explicit structure of 'windows' but overall adequate. No output schema reduces burden.
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%, baseline 3. Description adds value by explaining how to use skipClassPrefixes for SwiftUI, fields defaults, and maxDepth for output control—beyond schema definitions.
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 obtains the complete UIKit view tree using the verb 'Get' and specifies the resource. It distinguishes itself from sibling tool native-find-views by mentioning it is for targeted queries.
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 (deep layout debugging, finding unlabeled views) and when not to (prefer native-find-views for targeted queries). Provides constraints like large output and pruning strategies, covering both context and 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 provided, the description fully discloses behavior: it parses trace files, returns a structured markdown report with severity indicators, tables, and suggestions. It also explains the post-report interaction flow and failure condition (missing native-profiler-stop). 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: it opens with the main purpose, then details per platform, return format, usage instructions, prerequisite, and failure condition. Every sentence adds value, and it is front-loaded with the core function.
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 tool with one parameter and no output schema, the description covers functionality, platforms, return type, usage flow, prerequisite, and failure condition. It is complete enough for an agent to use correctly, though minor details like timeouts or size limits are absent.
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 for the single parameter device_id with a clear description. The tool description adds no further parameter details, but the baseline is appropriate given schema completeness. The description's value comes from usage context, not parameter elaboration.
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 analyzes exported native trace data and returns an LLM-optimized markdown report. It distinguishes from siblings by detailing platform-specific behaviors (iOS XML vs Android Perfetto) and mentions follow-up tools like profiler-stack-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 explicitly instructs to call native-profiler-stop first to export trace data, states the tool fails otherwise, and advises using it when needing to interpret a completed recording. It also guides the agent to ask the user about next steps (drill-down or fixes).
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 fully discloses key behavioral traits: coordinate system (raw iOS points, not normalized), the distinction from touch-interactive queries, and the restart_required status condition. It does not explicitly state that the operation is read-only or non-destructive, but that is implied by 'inspect'. Slightly more detail on side effects could push to 5.
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 extremely concise: 5 sentences, no wasted words. It front-loads the core purpose, then adds contrast, important caveats, and recovery instructions in a logical order. Every sentence earns its place.
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 10 parameters, 4 required, no output schema, and no annotations, the description covers the tool's primary distinction, coordinate system, and error handling. It does not describe the output structure, but the schema with fields parameter implicitly defines return content. A minor gap is not explaining parameters like maxDepth or skipClasses, but these are well-documented in the schema. Overall adequate for effective use.
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 by emphasizing the critical coordinate distinction for x and y: 'raw iOS window coordinates in points, NOT normalized [0,1] simulator tap coordinates.' This reinforces and extends the schema's own description, earning 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 the tool's purpose: 'Inspect the deepest visible UIView at a raw native window point.' It explicitly distinguishes itself from the sibling 'native-user-interactable-view-at-point' by highlighting that it ignores userInteractionEnabled, making its scope well-defined.
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 versus the alternative: answers 'what is visually here?' rather than 'what would receive the touch?'. It also includes important coordinate system caveats and a specific error recovery action ('If status is restart_required: call restart-app then retry.'), leaving no ambiguity.
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 fully discloses behavior: it blocks, polls the accessibility/DOM tree, details conditions (exists, visible, hidden, text) with precise semantics, explains selector matching, and describes return value and failure behavior. Very 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 well-structured with a concise main statement, a bullet list of conditions, and a clear example of usage. Every sentence adds value without redundancy. It is appropriately sized for 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 8 parameters, complex conditions, nested objects, and no output schema, the description covers all necessary context: behavior, conditions, selector semantics, return value, polling defaults, and typical use cases. It is complete.
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 the description adds significant meaning beyond the schema: it explains selector matching rules (reading order, fallback, loose selector caveats) and textMatch behavior. This adds value beyond the parameter descriptions, earning 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 the tool blocks until a UI element reaches an expected state or timeout, with the specific verb 'await' and resource 'UI element'. It distinguishes itself from manual polling by mentioning screenshot/describe, and the purpose is immediately clear.
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 provides explicit when-to-use scenarios: after tap/navigation or before tapping async elements. It does not explicitly name alternative tools but implies not to poll manually. A clear 4, missing explicit when-not-to-use or sibling differentiation.
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?
No annotations are provided, so the description carries the full burden. It explains that the tool returns { status: 'ok', matches } with details including frames, properties, optional ancestors, and optional children. It also discloses failure modes (devtools not connected, app not running, restart required). There is no mention of destructive behavior, which is appropriate for a search 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 concise with two paragraphs covering purpose, usage, return format, comparison to sibling, required input, and failure conditions. It is well-structured and front-loaded with the most important information. No extraneous details, but could potentially be slightly more compact.
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 10-parameter input schema with no output schema, the description provides adequate completeness: purpose, when to use, what to provide, return structure, and failure handling. It lacks exhaustive detail about the return format, but the essence is covered. The tools' complexity is moderate, and the description sufficiently complements the schema.
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 parameters are documented. The description adds value by stating the requirement that at least one search criterion must be provided (not enforced by schema), and mentions that fields parameter has defaults and additional options. This goes beyond the schema descriptions, warranting a score above the baseline of 3.
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 'Search for' and the resource 'specific UIViews' along with the search criteria (class name, accessibility identifier, label, tag, nativeID). It distinguishes itself from the sibling tool 'native-full-hierarchy' by saying it is 'much more targeted', providing clear differentiation.
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 'Use when you need to locate a specific view by its properties without dumping the entire hierarchy', gives a required condition ('At least one of className, identifier, label, tag, or nativeID must be provided'), and lists failure conditions with remediation (call restart-app then retry). It also contrasts with the sibling 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?
With no annotations provided, the description carries the full burden and excels. It discloses side effects (frees resources, reaps TV-control daemons, leaves native devtools/services running on iOS/Android/TV, cascades to debugger on Chromium and loses console history), return format, and silent failure behavior. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then expands with usage guidance and platform nuances. Every sentence contributes distinct, high-value information, and despite its length, there is no filler or redundant detail.
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 multi-platform complexity and lack of an output schema, the description provides complete context: it explains platform-specific behaviors, return value, failure mode, and interactions with sibling tools like 'debugger-connect'. No critical details are omitted.
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 the property description already explains 'udid' thoroughly. The tool description adds no new semantic information about the parameter, only re-contextualizes it within platform examples, so the baseline 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 uses a specific verb ('Stop') and resource ('transport session') with platform-specific clarifications (simulator-server process, CDP WebSocket). It clearly distinguishes from the sibling tool 'stop-all-simulator-servers' by emphasizing this targets a single device, making its purpose 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?
Explicitly states when to use ('done interacting with one device but want to keep others running, or to restart a wedged transport') and when not to use it, directing users to 'stop-all-simulator-servers' for draining native services. It also provides platform-specific guidance for Chromium and TV targets.
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 provided, but the description fully discloses platform internals (AXRuntime, uiautomator, CDP, getPageSource), return format, coordinate normalization, and TV focus behavior. 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 lengthy but every sentence adds value, with clear platform breakdowns and practical instructions. Well-structured, though slightly verbose; could be trimmed slightly without losing key info.
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 fully covers return format, coordinate usage, platform-specific behaviors, and error recovery hints (Vega relaunch). Sufficient for an agent to use correctly across contexts.
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 description adds meaningful context for bundleId (fallback behavior, ignored on Android/Chromium) beyond the schema. The udid parameter is well-described in schema but description reinforces it.
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 retrieves the accessibility/DOM element tree, specifies multiple platform mechanisms, and distinguishes itself from sibling tools like native-describe-screen and 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends alternatives for app-scoped inspection (native-describe-screen) and React Native (debugger-component-tree), and provides TV-specific instructions. Covers when to use relaunch on Vega.
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 excels. It discloses file-reset behavior, return values, when the server writes vs. returns a directive, concurrency semantics, and the live-execution nature of recorded steps. This goes far beyond minimal requirements.
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 lengthy but front-loaded with the core purpose and each subsequent sentence adds essential operational detail. No redundancy is apparent, though it could be tightened without losing information. It earns a 4 rather than 5 due to its length.
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 recording tool with no output schema, the description is remarkably complete. It covers return values, file-write behavior in co-located vs. remote servers, concurrency rules, first-step guidance, editing options, and client-specific caveats. Nothing critical appears missing 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 descriptions already cover all parameters (100% coverage), so the baseline is 3. The description adds meaningful context, especially for executionPrerequisite, explaining the fragment vs. e2e distinction and its relationship with restart-app. This extra context elevates 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 specific verb and resource: 'Start recording a new flow, resetting .argent/flows/<name>.yaml to an empty flow and replacing any existing one.' It clearly distinguishes this from siblings like flow-add-step and flow-finish-recording by specifying what starting a recording entails.
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: 'Use when you want to capture a reusable sequence of device interactions for later replay.' It also outlines the full workflow, referencing flow-add-step, flow-finish-recording, and clarifies when to use executionPrerequisite vs. restart-app, giving strong contextual direction.
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. It details the event sequence (Down+Up), platform-specific behavior (CDP for Chromium), double-tap semantics, return value, and failure condition (unreachable backend).
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 informative and well-structured, but slightly lengthy. Each sentence serves a purpose, though some redundancy exists (e.g., repeating 'normalized'). Still clear and 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?
Despite no output schema, the description mentions the return value and failure conditions. It covers platform-specific details and coordinate discovery, making it complete for a tap tool in this context.
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 that x,y are fractions (0-1) and clarifying clickCount behavior (single multi-tap gesture vs separate calls). This goes 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 the tool's purpose: pressing the device screen at normalized coordinates. It specifies platforms (iOS, Android, Chromium) and distinguishes from sibling gesture tools (e.g., gesture-drag, gesture-pinch) by focusing on tap/click.
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 on when to use (to tap buttons, links, etc.) and how to prepare (determine coordinates using discovery tools per platform). Also advises on double-tap vs separate taps, helping the agent choose appropriately.
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. It discloses devtools injection preparation, tvOS focus-driven interface, Chromium no-op behavior, return value format, and failure condition. All behaviors are transparently documented.
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 the core purpose first, followed by usage guidance, platform specifics, and common IDs. It is slightly lengthy but each sentence adds value. Could be trimmed slightly but effectively 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?
Given no output schema, the description explains return value format (launched, bundleId) and covers error conditions, platform behaviors (iOS, Android, Chromium, tvOS, Vega), and provides common bundle IDs. It is thorough for the tool's 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%, so baseline is 3. The description adds value beyond schema: for activity it explains default behavior and platform ignore logic; for bundleId it provides platform-specific examples and Chromium tag semantics. This adds meaningful context.
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 opens an app by bundle ID/package name or confirms a running Chromium renderer. It distinguishes itself from sibling tools like open-url and explicitly says it's preferred over tapping home-screen icons, providing clear purpose and differentiation.
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 suggests using this tool when starting any app and notes exceptions: for Chromium route changes use open-url, for tvOS use tv-* tools. It also says it fails if app is not installed, guiding 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 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 present, so description fully covers behavior: sends touch events, x/y normalization (0.0-1.0), delayMs default (16ms), interpolate parameter, return value { events: number }, and failure conditions (device not booted, invalid event type).
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?
Description is fairly long but well-structured with clear sections and examples. Slightly verbose due to examples, but each example 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 3 parameters, no output schema, description covers all aspects: inputs (with normalization), output (events count), failure conditions, and usage examples. Complete for agent invocation.
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 description adds significant context beyond schema: explains normalization, interpolation purpose, default delay, and provides multiple examples. Adds meaning beyond raw 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?
Description clearly states it sends a sequence of touch events for complex gestures, listing specific use cases (long press, drag-and-drop, etc.) and explicitly distinguishes from sibling tools like gesture-tap, gesture-swipe, gesture-pinch, gesture-rotate.
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 (complex gestures) and when not to use (simple taps, straight-line scrolling, etc.), with alternative tool names. No ambiguity.
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 provided, but description fully discloses behavior: press-start, move, release, interpolation at ~60fps, normalized coordinates, return value {dragged: true, timestampMs}, and failure condition when CDP session unreachable. Also clarifies it does not scroll.
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: action, use cases with exclusions, return and failure. No unnecessary words, front-loaded with essential 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?
Description covers inputs (normalized coords, duration), behavior (interpolation, no scroll), platform specificity (Chromium desktop only), return value, failure condition, and references sibling tools. Without output schema, it sufficiently explains the 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. Description adds context about normalized coordinate space and alignment with gesture-tap and describe, but no new parameter-specific details beyond schema. Slight improvement 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?
Description clearly states it performs a desktop mouse drag in a Chromium app, with specific verb 'press, move, release' and resource 'mouse drag'. It distinguishes from siblings like gesture-scroll and gesture-swipe by stating use cases and exclusions.
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 when to use (slider thumbs, drag-and-drop, text selection, draggable UI) and when not to (scrolling, non-Chromium platforms). Directs to alternatives gesture-scroll and gesture-swipe.
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 normalized coordinates, ~60fps interpolation, swipe direction effect (fromY > toY scrolls down), settle parameter behavior (momentum-free), return value, and failure condition. No annotations provided, so description carries full burden and does it 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?
Description is concise yet comprehensive, with clear sections for purpose, usage, and parameter details. No unnecessary sentences; all information 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 7 parameters, no output schema, and no annotations, the description fully covers behavior, usage, parameter details, return value, and failure conditions. Complete for a mobile gesture 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%, but description adds value by explaining coordinate normalization, settle behavior, and direction semantics (e.g., 'Swipe up (fromY > toY) to scroll content down'). Adds context 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?
Clearly states it executes a swipe/drag gesture on iOS/Android, with normalized coordinates. Distinguishes from siblings like gesture-tap and gesture-scroll by mentioning coordinate system similarity to gesture-tap and alternative for Chromium.
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 lists use cases (scroll list, dismiss modal, drag element, navigate pages) and exclusion ('Not supported on Chromium — use gesture-scroll there instead'). Provides clear guidance on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: return structure ({devices, avds}), platform discriminators, state and kind fields, headless behavior for additional device sets, discovery mechanisms (CDP ports, adb devices), and silent omission when CLIs are unavailable. No annotation contradiction 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 lengthy but every sentence earns its place, covering essential details for each device type. It is front-loaded with a clear one-line summary, followed by structured elaboration. No fluff or redundant statements.
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 provides complete context: return format, field meanings, state semantics, platform-specific interactions, and failure modes. An agent can confidently invoke the tool and interpret its results.
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 the schema is empty, so there is nothing to add for parameter semantics. Baseline 4 applies, and the description appropriately focuses on output semantics instead.
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 ('List') and clearly enumerates the scope: iOS simulators, Android emulators, physical Android devices, running Chromium apps, and Vega devices. This fully distinguishes the tool from all siblings, none of which are list 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 instructs to use the tool 'at the start of a session' and provides actionable guidance for different target types: use boot-device for stopped Vega VVDs and Chromium apps, use describe/tv-remote/keyboard for TV targets instead of gesture tools, and explains how physical devices are 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 provided, the description fully discloses behaviors: platform-specific signals (SIGINT for iOS, SIGTERM for Android), polling, file export, return format, and failure condition. This provides comprehensive 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?
The description is concise, well-structured, and front-loaded with the main action. Each sentence provides essential information without redundancy, effectively using bullet-like formatting for platform details.
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 (platform-specific behavior, prerequisites, return type), the description is complete. It covers return shape, failure conditions, and usage context, despite lacking an output schema.
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 device_id. The description adds value by tying device_id to the failure condition ('Fails if no active native-profiler-start session exists for the given device_id'), reinforcing its role 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 'Stop native profiling and export trace data', specifying the action and resource. It distinguishes from siblings like native-profiler-start and native-profiler-analyze by detailing the stop and export process.
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 to 'Call native-profiler-start first' and provides context for use: 'Use when the user has finished the interaction to profile'. It also notes failure if no active session, guiding correct invocation.
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. It discloses return format (`{ typed, keys }`), failure conditions (unsupported key, unreachable backend), secret handling (server-side resolution, no plaintext in context, screenshot skipped), platform-specific behavior (TV, Vega, Android), and key/text ordering. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed with essential information; every sentence provides actionable detail. Bullet-point structure and clear sections make it scannable. It is not verbose—it is complete, with no 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?
For a tool with 4 parameters, no output schema, and no annotations, the description covers all necessary dimensions: usage scenarios, return value, error conditions, platform nuances, secret handling, and parameter effects. It is fully self-contained for an agent to 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 field names: precise key list, combination behavior (text before key), delayMs platform exceptions, and a detailed explanation of secret placeholder resolution with security guarantees. This significantly enriches schema semantics.
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: 'Type text or press special keys on the device...' and immediately enumerates supported targets and key types. It clearly distinguishes itself from sibling tools like tv-remote (for D-pad) and gesture tools, leaving no ambiguity about what keyboard 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?
Explicit guidance is provided: 'Use when you need to enter text or trigger a named key...' and it names alternatives for TV targets ('prefer the remote tools for D-pad navigation', 'move focus with tv-remote'). It also details when only `text` applies and how to combine text and key, giving the agent precise decision criteria.
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?
Thoroughly describes cross-platform behavior, deep-linking limitations, failure conditions, and return value structure. Full disclosure meets the burden since no annotations are provided.
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 purpose, followed by usage details, caveats, and return information. Every sentence contributes 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?
Completely covers functionality, including cross-platform schemes, deep-linking nuances, failure modes, and return object structure, even though no output schema is provided. Suitable for a tool with two simple parameters.
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?
Despite 100% schema coverage, the description adds significant value by detailing supported URL schemes per platform, deep-linking behaviors, and context for the 'url' parameter beyond the schema's examples.
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 opens URLs or URL schemes, and distinguishes itself from sibling tool 'launch-app' by mentioning it as an alternative for reliably opening apps.
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 on when to use this tool versus alternatives (custom scheme or launch-app) for deep-linking, including platform-specific caveats.
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 disclosure burden and does so thoroughly. It states return shape ({ completed, total, steps }), stops on first error/unmet condition, partial results behavior, and that no screenshot is captured automatically. It also explains nuances like tv-remote button arrays and await-ui-element halting execution.
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 well-structured and information-dense: purpose, when-to-use, complete tool reference, and multiple worked examples. Every sentence contributes necessary operational detail; nothing is redundant 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?
There is no output schema, but the description clearly communicates the result object and partial-completion semantics. Combined with platform tags, error handling, secrets placeholder note, and four examples, the agent can invoke the tool correctly without needing additional external knowledge.
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 schema covers the top-level parameters, the description adds massive value by enumerating argument signatures for all 12 allowed internal tools, specifying which platforms support each tool, and clarifying that udid is auto-injected. This far exceeds the generic schema's 'additionalProperties' object.
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 statement: 'Execute multiple device interaction steps in a single call', which clearly defines what the tool does and distinguishes it from the individual gesture tools among siblings. It also names supported platforms, adding further clarity.
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?
Usage guidance is explicit: 'Use when you need sequential actions and do NOT need to observe the screen between them' and 'ONLY use this when every step is known in advance.' It also names the alternative ('use individual tool calls instead') when steps depend on prior results.
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