Test assistent MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TESTASSIST_KNOWLEDGE_DIR | No | Optional path to an alternative knowledge base directory. If set, the server loads knowledge from this directory instead of the default 'knowledge/' folder. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| catalog_techniquesA | List all classic test techniques (BVA, equivalence partitioning, decision table, pairwise, state transition, use case, error guessing). |
| catalog_heuristicsA | List all test heuristics (SFDPOT, FEW HICCUPPS, RCRCRC, quality criteria catalog, bug heuristics, test tours). |
| generate_test_casesA | Generate concrete test cases using a classic test technique (Boundary Value Analysis, Equivalence Partitioning, Decision Table, Pairwise Testing, State Transition, Use Case Testing, Error Guessing). Each call targets exactly one technique. For raw typed test data (random rows or property-based), use generate_test_data instead. |
| generate_test_dataA | Generate raw test data (values), not technique-driven test cases. strategy='random' produces N seeded rows across multiple fields; strategy='property' produces boundary + random + invalid values for a single typed field. For classic techniques with expected outcomes, use generate_test_cases. |
| advise_techniqueC | Recommend techniques and heuristics for a described testing context via keyword analysis. |
| checklist_forB | Produce a recommended test checklist (items) for a context, e.g. RCRCRC for regression. |
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 6 tools
generate_test_cases and generate_test_data are the most confusable pair, but their descriptions explicitly delineate them (technique-driven cases vs raw values). The catalog_* pair and the advise/checklist pair are distinct in purpose, though advise_technique and checklist_for both operate on a described context, which creates mild overlap.
Five of six tools follow a clean verb_noun pattern (generate_test_cases, generate_test_data, advise_technique, catalog_heuristics, catalog_techniques). checklist_for breaks the pattern with a noun+preposition form, but it is still readable and clearly named.
Six tools is well within the ideal 3-15 range and each has a clear, non-redundant role in the testing workflow. No tool feels padded or superfluous.
The surface covers generation (cases and data), technique/heuristic catalogs, advisory, and checklists, forming a coherent lifecycle for a test-assistant domain. Minor gaps exist (e.g., no export/format or test-execution helper), but agents can work around them.