Skip to main content
Glama
Ralf090102

lyra-mcp

by Ralf090102
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

lyra-mcp

Typed pipeline-stage abstraction + MCP tool surface for RAG/agent pipelines — lets Claude read/run/modify individual pipeline stages (retrieve, rerank, generate, eval) as structured, typed calls instead of tracing and re-reading raw code each time.

Status: Phase 3 done, plus a wiqas.eval stage. The abstraction is validated against a second, differently-built project (Orion, a FastAPI service vs. WiQAS's script/CLI shape) with zero changes to any shared code — only new adapter files. A third stage type (wiqas.eval, wrapping RAGAS's answer_similarity metric) proves the same abstraction also extends to a stage with a real live-LLM dependency, not just local-inference stages like retrieval/reranking.

Running the MCP server

uv run lyra-mcp

Registered with this session's Claude Code project (.mcp.json, generated via claude mcp add):

claude mcp add lyra -s project -e WIQAS_REPO_ROOT="D:\GitHub\WiQAS" -e WIQAS_VENV_PYTHON="D:\GitHub\WiQAS\.venv\Scripts\python.exe" -- uv run --project D:\GitHub\lyra-mcp lyra-mcp

New MCP servers load at Claude Code session start — restart/reconnect the session for lyra's tools to appear.

Tools

  • list_stages() — every stage in the loaded graph (graphs/wiqas_query_pipeline.json by default, override with LYRA_GRAPH_PATH): id, type, current config, and full config/input/output JSON schema. Enough to call the other tools without opening any adapter source file.

  • get_stage_config(stage_id) / set_stage_config(stage_id, config_overrides) — read/persistently mutate a stage's baseline config (validated before committing).

  • run_stage(stage_id, input, config_override=None) — run one stage. config_override merges over the baseline for that call only, without persisting — the way to compare configs on the same input (call repeatedly with a different override each time, nothing to reset).

  • run_pipeline(external_inputs) — run the whole loaded graph end to end via pipelines/executor.py's topological-order executor.

Real bugs found building this (Phase 2)

Two contract mismatches only surfaced through live protocol testing, not unit tests — both are why the project's test-first-workflow rule treats "touching a real external system" as its own verification step:

  • Client-visible errors were silently generic. The installed MCP SDK (mcp==2.1.1) only forwards a raised exception's own message to the client when it's the SDK's own ToolError — anything else (including Lyra's own LyraError hierarchy) becomes a bare "Error executing tool <name>", discarding every hand-written error message. Fixed with a _translate_lyra_errors decorator in server.py that re-raises any LyraError as a ToolError with the same text, at the MCP boundary only (core/errors.py stays independent of the SDK).

  • Schema and actual data disagreed on field names. model_json_schema() defaults to by_alias=True; model_dump() defaults to by_alias=False. list_stages advertised SearchResultModel's aliased field as "id", but run_stage/run_pipeline were returning it as "document_id" — a real schema/data mismatch an agent trusting the advertised schema would hit immediately. Fixed by adding by_alias=True everywhere a StageOutput gets dumped for an external caller (pipelines/executor.py, server.py).

Also confirmed empirically (not assumed): a bare dict return-type annotation does not produce structured content from this SDK version — only a parameterized dict[str, Any] (or a real pydantic model) does; sync def tool functions are automatically offloaded to a worker thread (anyio.to_thread.run_sync), so no manual async/await was needed anywhere in server.py.

Related MCP server: consulting-mcp-server

Architecture: the subprocess boundary

WiQAS's internal code (from src.retrieval.retriever import WiQASRetriever, etc.) only imports cleanly inside WiQAS's own venv, because of its heavy ML dependencies (torch, chromadb, sentence-transformers). Rather than running Lyra itself inside WiQAS's venv — which would break down the moment a second, differently-built project (Orion, Phase 3) needs wrapping too — each Lyra stage invokes the target project's own interpreter as a subprocess, running a small bundled shim script that talks JSON over stdin/stdout.

Claude ──calls──> Lyra typed Stage ──subprocess──> target project's own venv
                   (stable interface,     runs a small runner shim script,
                    same every time)      talks JSON over stdin/stdout

Lyra itself stays a small, dependency-light project (pydantic only) — the framework (src/lyra/core/) has zero knowledge of WiQAS or Orion specifically, so the same run_subprocess_stage helper is what every adapter reuses unchanged.

