TestAtlas
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statsA | Summary of the test map: project/class/method counts, class-kind breakdown, endpoints, and edge tallies. |
| impactA | Blast radius of a change: the test scenarios affected by changing a class, method, step definition, or endpoint. Returns the affected scenarios (feature + the connecting step text), plus step-definition and feature counts. |
| search_stepsA | Full-text search over step definitions (expression text + method + class name). Returns matching step definitions. |
| search_scenariosA | Full-text search over scenarios (feature name + scenario name + step text + tags). Returns matching scenarios. |
| list_endpointsA | The HTTP endpoints/operations the suite calls, each with verb, route (real path when known), and its scenario blast radius. Highest-reach first. |
| resolve_stepA | Resolve a Gherkin step phrase to the EXISTING step definition(s) that would bind it — the same way the runner does (regex/cucumber expression, keyword-agnostic). Use this BEFORE writing a new step so an agent reuses what already exists instead of authoring a duplicate. status is 'exact' (one binding — reuse it), 'ambiguous' (several match — a conflict to resolve), or 'none' (nothing binds — returns existing step definitions ranked by shared terms, to adapt rather than duplicate). Each match returns the expression, the C# class/method, the method parameters, the argument values captured from the phrase, and file:line. |
| get_scenarioA | Full detail of scenario(s) whose name contains the given text: feature, tags, kind, example-row count, file:line, and the ordered steps (keyword + text + doc-string/data-table flags). Use to read an existing scenario before writing a similar one. |
| get_step_definitionA | Full detail of step definition(s) whose expression contains the given text: keyword, expression kind, method parameters, C# class/method/signature, file:line, and the scenarios that currently use it (usage count). Use to inspect a step before reusing or changing it. |
| list_tagsA | The tag taxonomy across the suite — every scenario tag (e.g. @smoke, @regression, ticket ids) with the number of scenarios carrying it, most-used first. Use to tag new scenarios consistently with what already exists. |
| step_catalogA | The reusable step vocabulary: step definitions with their placeholders and (best-effort) allowed values pulled from the expression — cucumber {int}/{string}/{word}, regex alternations like (Auto|Allianz) as enum values, other groups as free parameters. Use to compose new scenarios from steps and values that already exist. Optional keyword/query filters. |
| project_dependenciesA | The project dependency graph the suite implies: for each project, which projects it depends on and which depend on it, derived from cross-project binds_to/uses_type/inherits edges (edge counts as weight). Answers e.g. "what depends on the Party project?". Optional 'project' name filter. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Most tools are distinct, but several revolve around step definitions: search_steps, resolve_step, get_step_definition, and step_catalog all have overlapping surfaces and could cause misselection. impact and list_endpoints also share blast-radius concepts for endpoints. Descriptions help, but an agent may need to read carefully to pick the right tool.
The tools mostly use verb_noun snake_case (search_steps, list_endpoints, get_scenario, list_tags), but several are bare nouns (stats, impact, step_catalog, project_dependencies). The mixed conventions are still readable, yet the pattern is not uniform.
11 tools is well within the ideal scope for a test-suite analysis server. Each tool contributes a meaningful capability, from summary stats to step resolution to dependency analysis, and none feel redundant enough to cut.
For its apparent purpose—discovering, understanding, and safely reusing steps and scenarios in a test suite—the surface is thorough. It covers search, detailed lookup, resolution before authoring, impact analysis, endpoint visibility, tagging, a step catalog for composition, and project dependencies. There are no obvious dead ends or missing critical operations.