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

[asapple]

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.

[asapple]

My name is Guming, and I am a Master's student at BUPT. I have gained solid software development experience through my internships at Alibaba Cloud's Serverless infrastructure team and Meituan's core local commerce department.

Throughout my internships, I became a heavy user of Qwen-Code, which gave me a deep appreciation and understanding of its core architecture and ecosystem. This proposal was born directly from my hands-on experience and a desire to contribute back to a tool I've come to rely on.

Furthermore, I've discussed this proposal in-depth with a few of my classmates who are also avid Qwen-Code users with strong development backgrounds. We share a common technical vision for this feature and are all very enthusiastic about bringing it to life. Together, we are confident that we can dedicate the necessary time and effort to deliver a high-quality, robust implementation that aligns with the proposal's goals.

We would be honored to have the opportunity to contribute to the Qwen-Code community in this capacity. We kindly ask the maintainers to consider our offer. If you are supportive, we would greatly appreciate any guidance on the next steps. We are ready and eager to get started.

[abbasmir12]

I completely understand your proposal and the vision you’re laying out here — it makes a lot of sense and feels like the right direction for Qwen-Code. I’m curious though, how do you envision handling security and trust once tools can be installed from the wider community (like npm/pip)? That seems like both the biggest challenge and also the biggest opportunity for building a strong ecosystem.

[asapple]

Drawing lessons from the mature security practices of industry package managers like npm and pip, these tools primarily ensure ecosystem security through registry-level access control, identity-based publisher verification, and continuous third-party security monitoring. Among these, classifying packages into different trust levels such as official, certified, and community by verifying publisher identity is a core security measure.

My thinking about the tool ecosystem, especially the decision not to establish an official central repository, stems from a forward-looking judgment of the future "Agentic Coding" paradigm. I foresee that in the future, there will not only be qwen-code, but also a variety of intelligent agents such as Gemini-CLI and asapple-code that will jointly use this tool ecosystem. In such a vision, no single platform should be the sole builder of the ecosystem. We believe that a more ideal model is for qwen-code, as a member of the ecosystem, to proactively be compatible with and integrate into a broader and more open tool standard, which includes key mechanisms such as a chain of trust and integrity checks.

It is precisely based on this concept of an open ecosystem that this proposal will focus on implementing support for community-level tools. For community tools, we have designed the following three layers of safeguards:

• First is explicit user authorization and risk notification. We firmly believe that developers are the primary responsible parties for their own environments. Therefore, qwen tool will issue a clear security warning when installing community tools, reminding users to carefully review the code source before installation and to be aware that they need to bear the corresponding risks themselves.

• Second is mandatory integrity verification. To ensure that the code is not tampered with during transmission from the publisher to the user, we will introduce a strong hash enforcement mechanism, drawing on the mature practices of pip. The qwen tool add command will add the --require-hashes parameter and support the hashes field in the qwen-tool.json manifest file. After enabling this feature, the tool manager will strictly verify the hash value of the downloaded file to ensure that it has not been tampered with, thereby effectively defending against man-in-the-middle attacks.

• Finally, we encourage and recommend that users adopt execution environment isolation. For example, running Qwen-Code in a sandboxed environment such as a Docker container can fundamentally isolate the tool's execution environment, preventing it from accessing or damaging the host system, thus achieving the highest level of security protection.

Separately, there is significant value in establishing tool management and sharing capabilities for qwen-code as a foundational step. This work is highly valuable in its own right, and should an official tool ecosystem be established in the future, this groundwork will allow for our seamless contribution and integration.

This model has successful precedents in the industry. For example, the popular mcp tool in the Claude ecosystem is not officially provided but has achieved widespread success as a community tool. We will actively refer to and learn from the practical experience of such models to build a community tool ecosystem that is both open and shared.

[abbasmir12]

I'm getting you but, From an implementation perspective, do you imagine starting with a curated, ‘official’ tool registry to build trust first, before opening it up to broader community contributions? Or are you thinking it should be open from day one?

[abbasmir12]

This all sounds really compelling — have you already started experimenting with this, or is it still more at the concept/vision stage?