What can you do with this server?

This MCP server integrates AI-driven testing into Cline, enabling automated test generation, classification, and project setup across multiple editors. * tailtest_ping: Health check to verify the server is reachable and retrieve its version. * tailtest_setup: Bootstraps tailtest in a project by detecting language/framework/runner, writing .clinerules/ rule packs and slash workflows, seeding the Memory Bank (tailtestContext.md), and initializing .tailtest/config.json and session.json — idempotently, without overwriting existing files. Supports manual or auto mode. * tailtest_scenario_plan: Generates structured scaffolding for composing test scenarios for a given source file, including language/framework detection, depth settings, adversarial count requirements, baseline scenarios, and test file path guidance. * tailtest_classify_failures: Parses test runner output (pytest, jest, vitest, mocha) and classifies failures into categories — real_bug, environment, test_bug, or unknown — with detailed metadata and summary counts. * tailtest_pick_template: Returns the full framework-specific test template for a source file, including baseline scenarios, framework-specific patterns (e.g., NestJS, Spring, Flask), and test file path conventions. When in auto mode, the server can automatically pick up file edits, generate production-shaped test scenarios (including adversarial mode), run them, and return structured failure data. Testing depth is configurable via levels such as simple, standard, thorough, and adversarial.

Which integrations are available for this server?

Enables AI software testing for Cline within JetBrains IDEs, allowing automated test generation and execution on code changes. Enables AI software testing for Cline within Neovim, allowing automated test generation and execution on code changes. Enables AI software testing for Cline within VSCodium, allowing automated test generation and execution on code changes.

de en es ja ko ru zh

tailtest-cline

by avansaber

Overview Schema Related Servers Score Discussions

Python

Local

tailtest-cline -- AI software testing for Cline (8+ editors)

License: MIT Tests Version MCP Editors

You build. Claude builds. tailtest makes sure it works -- across 8+ editors at once.

tailtest-cline is the open-source AI software testing layer for Cline, the autonomous coding agent that runs across 8+ editors (VS Code, Cursor, JetBrains IDEs, Antigravity, Zed, Neovim, VSCodium, Windsurf, plus the Cline CLI). MCP-driven test generation: every time Cline edits a file, tailtest's MCP server picks up the change, generates production-shaped scenarios via the R1-R15 rule layer, runs them, and returns structured failure data to Cline. Adversarial mode (R15) included from day one.

Open source (MIT), no telemetry, no SaaS account. Same R1-R15 rule layer + adversarial mode as the Claude Code, Cursor, and Codex CLI variants -- 1,234 plugin tests total across the four hosts.

Cline reach: VS Code, Cursor, JetBrains IDEs, Antigravity, Zed, Neovim, VSCodium, Windsurf, plus the Cline CLI. One plugin, eight-plus editors.

What's different from the other variants

