Proposal: Establishing a Standardized Tool Management and Distribution System for Qwen-Code

What would you like to be added?

Establishing a Standardized Tool Management and Distribution System for Qwen-Code

Why is this needed?

Abstract

Qwen-Code is a powerful command-line AI programming assistant, with one of its core capabilities being the execution of complex "agent-style" coding tasks using large language models. To further unlock its potential, I propose the development of a standardized tool management and distribution system for Qwen-Code. This system will introduce a package management mechanism similar to npm or pip, allowing developers to easil install, share, and manage various tools callable by Qwen-Code. This will significantly enhance development efficiency, foster community collaboration, and build a robust Qwen-Code ecosystem.

Background and Motivation

Currently, Qwen-Code users primarily share tools within teams by uploading them alongside business code to the same repository. While feasible, this approach presents significant bottlenecks in scalability, reusability, and community collaboration:

• Difficulty in Cross-Project Reusability: Reusing the same tool across different projects requires manual copying and configuration, which is cumbersome and error-prone.
• Inefficient Cross-Team Collaboration: The lack of a unified tool publishing and subscription mechanism hinders efficient tool sharing across teams and even organizations.
• Absence of a Community Ecosystem: Developers cannot easily discover and utilize high-quality tools contributed by the community, nor can they effectively share their own innovative tools with others.

If we consider these tools as a form of "meta code," Qwen-Code currently lacks a dedicated package manager for such "meta code." A robust tool ecosystem will be a critical next step in enhancing Qwen-Code’s core competitiveness.

Learning from Industry Leaders

Building a standardized tool ecosystem for AI programming assistants is crucial to enhancing their capabilities, a fact that has been demonstrated by industry leaders.
A prime example is Anthropic’s Claude Code, which leverages its Model Context Protocol (MCP) to achieve powerful integration with external tools and data sources. To support this, Claude Code provides a command-line tool that enables developers to easily manage these MCP integrations. Developers can use commands such as claude mcp add <name> <command> [args...] to seamlessly integrate community or internal tools into their personal environment; similarly, they can uninstall tools via the claude mcp remove <name> command. This clear and efficient management mechanism allows developers to effortlessly discover, share, and reuse tools, significantly expanding Claude Code’s capabilities.
In contrast, Qwen-Code currently lacks a similar standardized tool management system. Just as Claude Code relies on dedicated commands to manage MCP, Qwen-Code urgently requires an equivalent toolchain to support full lifecycle management of its “tools” (and potentially MCP integrations in the future). This would be a critical step toward unlocking its full potential and laying a solid foundation for a thriving developer ecosystem.

Core Benefits

Introducing a toolchain management system will deliver the following core value propositions:

1. Enhanced Development Efficiency: Developers can quickly discover and integrate community-verified, mature tools, avoiding redundant efforts and focusing on business logic innovation.
2. Promoted Standardization and Reusability: Establishing a unified tool development and distribution standard enables seamless tool reuse across projects, teams, and users, maximizing the value of code assets.
3. Fostering a Thriving Community Ecosystem: Lowering the barrier to tool sharing encourages community contributions and exchanges, creating a positive feedback loop that continuously enhances Qwen-Code’s functionality and influence.
4. Strengthened Core Competitiveness: A powerful and extensible tool ecosystem will become a key differentiator for Qwen-Code compared to other AI programming tools.

Additional context

1. Proposed Design: Qwen Tool Manager

We propose introducing a new core command, qwen tool, within the Qwen-Code command-line interface (CLI) to manage the entire lifecycle of tools.

The new tool manager will be built around the qwen tool command, with a clear and semantically intuitive subcommand structure:

• qwen tool add <tool_specifier> [options]: Install a new tool.
• qwen tool delete <tool_name> [options]: Uninstall an installed tool.
• qwen tool list: List all installed tools and their status.
• qwen tool info <tool_name>: Display detailed information about an installed tool.

The add command will support multiple installation sources to maximize flexibility:

1. Installation from local files.
2. Installation from Git repositories (supporting both external and internal Git repositories).

The delete command will be used to remove tools from the local environment.

2. Detailed Design: Command Structure and Parameters

To ensure the tool management system delivers exceptional usability, scalability, and developer experience, we have designed an intuitive and fully-featured command-line interface (CLI). This interface adheres to the widely recognized POSIX standards and modern CLI design paradigms, ensuring clear command structures and semantically explicit parameters.