A real gap this surfaced during implementation, worth knowing if you're wrapping a new project: don't trust a code investigation's reported function signatures for the exact wire shape — always confirm against the actual runtime output. Two mismatches turned up in WiQAS that weren't visible from reading signatures alone: SearchResult.to_dict() serializes its document_id attribute under the JSON key "id", and RerankerManager.rerank_search_results()'s output dicts omit search_type entirely. Both are handled in SearchResultModel (see its docstring in src/lyra/adapters/wiqas/common.py). Orion (Phase 3) turned out to have the identical mismatch, independently confirmed by reading its own source — not a coincidence worth assuming holds for a third project, but a real, recurring pattern worth checking for every time.

Also found live: WiQAS's own logging (a module-level rich.Console()) prints straight to stdout, which would have polluted the runner scripts' JSON-only stdout contract. Fixed on the Lyra side only (no WiQAS changes) with an OS-file-descriptor-level redirect — see src/lyra/adapters/_shared/shim_io.py. That helper was deliberately kept project-agnostic and outside any single adapter's folder specifically because this pattern was expected to recur — and it did: Orion has the exact same rich.Console()-to-stdout issue, fixed by reusing shim_io.py completely unchanged, zero new code needed.

Phase 3: validated against Orion, zero shared-code changes

Orion (D:\GitHub\Orion) is a FastAPI service with a Tauri desktop shell — a genuinely different shape from WiQAS's script/CLI style — wrapped the same way: adapters/orion/ mirrors adapters/wiqas/ file-for-file (common.py, retrieval.py, reranking.py, runners/), registered as two more STAGE_REGISTRY entries. No changes were needed to core/, adapters/_shared/shim_io.py, registry.py's shape, pipelines/executor.py, or pipelines/state.py — the entire cost of wrapping a second project was the new adapter files, exactly as the architecture was designed to allow. Live integration test (tests/integration/test_orion_live_pipeline.py) passed in ~21s against Orion's real ~232-chunk collection — dramatically faster than WiQAS's several minutes, since Orion's corpus is smaller and it does no query-decomposition/cross-lingual translation.

Eval stage: a stage type with a real live-LLM dependency

adapters/wiqas/eval.py wraps WiQAS's RAGAS answer_similarity metric (src/evaluation/[3] ragas/ragas_fixed.py) as wiqas.eval. Two things found by reading that code directly, not guessed:

  • The file WiQAS's own docs point to as the RAGAS entrypoint (ragas_eval.py) is broken — it references json, argparse, evaluate, and the ragas metric objects without ever importing them, so it imports cleanly but raises NameError at call time. ragas_fixed.py is the working one.

  • A real, hard live dependency, unlike retrieval/reranking. WiQAS's own setup_ollama_for_ragas() makes an unconditional chat-completion call to Ollama to test connectivity — even in answer_similarity-only mode, where that chat model is never actually used for scoring (answer_similarity is embeddings-only). Can't be skipped without modifying WiQAS's own code, which this adapter never does. A running Ollama server with the configured chat model (default mistral:latest) and nomic-embed-text both pulled is a hard precondition.

Scoped narrowly and deliberately: answer_similarity only (use_all_metrics=False, WiQAS's own default) — its own code comment calls this "the only one that works reliably," and warns the full 6-metric mode "may timeout." use_all_metrics=True is exposed as a config option but untested here. Live integration test (tests/integration/test_wiqas_eval_live.py) confirmed a real, discriminating score (0.697 similarity between a Filipino ground-truth answer and a differently-phrased English paraphrase) in ~12s wall time — far faster than WiQAS's own "this may take several minutes" comment, which describes the full-metric path this stage doesn't use. Not wired into wiqas_query_pipeline.json: eval needs a generated answer as input, which no existing stage produces (no generate stage exists yet) — registered in STAGE_REGISTRY alone, same precedent as retrieval/reranking being proven directly before Phase 2's MCP layer existed.

Setup

Requires uv and Python 3.12.

uv venv --python 3.12
uv sync

.env.example documents the environment variables Lyra reads if your WiQAS/Orion checkouts live somewhere other than their defaults. It's a template, not auto-loaded — nothing in this codebase reads .env — so set these as real environment variables in your shell/session:

WIQAS_REPO_ROOT=D:\GitHub\WiQAS
WIQAS_VENV_PYTHON=D:\GitHub\WiQAS\.venv\Scripts\python.exe
ORION_REPO_ROOT=D:\GitHub\Orion
ORION_VENV_PYTHON=D:\GitHub\Orion\.venv\Scripts\python.exe

Running on a different machine

Everything machine-specific is env vars plus one generated config file — nothing is hand-edited:

  1. uv venv --python 3.12 && uv sync (see Setup above).

  2. Set WIQAS_REPO_ROOT/WIQAS_VENV_PYTHON and/or ORION_REPO_ROOT/ORION_VENV_PYTHON as real environment variables for whichever projects you're wrapping on this machine (see .env.example).

  3. Regenerate .mcp.json — it's gitignored on purpose (bakes in this machine's absolute uv.exe path and repo checkout paths, not portable as-is; see .mcp.json.example for the shape). Don't hand-copy the example — run:

    claude mcp add lyra -s project -e WIQAS_REPO_ROOT="<path>" -e WIQAS_VENV_PYTHON="<path>" -e ORION_REPO_ROOT="<path>" -e ORION_VENV_PYTHON="<path>" -- uv run --project <path to this checkout> lyra-mcp

    Restart/reconnect the Claude Code session afterward — new MCP servers load at session start.