Cline does not have hooks (Claude Code's PostToolUse, Cursor's afterFileEdit, Codex's Stop). Instead, tailtest-cline uses three Cline-native primitives:

.clinerules/ carries the rule layer (R1-R14 + R15 adversarial mode)
tailtest-mcp server (this repo) provides structured tools for the agent: tailtest_setup, tailtest_scenario_plan, tailtest_classify_failures, tailtest_pick_template, tailtest_ping
Memory Bank (tailtestContext.md) holds the per-project profile across Cline sessions

The deterministic policy (depth tiers, R15 adversarial counts, framework templates, file paths) lives in MCP server code rather than rule text. The agent calls the tools when it needs scaffolding rather than relying on rule recall over long sessions.

Related MCP server: OpenTester

Install

Three install paths:

1. Cline MCP Marketplace (recommended; one click)

Open Cline's Extensions panel inside your IDE. Search tailtest. Click install. Cline clones, installs deps, registers the server in cline_mcp_settings.json automatically.

2. Direct GitHub install

Paste https://github.com/avansaber/tailtest-cline into Cline's MCP server install dialog. Cline does the same clone + install + register flow.

3. Manual `cline_mcp_settings.json` edit

{
  "mcpServers": {
    "tailtest": {
      "command": "python",
      "args": ["-m", "src.server"],
      "cwd": "/path/to/tailtest-cline/mcp_server",
      "alwaysAllow": [
        "tailtest_ping",
        "tailtest_scenario_plan",
        "tailtest_classify_failures",
        "tailtest_pick_template"
      ]
    }
  }
}

First run

After install, type in Cline chat: "set up tailtest in this project".

Cline calls tailtest_setup. The tool detects language / framework / runner, writes .clinerules/, writes .clinerules/workflows/, seeds memory-bank/tailtestContext.md, and initialises .tailtest/config.json + .tailtest/session.json. Idempotent: existing files preserved.

Important: Cline does not auto-reload .clinerules mid-conversation. Start a new conversation (or reload the window) to activate.

Two operating modes

Manual mode (default)

You invoke the test cycle explicitly:

/tailtest-test <file> -- run the cycle on a specific file
/tailtest hunt <file> -- one-shot adversarial pass on a specific file
Or natural language ("test the file I just edited")

Each step (file write, terminal command, MCP call) prompts for approval. Safer default for first-time users.

Auto mode (opt-in)

Enable Cline auto-approve for: Edit files (workspace), Execute safe commands, Use MCP servers. Then run /tailtest-mode auto and reload. After every edit, tailtest fires the test cycle automatically.

Plan / Act mode (Cline-native UX bonus)

Cline's Plan / Act toggle maps to tailtest's SCENARIO PLAN convention: Plan mode produces the SCENARIO PLAN (read-only); review and amend; Act mode writes the test file, runs it, and applies R12 classification. Recommended for high-stakes files.

Configuration

.tailtest/config.json:

{
  "depth": "standard",
  "mode": "manual"
}

Depth options:

simple -- 2-3 happy-path scenarios
standard -- 5-8 scenarios including 2+ adversarial probes (default)
thorough -- 10-15 scenarios including 4+ adversarial probes
adversarial -- 8-12 scenarios biased toward breakage

See tailtest.com/docs/config for all options and tailtest.com/docs/adversarial for adversarial mode details.

Other tailtest variants

Same R1-R15 rule layer, same adversarial test mode, different host integration. This repo is the Cline variant.

tailtest -- Claude Code plugin (hook-driven)
tailtest-cursor -- Cursor plugin (hook-driven)
tailtest-codex -- Codex CLI plugin (hook-driven)
tailtest-cline -- Cline plugin (MCP-driven; this repo)

See tailtest.com/demo/cline for a live walkthrough of this variant, or tailtest.com/comparison for a feature matrix across all four.

License

MIT.

Available Tools

5 tools

tailtest_classify_failuresA

Parse runner output (pytest, jest, etc.) into structured failure records and apply heuristic R12 classification. Returns failures with type (real_bug / environment / test_bug / unknown), reason, test name, file, line, error type, message, and a summary count per R12 category. The agent verifies or overrides the heuristic when context warrants.

ParametersJSON Schema

Name	Required	Description	Default
`runner_output`	Yes	Stdout (and optionally stderr) from the test runner.
`runner`	No	Runner name. Defaults to pytest.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations exist, so the description must fully disclose behavior. It details the return fields (type, reason, test name, etc.) and mentions the agent can verify/override. It does not mention side effects, which seems acceptable for a read-only classification. Could note that no state is modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each adding essential information: what it does, what it returns, and how the agent interacts. No unnecessary words, front-loaded with the main action. Highly concise and well-structured.

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?

Without an output schema, the description fully covers the return value details (fields and categories). It explains the heuristic and agent override capability. No gaps are apparent for the tool's complexity. Enough for an agent to correctly invoke and interpret results.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The description confirms the 'runner' parameter defaults to pytest, which is already in the schema. It does not add significant new meaning beyond the schema, but it does tie parameters to the overall classification context, earning a baseline score.

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 clearly states the tool's purpose: parsing runner output and applying heuristic R12 classification. It specifies the exact resources (runner output, runner) and outputs (failure types, categories). The tool distinguishes well from siblings (none involve classification).

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?

The description implies usage context: use when you have test runner output to classify. It does not explicitly exclude scenarios or name alternatives, but sibling tools are clearly different (template, ping, plan, setup), so confusion is low. A brief 'when not to use' would improve it.

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

tailtest_pick_templateA

Return the full framework R2 template for a given source file: language baseline scenarios, framework baseline scenarios, framework-specific test pattern (e.g., NestJS Test.createTestingModule, Spring @WebMvcTest, Flask test_client), and test file path pattern. Returns just language baseline when no framework matches.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Relative or absolute path to the source file under test.
`project_root`	No	Project root directory. Defaults to the current working directory.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full responsibility. It discloses the fallback behavior ('Returns just language baseline when no framework matches') and describes the output components. However, it does not mention error conditions or side effects, but given the read-only nature, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, starts with the verb 'Return', and contains zero redundant information. Every phrase contributes to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters and no output schema, the description adequately explains the return value and the fallback. It lacks mention of error cases or supported languages, but is otherwise complete for a straightforward read tool.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the parameter descriptions are minimal. The tool description adds value by explaining that the output is determined by the file_path and project_root, and contextually connects parameters to the template resolution. This goes beyond the schema.

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 clearly states it returns a framework R2 template for a given source file, listing specific components (language baseline scenarios, framework baseline scenarios, etc.). This is a specific verb+resource and differentiates from sibling tools like tailtest_classify_failures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for picking a template for a source file but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use or naming sibling tools for comparison.

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

tailtest_pingA

Health check. Returns server version and confirms the MCP server is reachable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but the description honestly discloses the read-only nature and return of server version. No hidden behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence with no redundancy, efficiently conveying the tool's purpose.

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?

For a simple ping tool with no parameters or output schema, the description fully covers its behavior and return value.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; schema coverage is 100%. Baseline for 0 params is 4.

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 clearly states it is a health check that returns server version and confirms reachability, distinguishing it from sibling tools like classification or setup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied as a health check, but no explicit guidance on when to use vs alternatives or when not to use.

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

tailtest_scenario_planA

Return structured scaffolding the agent uses to write its SCENARIO PLAN: language, framework, depth, R15 adversarial count requirement, language and framework baseline scenarios, test file path, and prose instructions. The agent uses this scaffolding to compose the actual SCENARIO PLAN scenario lines.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Relative or absolute path to the source file under test.
`project_root`	No	Project root directory. Defaults to the current working directory.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full behavioral burden. It details the returned content but does not disclose side effects, permissions, or whether the operation is read-only. It is adequate but lacks depth on behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose, and efficiently lists all components without redundancy or unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lists the fields returned but does not specify the output format (e.g., JSON structure) or address error cases. Given no output schema, the agent may need to infer the structure, but the listing is helpful.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover file_path and project_root with 100% coverage. The description does not add additional meaning beyond what the schema provides, so it is at baseline.

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 clearly states the tool returns 'structured scaffolding' for writing a scenario plan, listing specific components like language, framework, depth, R15 adversarial count, baseline scenarios, test path, and instructions. It distinguishes from sibling tools by focusing on scaffolding generation.

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?

The description provides context that the scaffolding is used before composing the actual scenario plan, but it does not explicitly exclude other uses or compare with alternatives like other tailtest tools. The usage is implied.

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

tailtest_setupA

Bootstrap entry point for tailtest in a Cline project. Detects language / framework / runner, writes the .clinerules/ rule pack, writes .clinerules/workflows/ slash workflows, seeds Memory Bank with tailtestContext.md (a 7th file alongside the 6 core ones; existing files are not overwritten), and initialises .tailtest/config.json + session.json. Returns a structured report including the user-facing 'reload required' warning (Cline does not auto-reload .clinerules mid-conversation).

ParametersJSON Schema

Name	Required	Description	Default
`project_root`	No	Project directory. Defaults to the current working directory.
`mode`	No	manual (default): user invokes /tailtest-test after edits. auto: tailtest fires after every edit (requires Cline auto-approve).

TDQS

A4.6/5.0

Behavior5/5

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

No annotations exist, so the description fully carries the burden. It discloses all major effects: file creation (rules, workflows, memory bank, configs), non-overwriting of existing files, and the reload warning. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3-4 sentences) yet packed with information. It front-loads the main purpose and each sentence serves a clear role without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description partially explains the return value (structured report with reload warning) but omits details about report fields or structure. For a tool that modifies multiple files, this is a minor gap.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds valuable context beyond the schema by explaining the implications of the mode parameter (manual vs. auto) and what triggers each. This adds semantic richness.

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 clearly states the tool's purpose as the bootstrap entry point for tailtest, listing specific actions like detecting language, writing rule packs, and initializing configs. It is distinctly different from sibling tools (classify, pick, ping, scenario plan).

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?

