Skip to main content
Glama
gvasile29

qai-consultant-mcp

by gvasile29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

assess_qa_maturity

Assess QA process maturity from a project description, scoring TMMi process areas and EU AI Act readiness for AI/ML systems. Get an indicative maturity level and actionable findings without LLM bias.

Instructions

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}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_descriptionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.5.2

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden. It explicitly reveals deterministic no-LLM behavior, the TMMi level cap rationale, conditional AI Act scoring, empty-findings behavior for short inputs, citation resolution policy, and the fixed caveat about high-risk classification.

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 description is long but dense; each clause adds meaningful behavioral or output information. It is front-loaded with the core purpose and no-LLM caveat, though a bulleted structure could improve scannability for such a complex tool.

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?

There is no output schema and no annotations, so the description must fully define the return contract. It lists the complete return object, explains conditional fields like ai_act_dimension_scores and ai_act_note, and covers edge cases such as short descriptions and unresolvable KB citations.

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

Parameters5/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 the lone project_description parameter. It explains that the parameter can contain a free-text description or a pasted Test Strategy/Risk Register, and it notes the ~200-character threshold that changes return behavior.

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: 'Deterministically assess QA process maturity.' It further distinguishes the tool by detailing TMMi scoring, EU AI Act readiness checks, and the exact return payload, making its purpose unmistakable relative to sibling 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?

It clearly states when to use the tool: with a free-text project/process description or a pasted Test Strategy/Risk Register. It also explains the behavior for very short descriptions, giving the agent clear context for invocation, though it does not explicitly name sibling alternatives or exclusion conditions.

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

Deploy Server

Other Tools