Detox MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The tools are well-organized around specific Detox operations like building, configuration management, code generation, testing, and device listing. Each tool name directly indicates its unique function, making it easy for an agent to select the correct one.
Naming Consistency5/5
All tools follow a consistent 'detox_verb_noun' pattern throughout, such as detox_build, detox_create_config, and detox_generate_action. This uniform naming convention enhances readability and predictability, allowing agents to easily understand and navigate the toolset without confusion.
Tool Count5/5
With 12 tools, the count is well-scoped and appropriate for a Detox testing server. Each tool serves a specific, necessary function in the E2E testing workflow, from setup and configuration to test generation and execution, ensuring comprehensive coverage without being overwhelming.
Completeness5/5
The toolset provides complete coverage of the Detox domain, including initialization, configuration management, code generation for actions/expectations/matchers/tests, device listing, building, and testing. There are no obvious gaps, and the tools support the full lifecycle of Detox E2E testing workflows.
Average 3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

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 mentions running a build command but fails to detail critical behaviors such as whether it modifies files, requires specific permissions, handles errors, or produces output. For a build tool with potential side effects, this omission is significant and leaves the agent guessing about its operational impact.
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 highly concise and front-loaded, consisting of two sentences that directly state the tool's purpose and action without unnecessary details. Every sentence earns its place by clearly conveying core functionality, making it efficient and easy to understand at a glance.
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 complexity of a build tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits, error handling, output format, and integration with sibling tools. This makes it inadequate for an agent to fully understand how to invoke and interpret results, especially in a testing context where build outcomes are critical.
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 input schema has 100% description coverage, providing clear documentation for all 5 parameters. The description does not add any semantic details beyond what the schema already explains, such as how parameters interact or typical use cases. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 purpose with a specific verb ('Build') and resource ('the app for Detox testing'), and it explains the action ('Runs the build command from your Detox configuration'). However, it does not explicitly distinguish this tool from its siblings, such as detox_test or detox_init, which might also involve building or configuration steps, leaving room for ambiguity.
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. It does not mention prerequisites (e.g., needing a Detox config file), exclusions, or comparisons to sibling tools like detox_test (which might include building) or detox_list_configurations (for checking available builds). This lack of context makes it unclear when this tool is the appropriate choice.
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 states the tool generates a file but doesn't mention whether this overwrites existing files, requires specific permissions, has side effects, or details the output format. For a file creation tool with zero annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand quickly.
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 tool involves file generation with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like file overwriting, error handling, or output details, leaving gaps for an AI agent to understand the tool fully in context.
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?
Schema description coverage is 100%, so the schema already documents all 5 parameters with descriptions. The description adds no additional meaning beyond implying configuration generation, but it doesn't explain parameter interactions or usage examples. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
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 ('Generate') and resource ('new Detox configuration file for your React Native project'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'detox_init' or 'detox_read_config', which might have overlapping or related functionality, preventing 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 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 like 'detox_init' (which might initialize a project) or 'detox_read_config' (which reads existing configs). It lacks context on prerequisites, such as whether a project must already be set up, or exclusions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states the tool generates code, implying a read-only or creation operation, but doesn't disclose behavioral traits like whether it modifies files, requires specific inputs, or has side effects. This is inadequate for a tool with parameters and no annotation coverage.
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, efficient sentence that front-loads the core purpose. Every word earns its place, with no wasted text, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 67% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the generated code looks like, how it's used, or the role of actionParams, leaving significant gaps for an AI agent to understand the tool's full context.
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?
Schema description coverage is 67%, with parameters like actionType and elementMatcher described in the schema. The description adds minimal value by listing example action types (e.g., tap, typeText, scroll), which partially overlaps with the enum in the schema. It doesn't explain the purpose of actionParams or provide additional semantics beyond the schema.
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 verb 'Generate' and the resource 'Detox action code', specifying it produces code for actions like tap, typeText, scroll, etc. It distinguishes from siblings like detox_generate_expectation or detox_generate_test by focusing on actions, but doesn't explicitly contrast them.
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 such as detox_generate_test or detox_generate_matcher. The description implies usage for generating action code, but lacks explicit context, prerequisites, or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'generates' code, implying a read-only or creation operation, but doesn't specify if this modifies files, requires specific environments, or has side effects like network calls. For a code-generation tool with zero annotation coverage, this lack of detail on behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single sentence: 'Generate Detox expectation/assertion code (toBeVisible, toHaveText, etc.).' Every word earns its place by stating the action ('Generate'), domain ('Detox'), purpose ('expectation/assertion code'), and examples. There's zero waste or redundancy.
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 complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like what the generated code looks like, how it integrates into tests, or error handling. For a tool with multiple parameters and no structured output information, more context is needed to guide effective use.
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?
Schema description coverage is 67% (4 of 6 parameters have descriptions), providing a moderate baseline. The description adds minimal value beyond the schema: it lists example expectation types (e.g., 'toBeVisible, toHaveText') which align with the enum in expectationType, but doesn't explain parameter interactions (e.g., how expectedValue relates to expectationType) or usage context. This compensates slightly but not fully for the coverage gap.
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 purpose: 'Generate Detox expectation/assertion code' with specific examples like 'toBeVisible, toHaveText, etc.' This distinguishes it from sibling tools like detox_generate_action or detox_generate_test by focusing on expectations/assertions. However, it doesn't explicitly mention what resource it operates on (e.g., UI elements in tests), keeping it from 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 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. It doesn't explain its relationship to sibling tools like detox_generate_test (which might incorporate expectations) or detox_generate_action (for different interactions). There's no mention of prerequisites, context (e.g., use in test setup), or exclusions, leaving usage ambiguous.
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 states 'generate' code, implying a creation operation, but doesn't specify whether this writes to files, outputs to console, requires specific permissions, or has side effects like modifying configurations. For a code generation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and impact.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, making it easy to parse. However, it could be slightly more structured by explicitly mentioning the tool's role in the Detox testing workflow.
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 complexity of a code generation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the generated output looks like (e.g., code snippet format), how it integrates with other Detox tools, or any behavioral constraints. This leaves the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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?
Schema description coverage is 80%, so the schema already documents most parameters well. The description adds minimal value beyond the schema by hinting at 'element selection (by.id, by.text, etc.)', which loosely relates to the matcherType enum but doesn't elaborate on parameter interactions or usage examples. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 verb 'generate' and the resource 'Detox matcher code for element selection', specifying it's for element selection mechanisms like 'by.id, by.text, etc.'. It distinguishes from siblings like detox_generate_action or detox_generate_expectation by focusing on matcher code generation rather than actions or expectations, but doesn't explicitly contrast with detox_generate_test which might also involve code generation.
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. It doesn't mention prerequisites, such as needing a Detox setup, or contrast with other tools like detox_generate_test for broader test generation. Usage is implied through the context of element selection, but no explicit when/when-not or alternative recommendations are given.
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 full burden. It states the tool generates a test file but doesn't disclose behavioral traits such as file system effects (e.g., overwriting existing files), required dependencies, error handling, or output format. This is inadequate for a tool that likely writes files.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by clearly stating the tool's function.
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 no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what a 'complete Detox test file' includes, how generation works, or what happens upon execution. For a tool with 5 parameters and likely file system operations, more context is needed.
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?
Schema description coverage is 60%, with parameters like 'description' and 'testName' documented but others like 'outputPath' lacking descriptions. The description adds no additional parameter meaning beyond the schema, such as explaining what 'includeSetup' or 'platform' entail. Baseline 3 is appropriate given partial schema coverage.
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 verb ('generate') and resource ('complete Detox test file'), specifying it creates a test file from a description. It distinguishes from siblings like detox_generate_action or detox_generate_expectation by focusing on a full test file, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like detox_generate_action for partial components or detox_test for running tests. The description implies usage for creating test files from descriptions but offers no context about prerequisites, dependencies, or 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 full burden but only mentions creation actions without detailing behavioral traits like side effects (e.g., file system changes), permissions needed, error handling, or output format. It lacks critical context for a tool that modifies project structure.
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 concise sentences that are front-loaded with the core purpose and efficiently detail the outcome (creates e2e folder structure and configuration). Every word adds value without redundancy.
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 tool's complexity (initializing a testing framework with file system changes), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't address what happens on success/failure, output details, or integration with sibling tools, leaving significant gaps.
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?
Schema description coverage is 50% (only projectPath has a description), and the description adds no parameter-specific information beyond implying initialization in a React Native project. It doesn't compensate for the undocumented testRunner parameter or provide additional meaning, so it meets the baseline for moderate schema coverage.
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 ('Initialize Detox') and the target ('in a React Native project'), specifying it creates an e2e folder structure and configuration. It distinguishes from siblings like detox_build or detox_test by focusing on setup rather than execution or generation, though it doesn't explicitly name alternatives.
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 like detox_create_config or detox_generate_test. The description implies it's for initial setup but doesn't specify prerequisites, exclusions, or context for choosing among sibling tools.
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 of behavioral disclosure. It states the tool lists 'available' devices, implying a read-only operation, but does not disclose other traits like error handling, performance characteristics, or whether it requires specific permissions or has rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance, with no wasted content.
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 tool's complexity (listing devices with parameters), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It does not explain return values, error conditions, or how parameters affect the listing, leaving the agent with insufficient information for effective use.
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 does not mention any parameters, and with 0% schema description coverage, the two parameters ('platform' and 'availableOnly') are undocumented in both the schema and description. Since schema coverage is low (<50%), the description fails to compensate by explaining parameter meanings, resulting in a baseline score due to lack of added value beyond the schema.
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 verb 'List' and the resources 'iOS simulators and Android emulators', providing a specific purpose. However, it does not explicitly differentiate from sibling tools like 'detox_list_configurations', which might list different resources, leaving some ambiguity in sibling differentiation.
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 other list tools in the sibling set (e.g., 'detox_list_configurations'). It lacks explicit context, prerequisites, or exclusions, offering only a basic statement of function without usage 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?
No annotations are provided, so the description carries full burden. It states the tool reads and parses a config file, implying a read-only operation, but doesn't disclose behavioral traits such as error handling (e.g., if file is missing), permissions needed, or output format. This leaves gaps for a tool with no annotation coverage.
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?
Single sentence, front-loaded with the core action, zero waste. Every word earns its place by specifying the verb, resource, and file types efficiently.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the parsed configuration returns (e.g., structure, format) or handle edge cases. For a read/parse tool with 2 parameters, more context is needed to guide effective use.
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?
Schema description coverage is 100%, so the schema already documents both parameters (projectPath and configPath). The description adds no additional meaning beyond implying these paths relate to the config file, but doesn't clarify usage (e.g., if both are optional or how they interact). Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb 'Read and parse' and the resource 'current Detox configuration file', specifying file types (.detoxrc.js or similar). It distinguishes from siblings like detox_create_config (creation) and detox_validate_config (validation), but doesn't explicitly contrast with detox_list_configurations which might overlap in purpose.
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 on when to use this tool versus alternatives like detox_list_configurations or detox_validate_config. The description implies usage for reading configuration but provides no context on prerequisites, typical scenarios, or 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'full options' but doesn't explain critical behaviors: whether this is a read-only or destructive operation, what happens during test execution (e.g., app installation, simulator startup), error handling, or output format. For a complex 14-parameter tool with no annotations, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose. Every word contributes to understanding the tool's scope. While it could be slightly more structured (e.g., separating purpose from capabilities), it avoids redundancy and stays focused on essential 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?
For a complex 14-parameter testing tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'running tests' entails behaviorally, what outputs or results to expect, error conditions, or dependencies on other tools. Given the richness needed for a test execution tool, this leaves too many contextual gaps for effective agent use.
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 mentions 'configuration, retries, artifacts, and more' which loosely maps to some parameters (configuration, retries, artifactsLocation), but doesn't add meaningful semantics beyond what the 71% schema coverage already provides. With moderate schema coverage, the baseline is 3 - the description doesn't compensate for the 29% undocumented parameters nor provide deeper context about parameter interactions or constraints.
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 ('Run Detox E2E tests') and scope ('with full options for configuration, retries, artifacts, and more'), making the purpose immediately understandable. It distinguishes this tool from siblings like detox_build or detox_init by focusing on test execution rather than setup or configuration tasks. However, it doesn't explicitly differentiate from all siblings (e.g., detox_generate_test might be related).
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. It doesn't mention prerequisites (e.g., needing a built app or configuration), when to choose this over other testing approaches, or which sibling tools should be used first (like detox_build or detox_create_config). The agent must infer usage from the tool name and sibling context alone.
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 states the tool validates for 'errors and warnings,' which implies a read-only diagnostic operation, but doesn't specify if it modifies anything, requires specific permissions, or has side effects like logging. For a validation tool with zero annotation coverage, this leaves critical behavioral traits unclear, though it's not misleading.
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, efficient sentence: 'Validate Detox configuration for errors and warnings.' It is front-loaded with the core action and resource, with no wasted words. Every part of the sentence contributes directly to understanding the tool's purpose, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is moderate (validation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, or output format. For a diagnostic tool, more information on what the validation returns (e.g., error messages, success status) would improve completeness, but it meets the minimum viable threshold.
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 input schema has 100% description coverage, with clear parameter descriptions: 'projectPath' as 'Path to project root' and 'configuration' as 'Specific configuration to validate.' The description adds no additional meaning beyond this, such as explaining parameter interactions or default behaviors. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the heavy lifting.
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 purpose: 'Validate Detox configuration for errors and warnings.' It specifies the verb ('validate') and resource ('Detox configuration'), making the action explicit. However, it doesn't differentiate this validation tool from its sibling 'detox_read_config' or 'detox_list_configurations', which might also involve configuration inspection, so it misses full sibling distinction.
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. It doesn't mention prerequisites, such as needing an existing configuration, or specify scenarios like pre-test validation. With siblings like 'detox_read_config' and 'detox_list_configurations', there's no indication of when validation is preferred over reading or listing, leaving usage ambiguous.
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 full burden. It states it lists configurations but doesn't disclose behavioral traits like whether it requires authentication, how it handles errors, if results are paginated, or what format the output takes. The description adds minimal value beyond the basic 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, efficient sentence that front-loads the core purpose with zero waste. It includes helpful examples without unnecessary elaboration, making it appropriately sized for its function.
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 no annotations, no output schema, and a simple parameter (1 param, 0 required), the description is adequate but has clear gaps. It explains what the tool does but lacks context on behavioral aspects like output format or error handling, which are important for a tool with no structured coverage.
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?
Schema description coverage is 100%, with the single parameter 'projectPath' documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
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 verb ('List') and resource ('all available Detox configurations') with specific examples ('ios.sim.debug, android.emu.debug'). It distinguishes from some siblings like 'detox_read_config' (which reads a single config) but doesn't explicitly differentiate from 'detox_list_devices' (which lists devices rather than configurations).
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 needing to see available configurations, but provides no explicit guidance on when to use this vs. alternatives like 'detox_read_config' (for reading a specific config) or 'detox_create_config' (for creating new ones). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![detox-mcp MCP server](https://glama.ai/mcp/servers/gayancliyanage/detox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gayancliyanage/detox-mcp)

Score Badge

Copy to your README.md:

[![detox-mcp MCP server](https://glama.ai/mcp/servers/gayancliyanage/detox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gayancliyanage/detox-mcp)

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/gayancliyanage/detox-mcp'

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