MCP server providing QA automation tools for insurance domain testing. Provides test execution, synthetic data generation, code analysis, insurance business-rule validation, BDD scenario generation, Playwright test generation, multi-agent code review, semantic search, chaos testing, mock enterprise connectors (ADO, Zephyr, SQL), and a natural-language QA workflow orchestrator.
23 tools with significant quality gaps. Most tools have basic descriptions (50-150 chars) but lack parameter-level detail. Input schemas are present but sparse: many parameters lack descriptions or type constraints. No output schemas documented. Error handling is minimal, no recovery guidance, categorization, or actionable error messages. Tool naming is generally clear (verb_noun pattern), but composition issues exist: tools like 'run_qa_workflow' and 'auto_generate_tests' are vague. No tool annotations (readOnlyHint/destructiveHint). Two write tools (update_test_result, run_qa_workflow) lack confirmation/dry-run patterns. Baseline: 549 production tools average 194 chars for descriptions and 72 chars for params; this server averages ~100 chars for descriptions and many params have no description at all.
Parse coverage reports and identify uncovered code paths.
Analyze Python source and generate test cases automatically.
Generate chaos test scenarios from an OpenAPI specification. Produces boundary value, type confusion, and edge case tests for each endpoint.
Analyze test suite health: test count, naming, structure, and distribution.
Run tests multiple times and detect non-deterministic (flaky) results.
Generate BDD/Gherkin test scenarios for insurance workflows.
Generate Playwright test scripts from natural language workflow descriptions.
No output schemas documented. Tools return strings but LLMs cannot parse structure, forcing unstructured text parsing and wasting tokens. Pattern:response-shaper requires documented return types.
Parameter descriptions missing or minimal. 'claim_data' and 'policy_data' accept dicts but lack field documentation. LLMs cannot infer required fields, types, or constraints. Pattern:tool-description requires descriptions for every parameter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Generate synthetic insurance test data (policies, claims, billing).
Get current test cycles from Zephyr test management (mock).
Get a test plan linked to a user story (mock).
Get user stories with acceptance criteria from ADO/Jira (mock). Returns realistic insurance domain stories for PolicyCenter, ClaimCenter, BillingCenter.
Run Python code quality checks: complexity, naming, type hints, docstrings.
Return mock insurance data from a simulated database table.
Run multi-agent code review (security, performance, style agents).
Run accessibility and performance audit concepts on a URL.
Execute a natural-language QA workflow orchestration.
Run pytest on a project and return a pass/fail summary.
Search documents using semantic similarity (embeddings or TF-IDF fallback).
Analyze source code and suggest missing test cases. Inspects functions for branches, error handling, and loops, then recommends specific tests to add.
Update a test execution result in Zephyr (mock).
Validate an insurance claim record against P&C business rules. Checks loss dates, amounts, status, and LOB-specific constraints.
Run data quality checks on a mock database table. Checks for nulls in non-nullable columns, orphan references, and business-rule violations.
Validate an insurance policy record against underwriting rules. Checks dates, premium range, coverage limits, and status consistency.
No error handling guidance. Tools return strings but do not categorize errors as retryable, user-fixable, or fatal. No recovery hints (e.g. 'Try search_users() first'). Pattern:recovery-guide requires actionable error messages.
No tool annotations. Write tools (update_test_result, run_qa_workflow) lack destructiveHint. Read-only tools lack readOnlyHint. Pattern:tool-annotations enables agents to reason about side effects.
Vague tool names and composition issues. 'run_qa_workflow' and 'auto_generate_tests' are generic and lack specificity. 'run_qa_workflow' accepts a natural-language description but provides no schema or structure, LLMs cannot predict outcomes. Pattern:tool requires verb_noun naming and single responsibility.