de en es ja ko ru zh

tailtest-cline

Name: tailtest-cline
Author: avansaber

by avansaber

Overview Schema Source Related Servers Discussions Admin

Python

Local

tailtest-cline

Tú construyes. Nosotros cubrimos. En más de 8 editores a la vez.

tailtest-cline es un plugin de Cline que genera y ejecuta pruebas automáticamente cada vez que el agente edita un archivo fuente. Utiliza la misma capa de reglas R1-R15 que las otras variantes de tailtest. Modo de prueba adversarial (V13) disponible desde el primer día.

Alcance de Cline: VS Code, Cursor, IDEs de JetBrains, Antigravity, Zed, Neovim, VSCodium, Windsurf, además de la CLI de Cline. Un solo plugin, más de ocho editores.

Documentación completa en tailtest.com/docs/cline

Qué es diferente de las otras variantes

Cline no tiene hooks (como PostToolUse de Claude Code, afterFileEdit de Cursor o Stop de Codex). En su lugar, tailtest-cline utiliza tres primitivas nativas de Cline:

.clinerules/ contiene la capa de reglas (R1-R14 + modo adversarial R15)
Servidor tailtest-mcp (este repositorio) proporciona herramientas estructuradas para el agente: tailtest_setup, tailtest_scenario_plan, tailtest_classify_failures, tailtest_pick_template, tailtest_ping
Memory Bank (tailtestContext.md) mantiene el perfil por proyecto a través de las sesiones de Cline

La política determinista (niveles de profundidad, conteos adversariales R15, plantillas de framework, rutas de archivo) reside en el código del servidor MCP en lugar del texto de las reglas. El agente llama a las herramientas cuando necesita andamiaje en lugar de depender de la memoria de reglas durante sesiones largas.

Related MCP server: OpenTester

Instalación

Tres rutas de instalación:

1. Marketplace de MCP de Cline (recomendado; un clic)

Abre el panel de extensiones de Cline dentro de tu IDE. Busca tailtest. Haz clic en instalar. Cline clona, instala dependencias y registra el servidor en cline_mcp_settings.json automáticamente.

2. Instalación directa desde GitHub

Pega https://github.com/avansaber/tailtest-cline en el diálogo de instalación del servidor MCP de Cline. Cline realiza el mismo flujo de clonar + instalar + registrar.

3. Edición manual de `cline_mcp_settings.json`

{
  "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"
      ]
    }
  }
}

Primera ejecución

Después de la instalación, escribe en el chat de Cline: "set up tailtest in this project".

Cline llama a tailtest_setup. La herramienta detecta el lenguaje / framework / ejecutor, escribe .clinerules/, escribe .clinerules/workflows/, inicializa memory-bank/tailtestContext.md e inicializa .tailtest/config.json + .tailtest/session.json. Idempotente: los archivos existentes se conservan.

Importante: Cline no recarga automáticamente .clinerules a mitad de una conversación. Inicia una nueva conversación (o recarga la ventana) para activar.

Dos modos de operación

Modo manual (predeterminado)

Invocas el ciclo de prueba explícitamente:

/tailtest-test <archivo> -- ejecuta el ciclo en un archivo específico
/tailtest hunt <archivo> -- pasada adversarial de una sola vez en un archivo específico
O lenguaje natural ("test the file I just edited")

Cada paso (escritura de archivo, comando de terminal, llamada MCP) solicita aprobación. Es un valor predeterminado más seguro para usuarios primerizos.

Modo automático (opcional)

Habilita la aprobación automática de Cline para: Editar archivos (espacio de trabajo), Ejecutar comandos seguros, Usar servidores MCP. Luego ejecuta /tailtest-mode auto y recarga. Después de cada edición, tailtest dispara el ciclo de prueba automáticamente.

Modo Plan / Act (bonificación de UX nativa de Cline)

El interruptor Plan / Act de Cline se asigna a la convención SCENARIO PLAN de tailtest: el modo Plan produce el SCENARIO PLAN (solo lectura); revisa y modifica; el modo Act escribe el archivo de prueba, lo ejecuta y aplica la clasificación R12. Recomendado para archivos de alta importancia.

Configuración

.tailtest/config.json:

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

Opciones de profundidad:

simple -- 2-3 escenarios de camino feliz (happy-path)
standard -- 5-8 escenarios incluyendo 2+ pruebas adversariales (predeterminado)
thorough -- 10-15 escenarios incluyendo 4+ pruebas adversariales
adversarial -- 8-12 escenarios sesgados hacia la ruptura

Consulta tailtest.com/docs/config para ver todas las opciones y tailtest.com/docs/adversarial para detalles del modo adversarial.

Otras variantes de tailtest

Misma capa de reglas R1-R15, mismo modo de prueba adversarial, diferente integración de host. Este repositorio es la variante para Cline.

tailtest -- Plugin de Claude Code (basado en hooks)
tailtest-cursor -- Plugin de Cursor (basado en hooks)
tailtest-codex -- Plugin de Codex CLI (basado en hooks)
tailtest-cline -- Plugin de Cline (basado en MCP; este repositorio)

Consulta tailtest.com/demo/cline para ver un recorrido en vivo de esta variante, o tailtest.com/comparison para una matriz de características entre los cuatro.

Licencia

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.1Apr 27, 2026
- First observedtailtest_classify_failures
- First observedtailtest_pick_template
- First observedtailtest_ping
- First observedtailtest_scenario_plan
- First observedtailtest_setup

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored 2026-05-10 02:25 across 5 tools

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

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

EdgehoundOAuth
io.github.Energixe
Writes adversarial test suites for AI-built code. Your agent's test engineer.
Testing & QA Tools Autonomous Agents Developer Tools
1
DiffCI A
io.github.adityankale190895
Change-aware CI validation and affected-test guidance for coding agents.
CI/CD & DevOps Testing & QA Tools Coding Agents
31
PlaywrightGen
com.playwrightgen
Approved test intent, reviewed Playwright automation and run evidence, inside your editor.
Testing & QA Tools Browser Automation Developer Tools
1
Testiny Test Management AOAuth
io.testiny
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Testing & QA Tools Project Management
152

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 9 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 7 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 6 months ago (2026-04-02 03:15 UTC)
8
-
rush
Code Analysis Testing & QA Tools Developer Tools
jamesdsizemore
A
license
C
quality
A
maintenance
Agentic code-quality CLI and stdio MCP server that runs real Python and JS/TS quality engines (Ruff, pytest, ESLint, Prettier, Vitest, etc.) for linting, testing, and reviewing code.
Updated 2 days ago (2026-10-10 17:20 UTC)
79
MIT

tailtest-cline

Qué es diferente de las otras variantes

Instalación

1. Marketplace de MCP de Cline (recomendado; un clic)

2. Instalación directa desde GitHub

3. Edición manual de cline_mcp_settings.json

Primera ejecución

Dos modos de operación

Modo manual (predeterminado)

Modo automático (opcional)

Modo Plan / Act (bonificación de UX nativa de Cline)

Configuración

Otras variantes de tailtest

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

3. Edición manual de `cline_mcp_settings.json`