Skip to main content
Glama

list_packages

Lists available QIT test packages for WordPress/WooCommerce testing. Filter results by name, namespace, or type, and control output size with search and limit parameters.

Instructions

List available QIT test packages with compact output. Use 'search' to filter and 'limit' to control response size.

āš ļø 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
searchNoSearch/filter packages by name or namespace
typeNoFilter by package type
limitNoMaximum number of packages to return (default: 20)

Implementation Reference

  • The core handler logic for the list_packages tool: runs 'qit package:list', parses table output into structured data, applies client-side filtering (search, type), limits results to 20 by default, and formats a compact bullet list with summary.
    handler: async (args: { search?: string; type?: string; limit?: number }) => {
      const cmdArgs = ["package:list"];
      if (args.type) {
        cmdArgs.push("--type", args.type);
      }
    
      const result = await executeQitCommand(cmdArgs);
    
      if (!result.success && !result.stdout.includes("Package")) {
        return {
          content: result.stderr || result.stdout || "Failed to list packages",
          isError: true,
        };
      }
    
      // Parse the table output format
      // | Package ID | Namespace | Version | Size | Visibility | Created |
      const lines = (result.stdout + "\n" + result.stderr)
        .split("\n")
        .filter(line => !line.includes("Deprecated:") && !line.includes("PHP Deprecated:"));
    
      let packages: Array<{
        id: string;
        namespace: string;
        version: string;
        size: string;
        visibility: string;
      }> = [];
    
      for (const line of lines) {
        // Skip non-table lines
        if (!line.startsWith("|") || line.includes("---") || line.includes("Package ID")) {
          continue;
        }
    
        const parts = line.split("|").map(p => p.trim()).filter(p => p);
        if (parts.length >= 5) {
          packages.push({
            id: parts[0],
            namespace: parts[1],
            version: parts[2],
            size: parts[3],
            visibility: parts[4].replace("🌐 ", "").replace("šŸ”’ ", ""),
          });
        }
      }
    
      const totalCount = packages.length;
    
      // Filter by search term if provided
      if (args.search) {
        const searchLower = args.search.toLowerCase();
        packages = packages.filter(pkg =>
          pkg.id.toLowerCase().includes(searchLower) ||
          pkg.namespace.toLowerCase().includes(searchLower)
        );
      }
    
      // Apply limit (default 20)
      const limit = args.limit ?? 20;
      const limited = packages.slice(0, limit);
      const hasMore = packages.length > limit;
    
      if (packages.length === 0) {
        let msg = "No packages found";
        if (args.search) msg += ` matching "${args.search}"`;
        if (args.type) msg += ` of type "${args.type}"`;
        return { content: msg + ".", isError: false };
      }
    
      // Compact text format
      const outputLines = limited.map(pkg =>
        `- ${pkg.id} (${pkg.visibility}, ${pkg.size})`
      );
    
      let output = `Packages (showing ${limited.length} of ${packages.length}`;
      if (args.search) output += ` matching "${args.search}"`;
      output += `, ${totalCount} total):\n${outputLines.join("\n")}`;
    
      if (hasMore) {
        output += `\n\n... and ${packages.length - limit} more. Use 'limit' to see more or 'search' to filter.`;
      }
    
      return { content: output, isError: false };
    },
  • Input schema using Zod for validating tool arguments: optional search string, type enum ('e2e' or 'utility'), and limit number.
    inputSchema: z.object({
      search: z
        .string()
        .optional()
        .describe("Search/filter packages by name or namespace"),
      type: z
        .enum(["e2e", "utility"])
        .optional()
        .describe("Filter by package type"),
      limit: z
        .number()
        .optional()
        .describe("Maximum number of packages to return (default: 20)"),
    }),
  • Aggregates and exports allTools object by spreading packagesTools (which contains list_packages) along with other tool groups.
    export const allTools = {
      ...authTools,
      ...testExecutionTools,
      ...testResultsTools,
      ...groupsTools,
      ...environmentTools,
      ...packagesTools,
      ...configTools,
      ...utilitiesTools,
    };
  • src/server.ts:29-35 (registration)
    Registers list_packages (via allTools) for MCP's listTools request by mapping to MCP tool format (name, description, jsonSchema), with CLI detection note if missing.
    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),
    }));
  • src/server.ts:44-44 (registration)
    Looks up the list_packages handler (via allTools) by name in MCP's callTool request handler.
    const tool = allTools[name as ToolName];
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'compact output' which is useful behavioral information, but doesn't describe pagination behavior, rate limits, authentication requirements, or what happens when QIT CLI is not detected (the CLI warning appears to be static text rather than behavioral description). For a listing tool with zero annotation coverage, this is insufficient disclosure.

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

Conciseness1/5

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

The description is poorly structured with 80% of the text being a CLI installation warning that doesn't belong in a tool description. The actual tool description is only the first sentence, followed by irrelevant installation instructions. This violates front-loading principles and includes substantial waste.

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 listing tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description is incomplete. It doesn't explain the return format, pagination, authentication requirements, or error conditions. The CLI warning text is irrelevant noise that doesn't help the agent understand tool behavior. The description fails to compensate for missing structured data.

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%, so the schema already documents all three parameters thoroughly. The description mentions 'search' and 'limit' parameters by name but adds no additional semantic context beyond what's in the schema. The 'type' parameter isn't mentioned at all. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description starts with 'List available QIT test packages with compact output' which clearly states the verb (list) and resource (QIT test packages). However, it doesn't distinguish this tool from sibling tools like 'list_tests' or 'list_environments' - all appear to be listing operations for different resources. The purpose is clear but lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description mentions using 'search' to filter and 'limit' to control response size, but this is parameter guidance rather than when-to-use guidance. There's no indication of when to use this tool versus alternatives like 'list_tests' or 'search' operations. No prerequisites, exclusions, or comparison to sibling tools are provided.

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