Skip to main content
Glama
SmartBear

SmartBear MCP server

Official
by SmartBear

Reflect: Create Segment

reflect_create_segment

Create a reusable segment with an ordered list of steps for web, API, or mobile tests.

Instructions

Create a new Reflect segment which contains an ordered list of steps. Segments are reusable groups of steps that can be referenced from tests, and cannot reference other segments.

Toolset: Tests

Parameters:

  • name (string) required: Name of the segment to create.

  • type (enum) required: Platform of the segment.

  • description (string): Optional description of the segment.

  • deviceProfile (string): Device profile id. Required for a 'web' segment; ignored for 'api' and 'native-mobile'. One of: 'desktop', 'tablet', 'mobile'.

  • steps (array) required: Ordered list of steps that make up the segment. Segments cannot reference other segments. Prefer deterministic, selector-based steps ('click', 'input', 'submit', 'text-validation', 'hover', etc.) over AI-driven 'prompt' steps whenever a stable selector is available. Reserve 'prompt' steps for behavior that can't be expressed with a selector. Any text field in a step (e.g. 'inputText', 'url', 'expectedText', 'requestBody', header values, prompt text) may embed Reflect variable and function references using '${...}' syntax, which are resolved at run time: '${var(name)}' inserts the value of a parameter/variable named 'name' (declare parameters via the top-level 'parameters' field, or assign them mid-run with an 'update-parameters' step); '${sec(name)}' inserts the value of the account secret 'name'. Functions generate dynamic values: '${alphanum(n)}', '${alpha(n)}', '${num(n)}' (random alphanumeric / alphabetic / numeric string of length n), '${range(min, max)}' (random integer, inclusive), '${time(offsetMs)}' and '${datetime(offsetMs)}' (current epoch-millis / date-time, with an optional millisecond offset), and '${date(format, offsetDays)}' (current date formatted with tokens like 'MM/dd/yyyy', with an optional day offset).

  • parameters (array): Optional named parameters (variables) for the segment, each with a 'name' and optional default 'value'. Reference a parameter's value inside any step text field with '${var(name)}'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the segment to create.
typeYesPlatform of the segment.
stepsYesOrdered list of steps that make up the segment. Segments cannot reference other segments. Prefer deterministic, selector-based steps ('click', 'input', 'submit', 'text-validation', 'hover', etc.) over AI-driven 'prompt' steps whenever a stable selector is available. Reserve 'prompt' steps for behavior that can't be expressed with a selector. Any text field in a step (e.g. 'inputText', 'url', 'expectedText', 'requestBody', header values, prompt text) may embed Reflect variable and function references using '${...}' syntax, which are resolved at run time: '${var(name)}' inserts the value of a parameter/variable named 'name' (declare parameters via the top-level 'parameters' field, or assign them mid-run with an 'update-parameters' step); '${sec(name)}' inserts the value of the account secret 'name'. Functions generate dynamic values: '${alphanum(n)}', '${alpha(n)}', '${num(n)}' (random alphanumeric / alphabetic / numeric string of length n), '${range(min, max)}' (random integer, inclusive), '${time(offsetMs)}' and '${datetime(offsetMs)}' (current epoch-millis / date-time, with an optional millisecond offset), and '${date(format, offsetDays)}' (current date formatted with tokens like 'MM/dd/yyyy', with an optional day offset).
parametersNoOptional named parameters (variables) for the segment, each with a 'name' and optional default 'value'. Reference a parameter's value inside any step text field with '${var(name)}'.
descriptionNoOptional description of the segment.
deviceProfileNoDevice profile id. Required for a 'web' segment; ignored for 'api' and 'native-mobile'. One of: 'desktop', 'tablet', 'mobile'.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a creation tool. The description adds extensive behavioral detail: how steps are structured, variable syntax, step type selection guidelines, and parameter definitions. No contradictions with annotations.

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 long but well-structured, starting with the core purpose and then detailing parameters. It front-loads the key action. Some redundancy with schema descriptions exists, but overall it is efficient given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters, 3 required, and no output schema, the description is thorough. It covers all parameters, provides usage guidance, variable syntax, and constraints. The complexity is high, and the description meets the need.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant value beyond schema: it explains the preference for selector-based steps, variable interpolation syntax, and provides context for step types and constraints. For high-coverage schemas, this elevates the score.

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 'Create a new Reflect segment' with a specific verb and resource. It distinguishes from sibling tools like reflect_add_segment by describing segments as reusable groups of steps that cannot reference other segments, which implies a different use case.

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?

The description provides clear guidance on preferring deterministic selector-based steps over AI-driven prompt steps, and notes that segments cannot reference other segments. However, it does not explicitly differentiate from sibling tools like reflect_add_segment or describe when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/SmartBear/smartbear-mcp'

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