2.1 Top-Level Command Structure

The qwen tool command serves as the sole entry point for tool management functionalities. Its subcommands follow an "action-object" design pattern, forming the following hierarchical tree structure:

qwen
└── tool
    ├── add      // Install a tool package from a specified source
    ├── delete   // Uninstall an installed tool package (aliases: rm, uninstall)
    ├── list     // Enumerate installed tool packages and their metadata (alias: ls)
    └── info     // Display detailed metadata of a specific installed tool package

2.2 Subcommand Specifications

qwen tool add

Purpose: Fetch, parse, and install a tool package from various specified sources into the current working environment.

Command Format:

qwen tool add <tool_specifier> [options]

Core Parameter (<tool_specifier>):
This parameter serves as the unique identifier for the tool package, with its format determining the source from which the tool is retrieved. The following protocols are supported:

1. Git Repository URL

   • Format: git+<protocol>://<repository_url>[#<commit-ish>]
   • Description: Clone and install the tool directly from a Git repository. This is useful for internal sharing, testing, or using unreleased versions of tools.
   • <protocol>: Supports Git protocols such as https and ssh.
   • <commit-ish> (optional): Can be a branch name, tag name, or specific commit hash. If omitted, defaults to the remote repository’s HEAD.
   • Examples:

     qwen tool add git+https://github.com/user/my-qwen-tool.git
     qwen tool add git+ssh://git@internal.repo.com/project/tool.git#develop
     

2. Local Filesystem Path

   • Format: file:<path>
   • Description: Install from a local directory or compressed archive (e.g., .tgz). Primarily used for local development, debugging, and offline installation scenarios.
   • <path>: A relative or absolute path pointing to the tool package’s root directory or compressed archive.
   • Examples:

     qwen tool add file:../my-local-tool
     qwen tool add file:/path/to/packaged-tool-1.0.0.tgz
     

Optional Parameters ([options]):

• --name <tool_name>:
  • Description: Define a unique name for the tool in the local environment to avoid naming conflicts between tools from different sources.
  • Default Value: The name field in qwen-tool.json.
  • Example: qwen tool add git+https://github.com/user/my-qwen-tool.git --name my-qwen-tool-v2
• --scope <scope_name>:
  • Description: Define the installation scope of the tool. project indicates the tool is available only for the current project (default behavior); global installs the tool globally, making it callable from any project directory.
  • Default Value: project
  • Example: qwen tool add @qwen/linter --scope global
• --force:
  • Description: Force the installation. If the tool already exists, this option triggers a forced re-download and installation, overwriting the existing version. Useful for repairing corrupted installations or ensuring the latest remote resources are fetched.

qwen tool delete

Purpose: Uninstall one or more installed tool packages from the current working environment.

Command Format:

qwen tool remove <tool_name> [<tool_name>...] [options]

Core Parameter (<tool_name>):

• The name of the tool package to uninstall, excluding version numbers or source information.

Optional Parameters ([options]):

• --scope <scope_name>:
  • Description: Specify the scope from which to uninstall the tool. Must match the --scope option used during installation.
  • Default Value: project
  • Example: qwen tool remove linter --scope global

qwen tool list

Purpose: Display a list of installed tool packages, including key information such as version, source, and installation scope.

Command Format:

qwen tool list [options]

Optional Parameters ([options]):

• --scope <scope_name>:
  • Description: Filter and display only tool packages within the specified scope. Valid values are project or global. If omitted, tools from both scopes are displayed and differentiated.
  • Example: qwen tool list --scope global
• --json:
  • Description: Output the results in JSON format for easy script processing and automation integration.

qwen tool info

Purpose: Retrieve and display detailed metadata of a specified installed tool package.

Command Format:

qwen tool info <tool_name> [options]

Core Parameter (<tool_name>):

• The name of the installed tool package to query.

Optional Parameters ([options]):

• --json:
  • Description: Output all metadata in a structured JSON format, including name, description, source, version, maintainer information, etc.

3. Manifest File: qwen-tool.json

This file uses JSON format to define the core attributes of a tool. A minimal qwen-tool.json must include the name and version fields.

Core Field Specifications:

