lyra-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LYRA_GRAPH_PATH | No | Path to the pipeline graph JSON file. Defaults to graphs/wiqas_query_pipeline.json. | |
| WIQAS_REPO_ROOT | No | The root path of the WiQAS repository. Defaults to D:\GitHub\WiQAS. | |
| WIQAS_VENV_PYTHON | No | Path to the Python interpreter inside WiQAS's virtual environment. Defaults to D:\GitHub\WiQAS\.venv\Scripts\python.exe. |
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 |
|---|---|
| list_stagesA | List every stage in the currently loaded pipeline graph: its id, stage_type, current config, and full config/input/output JSON schema. Enough to call run_stage or set_stage_config without opening any adapter source file. |
| get_stage_configA | Get a stage's current persistent baseline config. |
| set_stage_configA | Persistently merge config_overrides into stage_id's baseline config (validated before committing — an invalid override is rejected, not partially applied). Affects every subsequent run_stage call that omits config_override, and every run_pipeline call. For a one-off comparison that shouldn't persist, pass config_override to run_stage instead. |
| run_stageA | Run one stage from the loaded graph. If config_override is given, it's merged over the stage's persistent baseline config for this call only (not saved) — this is how to compare 2-3 configs on the same input without mutating shared state: call run_stage repeatedly with a different config_override each time, nothing to reset afterward. Omit config_override to use the current baseline unchanged. |
| run_pipelineA | Run the entire loaded pipeline graph end to end (e.g. retrieve then rerank), using every stage's current persistent baseline config. |
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 5 tools
The tools are mostly distinct: list_stages is for discovery, get_stage_config for targeted reads, set_stage_config for persistent writes, and the two run tools differ by scope. Minor overlap exists because list_stages already includes current config, making get_stage_config somewhat redundant.
All tools follow a clean verb_noun snake_case pattern: list/get/set/run + object. The naming style is perfectly consistent across the set.
Five tools is well-scoped for a pipeline stage configuration and execution server. Each tool covers a distinct operation without bloat or obvious missing essentials.
The surface covers stage discovery, config read/write, single-stage execution, and full-pipeline execution. A minor gap is that run_pipeline does not accept config_overrides, so one-off full-pipeline comparisons require temporarily mutating persistent config.