Retrieve grounding chunks from the local QA knowledge base (Markdown guides: testing methodologies, IEEE/ISO/OWASP Markdown standards, audit/evaluation frameworks, AI-SDLC case studies, the EU AI Act). NOT included: the ISTQB and OWASP PDF syllabi (licensing) - so fundamentals such as test design techniques (boundary value analysis), smoke vs sanity or test levels are often absent; the first call after server start may take ~30s while the index builds (usually done in the background by then). Returns {"chunks": [{"source", "category", "text", "score", "match"}], "kb_version", "best_score", "low_relevance"[, "note"][, "warnings"]}; "match" is strong (score >=0.55 AND the chunk contains most of the query's content terms), moderate (>=0.40) or weak, and when even the best chunk is not strong a note says to use only chunks that really answer the question (a 0.45 hit on an unrelated case study is vocabulary overlap). A query that names a source the KB does not ship (e.g. ISTQB) gets a note saying so; an out-of-range k is clamped and reported in "warnings". Chunks scoring below min_score (cosine similarity, default 0.40, 0 disables) are dropped; if nothing reaches it, chunks is empty, low_relevance is true and note says so - then answer from your own knowledge and tell the user the KB had no match (best_score shows how close the best miss was). Near-duplicate overlapping chunks of one document are collapsed. category, if given, must be one of: Standard, Methodology, Article, Expert Knowledge, Audit/Evaluation; an empty query, an unrecognized category or an out-of-range min_score returns a structured {"error": "invalid_argument", ...} rather than raising. k is clamped to [1, 20].

List every document in the knowledge base, grouped by category. Returns {"categories": {category: [{"source", "title"}]}, "kb_version", "doc_count"}.

Deterministic QA effort estimate (PERT + complexity multipliers + team capacity + confidence score) — no LLM narrative; write your own from these numbers. Fields mirror the app's project-intake dialogue and are validated with the same rules; a validation failure returns {"error": "validation", "fields": {field: message}}, never a crash; all eleven fields are needed, and a missing or empty one is reported by name in that same shape Success returns the full EstimationData as JSON (baseline, multipliers, pert_activities, capacity, risk_buffer_days, final_effort_min/max, confidence_level/confidence_score, confidence_note, data_quality_score out of data_quality_max=20). Negative team sizes and negative or zero timelines are rejected with a validation error; decimal team sizes ("2.5") are rounded half up to a whole headcount with a warning. capacity_gap = available_person_days - pert_total_expected, so POSITIVE is a surplus and NEGATIVE a deficit; capacity_status ("surplus"/"deficit"/"balanced") and capacity_note state this unambiguously. methodology_note is set only when the methodology does not change the numbers (it is then a label only).

Deterministically review an existing QA document (Test Plan, Test Strategy, or a test case list) against a six-dimension ISTQB/IEEE-829- grounded rubric (structure completeness, objectives & scope clarity, entry/exit criteria, traceability, measurability, risk coverage) — no LLM anywhere in this call path; write your own narrative from the returned findings. doc_type must be one of "auto", "test_plan", "test_strategy", "test_cases" — "auto" runs a cheap heading-keyword classifier and reports which type it assumed; an unrecognized value returns a structured {"error": "invalid_argument", ...} rather than raising. Documents under ~200 characters (after stripping this app's own AI-disclosure front matter/footer) return doc_type="insufficient_content" with overall_score=0 rather than an error, unless they carry an explicit QA signal (test plan/strategy/case wording, "Test N:" lines) and enough words to score — those get a (low) score with findings. In "auto" mode a weak but genuine QA document (a QA signal plus a core testing term) is scored as its most likely type instead of being rejected. Rejections carry a hint telling you to retry with an explicit doc_type. Each finding carries kb_citations resolved from the knowledge base for its citation queries — a finding with no resolvable source is returned with an empty kb_citations list rather than a fabricated one. Non-QA input returns status="not_a_qa_document" (doc_type equals the status, no score); oversize input returns status="input_too_large". Non- English input is still scored but score_reliable=false and language_warning explains the rubric is English-keyword based. detection_confidence says how sure the "auto" type guess was. Returns {doc_type, overall_score, dimension_scores, findings, stats, status, language, language_warning, score_reliable, detection_confidence, detection_note, hint, kb_version}.

Deterministically assess QA process maturity from a free-text project/ process description (or a pasted existing Test Strategy/Risk Register) — no LLM anywhere in this call path; write your own narrative from the returned findings. Scores 10 TMMi process areas (Level 2 Managed + Level 3 Defined) and returns an indicative_tmmi_level (1-3 — NEVER higher; Levels 4-5 require quantitative evidence a text description cannot substantiate, per TMMi's own no-skip rule — always read the returned disclaimer and never claim a certified TMMi level yourself). When the description signals an AI/ML system, also scores 7 EU AI Act Articles 9-15 readiness checks (ai_act_relevant=true, ai_act_dimension_scores populated); otherwise that dimension is omitted entirely (ai_act_relevant=false, empty dict) rather than scored as a false gap. Descriptions under ~200 characters (after stripping this app's own AI-disclosure front matter/footer) return indicative_tmmi_level=0 with empty findings rather than an error (status="insufficient_content"). Input with essentially no software- testing/QA vocabulary (a recipe, meeting notes) returns status="not_a_qa_description" with indicative_tmmi_level=null, a message and no findings; a successful assessment has status="ok". Mentions of AI that are negated ("no machine learning is used", "AI-free") do not switch the EU AI Act dimension on. Each finding carries kb_citations resolved from the knowledge base for its citation queries — a finding with no resolvable source is returned with an empty kb_citations list rather than a fabricated one. When ai_act_relevant=true, ai_act_note carries a fixed caveat that risk-tier classification (whether the system is legally "high-risk") is a determination this tool does not make — the user/team must confirm that independently; ai_act_note is empty when ai_act_relevant=false. Returns {status, indicative_tmmi_level, tmmi_dimension_scores, ai_act_relevant, ai_act_dimension_scores, ai_act_note, findings, disclaimer, detection_caveat, language, language_warning, score_reliable, keyword_list_warning, stats, kb_version}. Detection is keyword-based and can under-score paraphrased practices (see detection_caveat); non-English input sets score_reliable=false.

Deterministic test-results health metrics (flaky / ever-failing / never-run / slowest / failure clustering) from real test execution data — no LLM anywhere in this call path; write your own narrative from the returned numbers. Provide exactly one of junit_xml or csv_text. junit_xml is normally one JUnit XML report string for one run (accepts both a and a bare root); to analyze flakiness across MULTIPLE runs in one call, pass a JSON array of {"run_id": "...", "xml": "..."} objects (or simply a JSON array of XML strings, auto-named run-1, run-2, ...; repeated run_ids are kept as separate runs with a #2/#3 suffix and a warning) instead — either as a genuine JSON array/list argument, or as a string starting with "[" (some MCP clients stringify array arguments; both forms are accepted). csv_text needs a test-name column (name | test_name | test | testcase | title) and a status column (status | result | outcome); headers are matched case-insensitively. Status synonyms are accepted (pass/ok/success, fail/failure/ko, error/err, skip/ignored/pending). Optional columns: classname (or suite), run_id (or run/build; default "csv"), duration_s (or duration/time/elapsed, in seconds; a *_ms header or "350ms" values mean milliseconds), message (or error/details). Dropped rows and unrecognised columns are listed in warnings. If NO test could be parsed (wrong columns, empty or header-only CSV, HTML or non-JUnit XML, malformed XML) the call returns {"error": "no_tests_found", "message", "warnings"} instead of an empty 0% result. reference_tests, if given, is a list of test identities ("classname::name", or just "name" when there is no classname) expected to have run — any absent from the results are reported under never_run. A bare "name" also matches when exactly one executed test has that name (ambiguous bare names are not guessed; a warning explains). Skipped tests are NOT failures: they are excluded from pass rates and from the flaky/ever-failing verdicts and are reported separately (skipped, skipped_executions). Flaky = pass_rate (over non-skipped executions) strictly between flaky_min and flaky_max with at least 3 such executions; ever-failing = zero passes across at least 3 non-skipped executions. flaky_min/flaky_max must satisfy 0 <= flaky_min < flaky_max <= 1. Tests with fewer executions are left out of both lists; with fewer than 3 runs a warning says so, and tests that both passed and failed are listed under mixed_outcome (needs more runs). An empty flaky list on 1-2 runs means not enough data, not a stable suite. Malformed/oversized input never raises — it returns a structured {"error": "invalid_argument" | "no_tests_found", ...}. Returns the full ResultsAnalysis as JSON (runs, total_tests, executions, overall_pass_rate, flaky, ever_failing, never_run, slowest, failure_clusters, per_run, warnings, skipped_executions, skipped, mixed_outcome).