Retrieve grounding chunks from the QA knowledge base (ISTQB, OWASP, IEEE, ISO standards; testing methodologies; audit/evaluation frameworks; the EU AI Act). Returns {"chunks": [{"source", "category", "text", "score"}], "kb_version"}. category, if given, must be one of: Standard, Methodology, Article, Expert Knowledge, Audit/Evaluation — an unrecognized value 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. Success returns the full EstimationData as JSON (baseline, multipliers, pert_activities, capacity, risk_buffer_days, final_effort_min/max, confidence_level/confidence_score).

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. 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. Returns {doc_type, overall_score, dimension_scores, findings, stats, 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. 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 {indicative_tmmi_level, tmmi_dimension_scores, ai_act_relevant, ai_act_dimension_scores, ai_act_note, findings, disclaimer, stats, kb_version}.

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 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 columns: required name/classname/status (passed|failed|error|skipped), optional run_id/duration_s/message. reference_tests, if given, is a list of test identities ("classname::name") expected to have run — any absent from the results are reported under never_run. Flaky = pass_rate strictly between flaky_min and flaky_max with at least 3 executions; fewer executions is reported as insufficient data, not flaky. Malformed/oversized input never raises — it returns a structured {"error": "invalid_argument", ...}. Returns the full ResultsAnalysis as JSON (runs, total_tests, executions, overall_pass_rate, flaky, ever_failing, never_run, slowest, failure_clusters, per_run, warnings).