If a path is wrong, the failure is a clear, actionable SubprocessLaunchError: Interpreter not found: <path> (see core/subprocess_adapter.py) — not a silent hang or a cryptic import error.

Running tests

# Unit tests (default) — fast, subprocess boundary mocked, no WiQAS/Orion needed
uv run pytest

# Integration tests (opt-in) — need a real WiQAS/Orion venv + an already-ingested
# Chroma collection at WIQAS_REPO_ROOT / ORION_REPO_ROOT respectively
uv run pytest -m integration -s

Layout

src/lyra/
  core/            # StageConfig/StageInput/StageOutput, Stage ABC, the shared subprocess-boundary helper
  registry.py      # stage_type -> concrete classes lookup, all wrapped projects register here
  server.py        # the MCP server (list_stages/get_stage_config/set_stage_config/run_stage/run_pipeline)
  mcp_models.py    # tool-output-only models (StageInfo, RunPipelineResult)
  adapters/
    _shared/       # project-agnostic runner-script helpers (e.g. the stdout-redirect fix), reused by every adapter
    wiqas/         # WiQAS-specific typed stages (retrieval, reranking, eval) + their runner shim scripts
    orion/         # Orion-specific typed stages, same shape as wiqas/ — proves the pattern generalizes
  pipelines/       # PipelineGraph (load/validate), executor.py (topological-order execution), state.py (mutable loaded-graph wrapper)
  graphs/          # Example pipeline-as-data graphs, one per wrapped project
tests/
  unit/           # subprocess boundary mocked, run by default
  integration/    # opt-in (`pytest -m integration`), needs real WiQAS/Orion

Available Tools

5 tools
get_stage_configA
Read-onlyIdempotent

Get a stage's current persistent baseline config.

ParametersJSON Schema
NameRequiredDescriptionDefault
stage_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the safe-read nature is covered. The description adds the nuance 'current persistent baseline config', which clarifies it is not runtime/transient configuration, but it does not disclose further behavioral details such as error cases or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence that is front-loaded with the verb and resource, with no filler or redundant restatement. It earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with readOnly and idempotent annotations plus an output schema, the description is largely complete. The only context gap is explicit guidance on when to prefer sibling tools, but the get-vs-set/list semantics make this reasonably inferable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for stage_id. It ties the parameter to 'a stage's' config, but it does not explain how to obtain or format stage_id. The parameter name and title already do most of the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a specific resource ('a stage's current persistent baseline config'). This clearly distinguishes it from its siblings 'set_stage_config' (set vs. get) and 'list_stages' (list all vs. get one).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Get a stage's current persistent baseline config' implies use when you need the saved baseline for a single stage, but it does not explicitly say when to use this vs. list_stages or set_stage_config. No alternatives or exclusion conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_stagesA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. Beyond those hints, it discloses that the operation is scoped to the 'currently loaded pipeline graph' and that the output includes full config and JSON schema details, which is useful contextual behavior. This exceeds the minimal annotation coverage without contradicting it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the first states the action and result fields, the second states its purpose. The key scoping phrase 'currently loaded pipeline graph' is front-loaded, and every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter list tool with an output schema available, the description provides enough context: scope, result contents, and why the agent would call it. The mention of run_stage and set_stage_config helps justify its role in a workflow. No critical information appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is empty, so there are no parameter semantics to clarify; the baseline for zero-parameter tools is 4. The description does not mention arguments, but none are needed. It correctly focuses on output and context rather than parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List every stage in the currently loaded pipeline graph', a specific verb and resource, and enumerates the returned fields (id, stage_type, current config, full JSON schemas). This clearly distinguishes list_stages from its siblings get_stage_config, set_stage_config, and run_stage, which operate on individual stages or perform mutations. It leaves no doubt about the tool's scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives a concrete use case: the output is 'Enough to call run_stage or set_stage_config without opening any adapter source file.' This tells the agent when to use this tool as a preparatory step. However, it does not explicitly name get_stage_config as an alternative for single-stage queries, so it lacks explicit when-not/alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_pipelineA

Run the entire loaded pipeline graph end to end (e.g. retrieve then rerank), using every stage's current persistent baseline config.