The description implies usage as the first step in tailtest setup, but it does not explicitly state when to use or avoid it. It provides clear context but lacks explicit exclusions or alternative tool guidance.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: setup, health check, template selection, scenario planning, and failure classification. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent snake_case pattern with the prefix 'tailtest_' and a verb_noun structure (e.g., tailtest_classify_failures, tailtest_pick_template). No deviations.

Tool Count5/5

With 5 tools, the server is tightly scoped to test analysis and scaffolding. Each tool earns its place without being too few or too many for the domain.

Completeness4/5

The tools cover setup, health, template selection, scenario planning, and failure classification. While not a full test framework, it appears complete for its intended planning/analysis purpose. Minor gap: no tool for running tests or generating code.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gjalla
io.gjalla
Production-readiness for your AI coding agents.
Coding Agents Agent Orchestration
22
Future AGI
com.futureagi
Build, test, monitor & improve AI with Future AGI via Claude, Cursor, Windsurf & more.
AI & Machine Learning Monitoring Developer Tools
2
Apuchat A
io.github.opcastil11
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Communication Agent Orchestration
181
NoClick
io.github.noclickapp
Build agents to automate any background task. Works with your ChatGPT/Claude subscription.
Autonomous Agents App Automation
1

Related MCP Servers

MCP Universal Test Suite
Testing & QA Tools Developer Tools Code Analysis
gigici99
F
license
Not graded
quality
D
maintenance
Enables AI assistants to analyze Java and Web projects, automatically generate unit tests (JUnit) and end-to-end tests (Selenium), and execute them directly through Maven or NPM commands.
Updated 8 months ago (2026-01-14 14:16 UTC)
OpenTester
Testing & QA Tools Developer Tools Code Execution
kznr02
A
license
Not graded
quality
C
maintenance
OpenTester is a testing execution engine designed for AI coding tools (Claude Code, Cursor, OpenCode, etc.). It provides a unified DSL format and MCP interface, enabling Agents to generate, execute, and manage test cases, achieving an automated "code-test-fix" workflow.
Updated 5 months ago (2026-03-23 08:57 UTC)
28
MIT
Test Case Generator MCP Server
Testing & QA Tools Project Management
prem2230
F
license
A
quality
D
maintenance
Auto-generates and manages test cases for any project from feature descriptions, with tools for adding, listing, updating, and exporting test cases via Claude.
Updated 5 months ago (2026-04-02 03:15 UTC)
8
TestPilot MCP
Testing & QA Tools Developer Tools
Kirit2121
A
license
Not graded
quality
D
maintenance
Enables AI models (Claude, ChatGPT, GitHub Copilot) to run and analyze local tests, rerun failures, and orchestrate QA workflows using existing UI and API test frameworks.
Updated 9 months ago (2025-12-18 13:08 UTC)
19
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avansaber/tailtest-cline'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

tailtest-cline -- AI software testing for Cline (8+ editors)

What's different from the other variants

Install

1. Cline MCP Marketplace (recommended; one click)

2. Direct GitHub install

3. Manual cline_mcp_settings.json edit

First run

Two operating modes

Manual mode (default)

Auto mode (opt-in)

Plan / Act mode (Cline-native UX bonus)

Configuration

Other tailtest variants

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

3. Manual `cline_mcp_settings.json` edit