MCP Workflow Engine
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_impactA | Analyzes the dependency graph to find all files impacted by changes to a specific file. Returns direct dependents, transitive dependents, and associated test files. Use this BEFORE implementing changes to understand the full scope of impact. |
| get_dependenciesB | Returns the list of files that a specific file imports/depends on. Useful for understanding what a file relies on. |
| get_graph_statsB | Returns statistics about the dependency graph including total modules, total dependencies, and any circular dependencies detected. |
| get_impact_from_diffB | Aggregates impact analysis across a diff or Git changeset. Provide a diff string, or let it use git to discover changed files. |
| verify_buildA | Runs the build command and returns success/failure with any errors. Use this AFTER implementing changes to verify the build passes. A task is NOT complete until this returns success. |
| run_typecheckA | Runs TypeScript type checking (tsc --noEmit) and returns any type errors. Use this to catch type errors without running the full build. |
| run_lintC | Runs the linter and returns any linting errors. |
| get_relevant_testsC | Returns a list of tests likely impacted by the given files or diff. |
| run_testsC | Runs the project's test command (auto-detected if not provided). |
| run_relevant_testsC | Runs tests for a provided list. Use {tests} in the command for precise selection. |
| get_contract_impactC | Highlights potential contract/API impacts and suggests checks. |
| chain_effect_checklistA | Generates a checklist of things to verify based on the type of file being changed. Use this to ensure you don't miss any ripple effects of your changes. |
| multi_file_checklistA | Generates checklists for multiple files being changed. Use this when your change spans multiple files. |
| invalidate_graph_cacheA | Invalidates the cached dependency graph. Use this after making changes to files so that subsequent impact analysis reflects the new state. |
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 14 tools
Most tools have clearly distinct purposes: impact analysis, test selection, build verification, and checklist generation are separated by action and input scope. The only mild ambiguity is between chain_effect_checklist and multi_file_checklist, and between get_impact and get_contract_impact, but their descriptions clarify the intended use.
The naming pattern is largely consistent, using verb_noun pairs like run_lint, get_dependencies, verify_build, and invalidate_graph_cache. The exceptions are chain_effect_checklist and multi_file_checklist, which drop the leading verb and break the otherwise predictable pattern.
At 14 tools, the surface is well-scoped for a workflow engine covering linting, type checking, builds, tests, impact analysis, and checklists. Each tool addresses a meaningful stage in the change workflow without unnecessary redundancy.
The tool set covers the full change lifecycle: pre-implementation impact analysis, implementation-time verification, test identification and execution, and post-change cache invalidation. It also includes checklist generation to guard against missed ripple effects, with no critical dead ends or missing core operations.