Skip to main content
Glama

detox_generate_expectation

Generate Detox mobile testing assertions for React Native apps to verify UI elements like visibility, text, labels, and values during end-to-end testing.

Instructions

Generate Detox expectation/assertion code (toBeVisible, toHaveText, etc.).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expectationTypeYesType of expectation
elementMatcherYesMatcher code or description
expectedValueNoExpected value
negatedNo
timeoutNoCustom timeout in ms
visibilityThresholdNo

Implementation Reference

  • MCP tool definition and handler for 'detox_generate_expectation'. Validates input using GenerateExpectationArgsSchema and generates code by calling generateExpectationCode.
    export const generateExpectationTool: Tool = {
      name: "detox_generate_expectation",
      description: "Generate Detox expectation/assertion code (toBeVisible, toHaveText, etc.).",
      inputSchema: zodToJsonSchema(GenerateExpectationArgsSchema),
      handler: async (args: z.infer<typeof GenerateExpectationArgsSchema>) => {
        const parsed = GenerateExpectationArgsSchema.parse(args);
    
        const code = generateExpectationCode({
          expectationType: parsed.expectationType,
          elementMatcher: parsed.elementMatcher,
          expectedValue: parsed.expectedValue,
          negated: parsed.negated,
          timeout: parsed.timeout,
          visibilityThreshold: parsed.visibilityThreshold,
        });
    
        return {
          success: true,
          code,
        };
      },
    };
  • Zod schema defining the input arguments for the detox_generate_expectation tool.
    export const GenerateExpectationArgsSchema = z.object({
      expectationType: z
        .enum([
          "toBeVisible",
          "toExist",
          "toBeFocused",
          "toHaveText",
          "toHaveLabel",
          "toHaveId",
          "toHaveValue",
          "toHaveSliderPosition",
          "toHaveToggleValue",
        ])
        .describe("Type of expectation"),
      elementMatcher: z.string().describe("Matcher code or description"),
      expectedValue: z.string().optional().describe("Expected value"),
      negated: z.boolean().optional().default(false),
      timeout: z.number().optional().describe("Custom timeout in ms"),
      visibilityThreshold: z.number().min(1).max(100).optional(),
    });
  • Core helper function that generates the Detox expectation code snippet based on provided options.
    export function generateExpectationCode(options: {
      expectationType:
        | "toBeVisible"
        | "toExist"
        | "toBeFocused"
        | "toHaveText"
        | "toHaveLabel"
        | "toHaveId"
        | "toHaveValue"
        | "toHaveSliderPosition"
        | "toHaveToggleValue";
      elementMatcher: string;
      expectedValue?: string | number | boolean;
      negated?: boolean;
      timeout?: number;
      visibilityThreshold?: number;
    }): string {
      const element = options.elementMatcher;
      const not = options.negated ? ".not" : "";
      let expectation: string;
    
      switch (options.expectationType) {
        case "toBeVisible":
          if (options.visibilityThreshold) {
            expectation = `toBeVisible(${options.visibilityThreshold})`;
          } else {
            expectation = "toBeVisible()";
          }
          break;
    
        case "toExist":
          expectation = "toExist()";
          break;
    
        case "toBeFocused":
          expectation = "toBeFocused()";
          break;
    
        case "toHaveText":
          expectation = `toHaveText('${options.expectedValue || ""}')`;
          break;
    
        case "toHaveLabel":
          expectation = `toHaveLabel('${options.expectedValue || ""}')`;
          break;
    
        case "toHaveId":
          expectation = `toHaveId('${options.expectedValue || ""}')`;
          break;
    
        case "toHaveValue":
          expectation = `toHaveValue('${options.expectedValue || ""}')`;
          break;
    
        case "toHaveSliderPosition":
          expectation = `toHaveSliderPosition(${options.expectedValue || 0})`;
          break;
    
        case "toHaveToggleValue":
          expectation = `toHaveToggleValue(${options.expectedValue ?? true})`;
          break;
    
        default:
          expectation = "toBeVisible()";
      }
    
      let code = `await expect(${element})${not}.${expectation};`;
    
      if (options.timeout) {
        code = `await waitFor(${element})${not}.${expectation}.withTimeout(${options.timeout});`;
      }
    
      return code;
    }
  • Registration of the generateExpectationTool in the allTools array for MCP tool serving.
    // Export all tools
    export const allTools: Tool[] = [
      buildTool,
      testTool,
      initTool,
      readConfigTool,
      listConfigurationsTool,
      validateConfigTool,
      createConfigTool,
      listDevicesTool,
      generateTestTool,
      generateMatcherTool,
      generateActionTool,
      generateExpectationTool,
    ];
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.

Install Server

Other Tools

Latest Blog Posts

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