test-mcp-tool

name	test-mcp-tool
description	Add or update unit and end-to-end coverage for a clio MCP tool. Use when changing MCP tool arguments, tool names, command wiring, prompts, resources, destructive behavior, or when creating a new MCP tool that needs contract tests and E2E coverage.

Test MCP Tool

Test MCP tools at two levels: in-process contract tests and external-process end-to-end tests.

Coverage Plan

Cover all meaningful argument combinations.

• Test the happy path for each exposed tool method.
• Test every invocation mode separately when the tool exposes more than one method.
• Test negative outcomes with invalid inputs or missing dependencies.
• Cover all possible combinations of optional arguments, especially arguments that are not marked [Required].
• When optional flags change execution mode, add dedicated tests for each mode instead of assuming one representative case is enough.

Unit Tests

Use clio.tests to verify:

• tool discovery names
• argument-to-options mapping
• command resolution path
• destructive flags or prompt/resource alignment when applicable

At minimum, assert that each MCP method:

• uses the tool-name constant from the production tool class
• maps every argument into the expected command options
• preserves defaults for omitted optional arguments
• rejects or reports invalid inputs as expected

End-to-End Tests

Use clio.mcp.e2e for every new or updated MCP tool.

• Start the real clio mcp-server process over stdio.
• Discover the tool by the production constant, not a duplicated string literal.
• Verify side effects in the target system, not only MCP success shape.
• For destructive tests, require explicit opt-in and a sandbox target.
• If the current harness cannot cover the tool yet, extend the harness in the same task instead of omitting E2E coverage.

Assertion Rules

Always use explicit AAA structure and separate important assertions into distinct Allure steps.

Required output assertions:

• On success, assert at least one Info message type in the returned execution log.
• On failure, assert an Error message type when execution output is available.
• If the MCP server surfaces a top-level invocation error instead of raw command output, still assert human-readable diagnostics and verify no unintended side effects.

Also assert:

• IsError state matches the scenario
• exit code matches the scenario
• side effects happened on success
• side effects did not happen on failure

Tool Name Rule

Tests must reference tool names from constants defined on the production tool class.

Example:

private const string ToolUnderTestTag = ClearRedisTool.ClearRedisByEnvironmentName;

Do not hardcode MCP tool names in test files.

Finish Checklist

• Unit coverage updated in clio.tests
• E2E coverage updated in clio.mcp.e2e
• Optional-argument combinations reviewed explicitly
• Info and Error message-type assertions added where relevant
• Allure metadata added for MCP E2E tests
• AGENTS or local guidance updated when a new MCP testing convention is introduced