qa-probe
OfficialServer 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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| qa_probe_get_graphA | Get the dependency graph showing which backend API routes each frontend route calls. Ask: "Which backend routes does /dashboard call?" |
| qa_probe_get_reportA | Get the QA report with route scores and root causes. Ask: "Show me all broken routes" or "What is the overall score?" |
| qa_probe_probe_endpointA | Live-probe a single endpoint right now and return its status. Ask: "Is GET /alerts returning data right now?" |
| qa_probe_explain_failureA | Explain in plain English why a specific frontend route is showing no data or failing. Ask: "Why is /rules showing no data?" |
| qa_probe_suggest_fixA | Get a step-by-step fix guide for a root cause category. Ask: "What do I do about feature_flag_disabled issues?" |
| qa_probe_get_blast_radiusA | Find out how many frontend routes would break if a backend endpoint goes down. Ask: "What pages break if GET /alerts goes down?" |
| qa_probe_run_analysisA | Trigger a full qa-probe pipeline (analyze + probe + report) and return a summary. Ask: "Run a full QA check and give me the summary." |
| qa_probe_labelA | Record feedback on an endpoint diagnosis so qa-probe reapplies it on future runs. Use this to teach the tool: mark a result as expected/known (suppresses the finding) or confirm it as a real bug. Example: "mark the empty GET /alerts result as expected". |
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 8 tools
Each tool targets a distinct aspect of QA probing: explaining failures, impact analysis, dependency graphs, reports, feedback labeling, live probing, full analysis runs, and fix suggestions. No two tools overlap in purpose.
All tools share the 'qa_probe_' prefix and follow a consistent verb_noun pattern in snake_case (e.g., explain_failure, get_blast_radius). The minor deviation of 'label' as a single verb is still semantically clear and consistent with the pattern.
With 8 tools, the server is well-scoped for its domain—covering analysis, probing, reporting, labeling, and fixes—without being too sparse or overwhelming.
The tools cover the full workflow: triggering analysis, probing live endpoints, retrieving reports and graphs, explaining failures, assessing impact, suggesting fixes, and recording feedback. No obvious gaps exist for the intended use case.