ParametersJSON Schema
NameRequiredDescriptionDefault
external_inputsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnly false and idempotent false, so the mutation/non-idempotent nature is covered. The description adds context that execution uses each stage's persistent baseline config (vs ad-hoc config), but it doesn't disclose side effects, latency, or external calls beyond the 'retrieve then rerank' example. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One compact, front-loaded sentence that states action, object, scope, and config behavior. Every clause earns its place; no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the operation and config behavior, and annotations plus output schema handle safety and return format. However, the sole required parameter external_inputs is left entirely undescribed, which is a meaningful gap for correct invocation. The missing run_stage contrast is minor because siblings imply it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description never mentions external_inputs or explains what shape/contents the object should have. With additionalProperties true, the agent gets no guidance on required keys or semantics from either source.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Run'), names the resource ('the entire loaded pipeline graph'), and specifies the scope ('end to end', 'every stage'), distinguishing it from sibling run_stage without needing to inspect schemas. The 'current persistent baseline config' qualifier adds precision about how stages are configured.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear context for use: when you want the full pipeline executed end to end rather than a single stage. It doesn't explicitly name run_stage as the alternative or state exclusions, but the 'entire loaded pipeline graph' phrasing makes the route evident.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYes
stage_idYes
config_overrideNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false, openWorldHint=false, and idempotentHint=false. The description adds meaningful behavior beyond that: config_override is merged over the persistent baseline for this call only, is not saved, and repeated calls avoid mutating shared config state. This gives an agent useful expectations about side effects and persistence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first sentence, and the config_override guidance is organized clearly. The explanation is slightly wordy but every sentence adds relevant operational detail, so it remains efficient without being bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description thoroughly covers the optional config_override behavior and its use case, but it omits semantics for the required stage_id and input parameters, and does not mention prerequisites like the graph needing to be loaded. The output schema exists, so return values need not be explained, but the parameter gaps leave the definition incomplete for a 3-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It richly explains config_override, including merge semantics and non-persistence, but stage_id and input receive no semantic explanation beyond their names. With two of three parameters unexplained, the description only partially compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Run one stage from the loaded graph.' This clearly identifies the tool's action and scope, and distinguishes it from siblings like run_pipeline (whole pipeline) and list_stages/get_stage_config/set_stage_config (inspection/config tools).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong, explicit usage guidance for config_override: when to use it, how to compare configs, and that no reset is needed afterward. However, it does not explicitly state when to choose this tool over run_pipeline or other siblings, so it stops short of full alternative-based guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_stage_configA
Idempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
stage_idYes
config_overridesYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description reveals that the merge is validated before committing, is atomic (invalid overrides are rejected rather than partially applied), and has a persistent global effect on subsequent run_stage and run_pipeline calls. These are exactly the side effects an agent needs to anticipate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three focused sentences lead with the core operation, then cover side effects and the alternative. No filler or schema repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with an output schema present and idempotentHint set, the description covers the main decision, the effect, and the exception. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden. It defines stage_id as the target baseline config and config_overrides as the values being merged, and adds validation semantics, but it does not enumerate any allowed override keys. Given additionalProperties is true, that is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise action ('persistently merge') and a specific resource ('stage_id's baseline config'), so an agent knows exactly what the tool does. It also distinguishes this from run_stage by contrasting persistent changes with one-off overrides.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use the tool (when a change should persist and affect future runs) and when not to (one-off comparison), explicitly directing the agent to pass config_override to run_stage instead. This is clear routing against a named sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedget_stage_config
    • First observedlist_stages
    • First observedrun_pipeline
    • First observedrun_stage
    • First observedset_stage_config
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation4/5

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.

Naming Consistency5/5

All tools follow a clean verb_noun snake_case pattern: list/get/set/run + object. The naming style is perfectly consistent across the set.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • consulting-mcp-server

    Brinkv3
    A
    license
    Not graded
    quality
    B
    maintenance
    Exposes RAG and document intelligence pipelines as 8 composable tools for MCP-compatible clients, enabling querying, indexing, classifying, extracting, and assessing documents.
    1
    MIT

  • AgentOps EvalBench MCP

    AbhinavVarma02
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables LLM evaluation and observability by uploading documents, building test sets, running RAG pipelines, and automatically scoring answers for groundedness, hallucination risk, retrieval quality, latency, and cost, with tools exposed to MCP-compatible clients.
    1
    MIT

  • RAG MCP Server

    arbaz-builds
    F
    license
    Not graded
    quality
    B
    maintenance
    Exposes a Retrieval-Augmented Generation pipeline as MCP tools, allowing users to index documents and query them through any MCP-compatible client like Claude or IDEs.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ralf090102/lyra-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server