Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 11 tools

Disambiguation3/5

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.

Naming Consistency3/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues