Skip to main content
Glama
aliyun

AlibabaCloud DevOps MCP Server

Official
by aliyun

create_version

Create a new version in a Yunxiao project to manage release plans, set version owners, and track delivery progress with defined start and publish dates.

Instructions

[Project Management] Create a new version in a Yunxiao Project. Versions are used to manage release plans and track delivery progress.

Use Cases:

Create a new release version Plan project milestones Set version owners and dates

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationIdYesOrganization ID, can be found in the basic information page of the organization admin console
idYesProject unique identifier
nameYesVersion name, max length 50 characters
ownersYesOwner user IDs, at least one required
startDateNoStart date, format: YYYY-MM-DD
publishDateNoPublish date, format: YYYY-MM-DD

Implementation Reference

  • Handler case for 'create_version' in the project management tool switch statement. Parses input with CreateVersionSchema, calls createVersionFunc, and returns the result as JSON.
    case "create_version": {
      const args = types.CreateVersionSchema.parse(request.params.arguments);
      const result = await version.createVersionFunc(
        args.organizationId,
        args.id,
        args.name,
        args.owners,
        args.startDate ?? undefined,
        args.publishDate ?? undefined,
      );
      return {
        content: [{ type: "text", text: JSON.stringify(result, null, 2) }],
      };
    }
  • Zod schema 'CreateVersionSchema' defining the input parameters: organizationId (string), id (project ID string), name (1-50 chars), owners (array of strings, min 1), startDate (optional nullable string YYYY-MM-DD), publishDate (optional nullable string YYYY-MM-DD).
    export const CreateVersionSchema = z.object({
      organizationId: z.string().describe("Organization ID, can be found in the basic information page of the organization admin console"),
      id: z.string().describe("Project unique identifier"),
      name: z.string().min(1).max(50).describe("Version name, max length 50 characters"),
      owners: z.array(z.string()).min(1).describe("Owner user IDs, at least one required"),
      startDate: z.string().nullable().optional().describe("Start date, format: YYYY-MM-DD"),
      publishDate: z.string().nullable().optional().describe("Publish date, format: YYYY-MM-DD"),
    });
  • Tool registration entry for 'create_version' with name, description, and inputSchema derived from CreateVersionSchema.
    {
      name: "create_version",
      description: "[Project Management] Create a new version in a Yunxiao Project. Versions are used to manage release plans and track delivery progress.\n\nUse Cases:\n\nCreate a new release version\nPlan project milestones\nSet version owners and dates",
      inputSchema: zodToJsonSchema(types.CreateVersionSchema),
    },
  • Core function 'createVersionFunc' that sends a POST request to the Yunxiao API to create a version. Builds payload with name, owners, and optional startDate/publishDate. Returns the new version's ID.
    export async function createVersionFunc(
      organizationId: string | undefined,
      id: string,
      name: string,
      owners: string[],
      startDate?: string,
      publishDate?: string
    ): Promise<{ id: string }> {
      const finalOrgId = await resolveOrganizationId(organizationId);
      const url = isRegionEdition()
        ? `/oapi/v1/projex/projects/${id}/versions`
        : `/oapi/v1/projex/organizations/${finalOrgId}/projects/${id}/versions`;
    
      const payload: Record<string, any> = {
        name,
        owners,
      };
    
      if (startDate !== undefined) {
        payload.startDate = startDate;
      }
    
      if (publishDate !== undefined) {
        payload.publishDate = publishDate;
      }
    
      const response = await yunxiaoRequest(url, {
        method: "POST",
        body: payload,
      }) as { id: string };
    
      return { id: response.id };
    }
  • Re-export of CreateVersionSchema from operations/projex/types.ts, making it available in the common types barrel module.
    // Projex types
    export {
      // Project schemas
      GetProjectSchema,
      SearchProjectsSchema,
      SearchProgramsSchema,
      
      // Version schemas
      VersionDTOSchema,
      ListProgramVersionsSchema,
      ListVersionsSchema,
      CreateVersionSchema,
      UpdateVersionSchema,
      DeleteVersionSchema,
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the action as creation but doesn't disclose side effects, permission requirements, or potential errors. While the basic behavior is clear, deeper behavioral context (e.g., idempotency, authorization) is missing.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and uses bullet points for use cases, making it scannable. It is concise but could be slightly more efficient by removing the 'Use Cases' header or integrating the items into the first sentence.

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

Completeness3/5

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

Given no output schema and 6 parameters (4 required), the description covers the tool's function and main use cases but does not explain return values, error handling, or constraints like uniqueness of version names. Completeness is adequate but leaves gaps for an agent.

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 baseline is 3. The description's use cases imply a few parameter roles but do not add detailed semantics beyond the schema's existing descriptions. No extra guidance on format or constraints is provided.

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

Purpose5/5

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

The description clearly states the action 'create a new version' and the resource 'Yunxiao Project', with additional context about versions managing release plans and tracking delivery, distinguishing it from sibling tools like create_sprint or create_branch.

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

Usage Guidelines4/5

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

The description provides specific use cases (create release version, plan milestones, set owners/dates), guiding the agent on when to invoke the tool. However, it lacks explicit exclusions or comparisons to alternatives such as update_version or list_versions.

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/aliyun/alibabacloud-devops-mcp-server'

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