Skip to main content
Glama

get_test_report

Retrieve detailed local test reports for specific test runs to analyze results and identify issues in WordPress/WooCommerce plugin testing.

Instructions

Get a detailed local test report for a specific test run. Only available for tests run locally (not managed tests).

⚠️ QIT CLI not detected. QIT CLI not found. Please install it using one of these methods:

  1. Via Composer (recommended): composer require woocommerce/qit-cli --dev

  2. Set QIT_CLI_PATH environment variable: export QIT_CLI_PATH=/path/to/qit

  3. Ensure 'qit' is available in your system PATH

For more information, visit: https://github.com/woocommerce/qit-cli

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
test_run_idYesTest run ID to get report for

Implementation Reference

  • Executes the 'qit test report' CLI command for the given test_run_id, handles output including 'not found' cases, and returns formatted content with error flag.
    handler: async (args: { test_run_id: string }) => {
      const cmdArgs = ["report", args.test_run_id];
      const result = await executeQitCommand(cmdArgs);
    
      const output = result.stdout || result.stderr || "";
    
      // Check if it's a "report not found" error vs actual report content
      if (output.includes("Could not find") || output.includes("not found")) {
        return {
          content: `Report not available locally. This may be a managed test (run on GitHub Actions) or the local report files were cleaned up. Use get_test_result to see the test status and result URL.`,
          isError: false,
        };
      }
    
      // If we got output, return it (even with exit code 1 for failed tests)
      if (output) {
        return {
          content: output,
          isError: false,
        };
      }
    
      return {
        content: "No report found",
        isError: true,
      };
    },
  • Zod input schema requiring a single string parameter 'test_run_id'.
    inputSchema: z.object({
      test_run_id: z.string().describe("Test run ID to get report for"),
    }),
  • The get_test_report tool is registered by spreading testResultsTools into the allTools object, which is imported and used by the MCP server.
    export const allTools = {
      ...authTools,
      ...testExecutionTools,
      ...testResultsTools,
      ...groupsTools,
      ...environmentTools,
      ...packagesTools,
      ...configTools,
      ...utilitiesTools,
    };
  • src/server.ts:25-38 (registration)
    MCP server lists all tools including get_test_report by iterating over allTools.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      // Check if QIT CLI is available
      const cliInfo = detectQitCli();
    
      const tools = Object.entries(allTools).map(([_, tool]) => ({
        name: tool.name,
        description: cliInfo
          ? tool.description
          : `${tool.description}\n\n⚠️ QIT CLI not detected. ${getQitCliNotFoundError()}`,
        inputSchema: zodToJsonSchema(tool.inputSchema),
      }));
    
      return { tools };
    });
  • src/server.ts:41-75 (registration)
    MCP server handles calls to get_test_report by looking up the tool in allTools, validating args with its schema, and invoking its handler.
    server.setRequestHandler(CallToolRequestSchema, async (request) => {
      const { name, arguments: args } = request.params;
    
      const tool = allTools[name as ToolName];
    
      if (!tool) {
        return {
          content: [
            {
              type: "text",
              text: `Unknown tool: ${name}`,
            },
          ],
          isError: true,
        };
      }
    
      try {
        // Validate input
        const validatedArgs = tool.inputSchema.parse(args);
    
        // Execute tool
        // eslint-disable-next-line @typescript-eslint/no-explicit-any
        const result = await (tool.handler as (args: any) => Promise<{ content: string; isError: boolean }>)(validatedArgs);
    
        return {
          content: [
            {
              type: "text",
              text: result.content,
            },
          ],
          isError: result.isError,
        };
      } catch (error) {
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the tool is only for local tests, it fails to describe what 'detailed report' contains, whether it's read-only or has side effects, authentication requirements, or error handling. The CLI installation warning is procedural rather than behavioral context about the tool itself.

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

Conciseness2/5

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

The description is poorly structured with significant waste. The first sentence is useful, but the extensive CLI installation warning (7 lines) belongs in error handling or prerequisites, not the core description. This creates noise and buries the actual tool purpose.

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

Completeness2/5

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

For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the 'detailed report' contains, its format, or what happens on failure. The CLI warning addresses setup but not tool behavior, leaving significant gaps in understanding how to properly use this tool.

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 description coverage is 100% with one parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide additional semantic context about the test_run_id parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and resource 'detailed local test report for a specific test run', making the purpose understandable. It distinguishes from siblings like 'get_test_result' by specifying 'detailed report' and 'local test run', but doesn't explicitly contrast with all similar tools.

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 provides some usage context by stating 'Only available for tests run locally (not managed tests)', which helps differentiate from potential managed test alternatives. However, it doesn't explicitly mention when to use this versus siblings like 'get_test_result' or 'open_test_result', leaving some ambiguity about tool selection.

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

Install Server

Other Tools

Latest Blog Posts

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/woocommerce/qit-mcp'

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