• name (string, required): The unique name of the tool. It is recommended to use lowercase letters, numbers, and hyphens (-). This serves as the unique identifier for referencing the tool in subsequent commands such as delete and info.
• version (string, required): The version number of the tool. It is strongly recommended to follow Semantic Versioning (SemVer) specifications (e.g., "1.0.2").
• description (string, optional): A brief description of the tool's functionality. This information is displayed by the qwen tool info command.
• author (string | object, optional): The author's information about the tool. This can be a simple string (e.g., "asapple") or an object containing name and email fields.
• path (string, required): Defines the file path of the tool within the code repository.
• license (string, optional): The open-source license identifier of the tool, such as "MIT" or "Apache-2.0".

Example Directory Structure:
A standard Qwen-Code tool package directory structure is as follows:

my-qwen-formatter/
├── qwen-tool.json           # Tool manifest file (core metadata)
├── my-qwen-formatter.toml   # Tool file (defines core logic)
├── utils/                   # Additional helper modules or libraries
│   └── helper.py
└── README.md                # Detailed tool documentation

Example qwen-tool.json File:

{
  "name": "json-formatter",
  "version": "1.1.0",
  "description": "A powerful tool to format and validate JSON strings.",
  "author": {
    "name": "asapple",
    "email": "asapple@example.com"
  },
  "path": "/my-qwen-formatter.toml",
  "license": "MIT"
}

4. Example Workflow

The following scenario demonstrates how a developer can create, install, use, and manage a tool in a complete workflow.

Scenario: A team requires a custom log analysis tool named log-analyzer.

1. Create the Tool:

   • Developer Alice creates a local folder named qwen-log-analyzer.
   • She creates a qwen-tool.json file inside the folder and fills in fields such as name, version, and entrypoint.
   • She writes the core logic of the tool in analyzer.toml (the tool file).
   • Upon completion, she pushes the entire folder to the team's internal Git repository: git@internal.git.com/tools/qwen-log-analyzer.git.

2. Install the Tool:

   • Another team member, Bob, needs to use this tool in his project.
   • He navigates to his project's root directory and executes the following command:

     qwen tool add git+ssh://git@internal.git.com/tools/qwen-log-analyzer.git#main
     

   • The qwen tool command automatically clones the repository, parses qwen-tool.json, and installs the tool into Bob's project environment.

3. Verify and View:

   • Bob checks if the tool was installed successfully by executing:

     qwen tool list
     

   • The command-line output displays the installed log-analyzer tool along with its version and source.
   • To view more detailed information, he executes:

     qwen tool info log-analyzer
     

4. Update the Tool:

   • After some time, Alice upgrades the tool's functionality and pushes a new Git tag v1.2.0 to the repository.
   • Upon learning about the update, Bob executes the add command again, specifying the new tag and using the --force option to overwrite the old version:

     qwen tool add git+ssh://git@internal.git.com/tools/qwen-log-analyzer.git#v1.2.0 --force
     

   • The tool is then updated to version 1.2.0.

5. Uninstall the Tool:

   • After a project restructuring, Bob no longer needs the tool. He can easily uninstall it by executing:

     qwen tool delete log-analyzer
     

   • The tool and its related files are subsequently removed from the local environment.

5. Summary

By introducing a tool management system centered around the qwen tool command and defining a standardized tool package structure, we can significantly streamline the creation, sharing, and reuse of Qwen-Code tools. Even in the initial stages without a central registry, this solution—relying solely on Git and local filesystems—can markedly enhance team development efficiency and collaboration experience, laying a solid foundation for the future growth of the Qwen-Code ecosystem.

6. Future Outlook

1. Establish an Official Tool and Protocol Registry (Registry): While Git-based decentralized sharing is ideal for internal team collaboration, building a thriving and open public ecosystem necessitates an official registry similar to PyPI or npm.
2. Support Management and Distribution of MCP (Model Context Protocol): Extend the system to manage and distribute tools compliant with the Model Context Protocol, enabling broader interoperability and integration within the AI development landscape.
3. Enable Seamless Agent Replication and Redistribution Through Complete Tool Migration: Achieve full portability of AI agents by automatically bundling all dependent tools and their configurations into self-contained, versioned packages. This capability ensures cross-environment compatibility and allows users to effortlessly replicate, share, and deploy fully functional agent setups. By eliminating environment-specific dependencies and configuration overhead, this approach significantly reduces agent deployment and configuration time while enhancing reproducibility and collaboration across teams and systems.

The proposal identifies a new qwen tool CLI entry point but names no implementation files or tests. Start by locating the existing CLI command structure and tool or MCP integration points; completion would require agreeing on scope and implementing the proposed add, delete, list, info, and manifest behavior with corresponding tests.