dejank

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose: target discovery, capability probing, JS/React profiling (start/stop/capture), UI tree, interaction, logs, screenshots, and artifact listing. The profile tools are differentiated by 'js' vs 'react' and 'start/stop/capture', and the high-level investigate_slow_screen is explicitly preferred over chaining, reducing ambiguity.
Naming Consistency5/5
All tools use snake_case with a verb-first pattern (investigate_, list_, get_, start_, stop_, capture_, take_, tap). The modifiers 'js' vs 'react' and 'profile' are applied uniformly, creating a predictable and readable convention.
Tool Count4/5
16 tools is slightly above the typical 3-15 well-scoped range, but each tool serves a distinct purpose in the performance diagnostic workflow. The redundancy between capture and start/stop pairs is justified by different use cases (fixed-duration vs manual repro), so the count is reasonable if slightly heavy.
Completeness5/5
The tool set covers the full diagnostic lifecycle: target discovery, capability probing, JS and React profiling, UI tree inspection, interaction, device logs, screenshots, and artifact management. The one-shot investigate_slow_screen provides a high-level entry point, while the granular tools allow manual control, leaving no obvious gaps for the stated purpose.
Average 3/5 across 16 of 16 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals no details about side effects (e.g., whether clear resets logs), rate limits, output format, or permissions. The agent is left without knowledge of how the operation behaves at runtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is good from a conciseness standpoint, but it is under-specified to the point of being a fragment rather than a structured sentence. It does not effectively front-load key information about behavior or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters, no output schema, and no annotations, the description fails to provide a complete picture. It does not explain what the logs contain, how they are returned, or how parameters affect the operation, making the tool inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (clear, filter, maxLines, platform, sinceSeconds). It adds no meaning beyond the raw schema, leaving the agent to guess the semantics of each option.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as dealing with native logs and specifies platforms (Android logcat / iOS Simulator), which provides some clarity. However, it lacks a verb or explicit statement of what the tool does with those logs (e.g., fetch, list, stream), relying on the tool name to convey the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention typical scenarios, prerequisites (e.g., device connection), or exclusions. Sibling tools are not referenced, so an agent cannot distinguish when get_device_logs is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states 'Compact UI tree' without explaining what 'compact' means, whether it is read-only, or if a target/device selection is required. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified. It is a noun phrase rather than a clear sentence, sacrificing clarity for brevity. A properly concise description would include a verb and necessary context in a few words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits essential context such as return format, usage context, and differentiation from similar tools like get_component_tree. Given no output schema and no annotations, the description is too incomplete to be fully useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'platform' has an enum but no schema description. The description loosely mentions Android/iOS but does not explain the meaning of 'auto' or how the platform value affects the output. It fails to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (UI tree) and platforms (Android/iOS) but lacks a verb, reading as a fragment. It gives a general idea but does not distinguish from sibling tools like get_component_tree, so purpose clarity is only moderate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_component_tree or take_screenshot. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It discloses the potential 30–60s latency, but fails to mention whether the probes are read-only, what side effects may occur, or what the output looks like. The term 'probes' implies checking, but it is not explicit enough for an agent to assess safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, with only two phrases. It is front-loaded with the purpose and includes a useful latency note, but the first phrase is a fragment and the brevity comes at the expense of crucial parameter and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations, so the description carries the full burden of explaining what the tool does, how to call it, and what to expect. It only provides a vague purpose and a latency estimate, leaving major gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the 3 parameters (host, port, skipInteraction), and the description does not mention them at all. An agent gets no help understanding what these parameters control, making the tool very difficult to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'live capability probes' and specifies the domains (CDP, profilers, UI), which gives a clear sense of what it does. However, it does not strongly distinguish it from sibling tools like get_target_info or get_ui_tree, which also probe capabilities in a sense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The only added information is the potential 30–60s duration, which hints at a long-running operation but does not explain typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and reliability. Only 'best-effort' hints at potential incompleteness or failure, but there is no mention of whether it's read-only, what conditions are required, or what happens when React info is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, making it easy to scan. However, the phrase 'via Fusebox DevTools operations' is somewhat jargon-heavy and not entirely necessary, though it doesn't waste words overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a single parameter. The description provides minimal context about return values, error behavior, or use cases. It does not sufficiently explain what a consumer should expect from the component tree operation, especially given the rich set of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents a single targetId parameter but provides no description. The tool description does not explain what targetId refers to, how it's used, or its format. With 0% schema description coverage, the description should compensate, but it doesn't mention the parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as dealing with React component display names and renderer info, distinguishing it from siblings like get_ui_tree. However, 'best-effort' adds uncertainty and the exact nature of the output (tree structure) is only implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it differs from similar tools like get_ui_tree or capture_react_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only says 'List recent...' implying a read-only operation, but does not explain what 'artifacts' means, how 'recent' is defined, whether there is pagination, or any side effects. The lack of detail about return format or ordering is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse and front-loads the action and object. However, it is extremely terse and omits critical context, but that is a content completeness issue rather than a structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the tool description is insufficient for an agent to understand the full scope and usage. It does not explain what constitutes an artifact, the effect of the limit parameter, or how the output is structured. Sibling tools provide no contrast, making this description only minimally useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with 0% schema description coverage. The tool description does not mention the parameter or its semantics, leaving the agent to guess its purpose and valid values beyond the numeric bounds. There is no compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('recent TracePilot evidence artifacts'), giving a specific verb and object. However, it does not differentiate from sibling tools like list_targets, as 'artifacts' vs 'targets' is ambiguous without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. It does not mention prerequisites, appropriate scenarios, or exclude cases where other list tools (e.g., list_targets) would be more suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the action ('List') without disclosing whether it is a safe read operation, what the return format is, or any connection prerequisites. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words. It is appropriately sized for a simple list tool, though it omits parameter details that could be added without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and zero parameter documentation, the description is not complete enough. An agent cannot determine what values to pass for host/port or what the returned list will contain, making the tool contextually under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'host' and 'port' parameters. It does not mention them at all, leaving the agent to guess their meaning and format, despite the parameter names being somewhat self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Metro/CDP debug targets') with context ('connected React Native app'), clearly distinguishing the action from sibling tools like get_target_info which retrieves details about a single target. However, it doesn't explicitly mention that it lists all targets or how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives such as get_target_info or get_capabilities. There are no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions that it should be paired with a stop tool, but does not disclose what starting the profiler does to the app (e.g., performance impact), whether it requires a target, or any side effects. This is insufficient for a profiling 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and has no wasted words. It is concise and efficient, though it may be too brief for the tool's complexity. Still, the conciseness dimension rewards brevity and structure, which is well-executed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (one optional parameter, no output schema, no annotations), the description is incomplete. It does not explain what the profiler does, how to use the targetId, or how this tool relates to siblings like 'start_js_profile' and 'capture_react_profile'. The pairing hint is the only contextual detail provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'targetId' with 0% schema description coverage, and the description does not mention or explain this parameter at all. Since the description fails to compensate for the low coverage, parameter semantics are severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the resource ('React Profiler (Fusebox)'). It is specific about what it starts, but it does not explicitly distinguish from sibling tools like 'start_js_profile' or 'capture_react_profile', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to 'pair with stop_react_profile' implies a profiling session lifecycle, giving some usage context. However, it lacks any guidance on when to choose this tool over alternatives like 'start_js_profile' or 'capture_react_profile', and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only discloses 'writes artifact' as a side effect, with no mention of whether profiling is started/stopped, any state changes, or potential impact on the target. With no annotations, the description does not adequately convey behavioral traits such as whether the operation is read-only or has side effects beyond writing an artifact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the primary action and then adding the method and outcome. It is efficiently structured and easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context: it does not explain what 'capture' entails in relation to start/stop react profile, what the artifact is, how it is stored or accessed, or any interaction with sibling tools. No output schema exists, so the description alone is insufficient for an agent to understand the full behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention or explain the parameters targetId and profileMs at all. Since there are two parameters that likely carry important meaning, the description must compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Capture React Profiler session'), the method ('via Fusebox CDP'), and the outcome ('writes artifact'). This distinguishes it from sibling tools like start_react_profile, stop_react_profile, and capture_js_profile, which have different verbs or targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or relationships to the sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only describes input modes and does not explain what happens when both label and x/y are provided, whether coordinates are absolute or relative pixels, how platform affects behavior, or any error handling. This is a significant gap for a tool that directly performs a UI action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and front-loads the core verb and resource. It wastes no words and immediately conveys the essential purpose. This is an example of efficient minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given 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 is too sparse. It fails to explain the platform parameter, the precedence between label and x/y, or the outcome/return value. The low complexity of the action is offset by these unanswered questions, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must compensate for all parameters. It explains label (a string identifier) and x/y (coordinates) as alternatives, but omits the 'platform' parameter entirely, leaving its purpose and valid values unclear. The example for label helps, but the coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to tap a UI element by either a label (e.g., 'Go to next screen') or x/y coordinates. It uses a specific verb ('Tap') and implies the resource (on-screen element), distinguishing it from sibling tools that perform other actions like logging, profiling, or screenshotting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates two usage modes—by label or x/y—but offers no guidance on when to prefer one over the other, nor does it mention any alternatives or exclusions. Context is implied but not explicit, so it meets the 'implied usage' level rather than providing clear instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'get details', implying a read operation, but does not disclose what details are returned, whether network calls are made, authentication requirements, or any side effects. Minimal transparency beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that gets straight to the point. There is no filler or redundancy, and the structure is clean and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description is too terse to be complete: it does not specify what 'details' are included, how errors are reported, or the significance of host/port. Given the simplicity of the tool, a more descriptive explanation of the response and usage conditions is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description mentions 'by id' but does not explain that id is the primary key, nor does it address host and port parameters. No guidance is provided on their roles or optionality, leaving semantic ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (details for one Metro CDP target), and the scope (by id). It is specific and distinguishes itself from sibling tools like list_targets, which lists all targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., obtaining an id from list_targets) or scenarios where host/port are needed, leaving usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'Start', disclosing no side effects, whether targetId is required, how long profiling runs, or what happens after stopping. Minimal behavioral insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the primary action. The pairing hint adds useful context without bloat. Slightly terse but appropriately concise for a simple start command.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one undocumented parameter and no output schema, the description should compensate, but it omits targetId semantics and does not explain how results are obtained via stop_js_profile. Incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never mentions targetId. The agent receives no guidance on what targetId refers to or how to populate it, making the sole parameter semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Start Hermes JS CPU profiler'. It distinguishes from siblings by specifying 'Hermes JS' and by pairing with stop_js_profile, differentiating it from capture_js_profile or start_react_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'pair with stop_js_profile around a repro', giving clear usage context. It does not mention when not to use it or alternative tools like capture_js_profile, but the pairing note is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must fully disclose behavior. It states the action and a side effect (saving an artifact), but does not explain what 'artifact' means, whether the profiler must be running, failure conditions, or any other consequences. This is minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words: 'Stop JS CPU profiler and save artifact' effectively communicates the core purpose. It is appropriately concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter tool, the description covers the primary action, but the term 'artifact' is vague and there is no mention of the profiling workflow, where the artifact is stored, or how it related to sibling tools like start_js_profile. Given no annotations or output schema, some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered. Even though the description adds no parameter details, the baseline for 0 parameters is 4, and there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop'), the specific resource ('JS CPU profiler'), and the outcome ('save artifact'). It also distinguishes itself from sibling stop_react_profile by explicitly naming 'JS CPU profiler', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool, such as 'call after start_js_profile' or 'prefer this over capture_js_profile'. The workflow context is only implicit from the sibling tool names, but the description does not provide any decision-making support.
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?
With no annotations provided, the description carries the full transparency burden. It discloses the side effect of writing to .dejank/artifacts and the underlying tools (adb/simctl), but does not explain overwrite behavior, device requirements, or return values. This is moderate transparency, sufficient for a simple screenshot operation but lacking deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and includes the destination. Every word carries meaning, with no filler or redundant information. It is exceptionally succinct and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate: it states the purpose and output location. However, it omits any mention of return values (e.g., a file path), error conditions, or how the artifact can be accessed later. Sibling tools like list_artifacts imply retrieval, but the description does not explicitly connect these, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate for the platform parameter. It does not mention 'platform' or explain the meaning of 'auto' or the difference between android/ios, aside from implicitly hinting via adb/simctl. This is a clear gap, as the description adds little value beyond the enum values themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (capture device screenshot) with specific implementation details (adb / simctl) and the output destination (to .dejank/artifacts). This distinguishes it from sibling tools that capture profiles or UI hierarchies, making the purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a screenshot is needed, but provides no explicit guidance on when to use this tool over alternatives such as get_ui_tree or tap. There is no mention of exclusions or prerequisites, so it offers only implied context rather than detailed when-to-use instructions.
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?
The description discloses a concrete side effect (writes artifact under .dejank/artifacts), which adds value beyond the schema. However, it does not state whether the operation is read-only, how it interacts with an ongoing JS profiling session, or what the return value is. No annotations are present, so the description carries the full burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the core action and includes key details about duration and artifact location. No wasted words, perfectly sized for a quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and artifact destination, but omits details about the targetId parameter, the return format, and how it relates to sibling profiling tools (e.g., whether it conflicts with start_js_profile). Given the tool's simplicity, it is not severely incomplete but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly mentions 'durationMs' and its role, which is helpful given 0% schema coverage. However, 'targetId' is not explained at all, leaving a gap for one of the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture'), the resource ('Hermes JS CPU profile'), and includes the duration parameter. It distinguishes itself from sibling tools by specifying 'Hermes JS' (vs React) and using 'capture' (vs start/stop).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: provide a duration to capture a profile. However, there is no explicit mention of when to use this tool over start_js_profile/stop_js_profile or other alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core actions (stop and save) but says nothing about prerequisites (e.g., an active profiling session), side effects, error behavior, or what happens to the artifact. This is a significant gap for a mutating 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (8 words) that is front-loaded with the primary action. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 parameters, no output schema), and the description covers the essential behavior. It is reasonably complete, though it could benefit from noting the expected lifecycle (e.g., must be called after start_react_profile) and what happens if no session is active. These gaps are minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description adds no parameter-specific meaning, but none is needed. Per calibration guidance, 0 params yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Stop') and resource ('React Profiler'), plus an additional action ('save profilingData artifact'). It effectively distinguishes itself from siblings like stop_js_profile and start_react_profile by naming the profiler type and the artifact output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after starting the React Profiler but provides no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. It is minimally viable but lacks the explicit context that would make it a stronger 4 or 5.
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?
There are no annotations, so the description carries the full burden. It discloses the core behaviors: profiling JS and React, optional tap, fetching component names, and returning a diagnosis with artifact paths. The 'one-shot' hint implies it manages the entire start/stop lifecycle internally, which is useful context. However, it does not mention side effects like whether existing profiles are cleared or if artifacts are left behind, but overall it gives a solid behavioral overview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with 'PREFERRED' and the core action, and every sentence is informative. It avoids repetition and packs the key details (profiling scope, optional tap, output, and usage context) into a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (5 parameters, no output schema, no annotations) but the description provides a high-level summary of the workflow and return value. It lacks details on parameter semantics, the exact format of the 'rule-based diagnosis', and artifact path structure. Given the absence of structured schemas, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description must compensate. The only parameter hint is 'optional tap' which vaguely covers tapLabel/preferCdpTap/targetId, but the other parameters (platform, settleMs) are not explained at all. The description adds minimal semantic value beyond the schema's parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'profile JS + React around an optional tap, fetch component names, return rule-based diagnosis + artifact paths.' It clearly identifies the tool as a one-shot combined profiling and diagnostic tool, distinguishing it from the many individual profiling/tapping sibling tools. The phrase 'PREFERRED one-shot' further emphasizes its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use this instead of chaining start/stop/tap tools when asking why a screen is slow.' It mentions the alternative (chaining start/stop/tap tools) and the specific scenario (slow screen). This is clear, direct guidance that differentiates it from the siblings.
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:

[![dejank MCP server](https://glama.ai/mcp/servers/RanjithKumarSeekolu/dejank/badges/card.svg)](https://glama.ai/mcp/servers/RanjithKumarSeekolu/dejank)

Score Badge

Copy to your README.md:

[![dejank MCP server](https://glama.ai/mcp/servers/RanjithKumarSeekolu/dejank/badges/score.svg)](https://glama.ai/mcp/servers/RanjithKumarSeekolu/dejank)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/RanjithKumarSeekolu/dejank'

If you have feedback or need assistance with the MCP directory API, please join our Discord server