Skip to main content
Glama
TencentEdgeOne

EdgeOne Pages MCP

Official

deploy_folder_or_zip

Deploy a built frontend directory or zip file to EdgeOne Pages, generating a public URL and project metadata for easy access and sharing.

Instructions

Deploy a built frontend directory (or zip file) to EdgeOne Pages. Returns: the deployment URL and project metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
builtFolderPathYesProvide the absolute path to the built frontend folder(or zip file) you wish to deploy.

Implementation Reference

  • Main implementation of the deploy_folder_or_zip tool. Handles validation, COS upload, project management, deployment creation, status polling, and result formatting with logs.
    export const deployFolderOrZipToEdgeOne = async (
      localPath: string,
      env: 'Production' | 'Preview' = 'Production'
    ): Promise<string> => {
      // Reset logs and override console at the start
      resetLogs();
      overrideConsole();
    
      try {
        // Reset token cache at the start of deployment
        resetTokenCache();
        resetTempProjectName();
    
        // Validate folder or zip file
        const isZip = await validateFolder(localPath);
    
        await checkAndSetBaseUrl();
    
        // 1. Upload folder to COS
        const uploadResult = await uploadToEdgeOneCOS(localPath);
        if (!uploadResult.targetPath) {
          throw new Error('COS upload succeeded but targetPath is missing.');
        }
        const targetPath = uploadResult.targetPath;
    
        // 2. Get or create project
        console.log(`[getOrCreateProject] Getting or creating project...`);
        const projectResult = await getOrCreateProject();
        if (!projectResult?.Data?.Response?.Projects?.[0]?.ProjectId) {
          console.error('Invalid project data received: ' + projectResult);
          throw new Error('Failed to retrieve Project ID after get/create.');
        }
        const projectId = projectResult.Data.Response.Projects[0].ProjectId;
        console.log(`[getOrCreateProject] Using Project ID: ${projectId}`);
    
        // 3. Create deployment
        console.log(
          `[createPagesDeployment] Creating deployment in ${env} environment...`
        );
        const res = await createPagesDeployment({
          projectId,
          targetPath: targetPath,
          isZip,
          env,
        });
        const deploymentId = res.Data.Response.DeploymentId;
    
        // 4. Wait for deployment to complete
        console.log(
          `[pollProjectStatus] Waiting for deployment to complete (polling status)...`
        );
        await sleep(5000);
        const deploymentResult = await pollProjectStatus(projectId, deploymentId);
    
        // 5. Get structured deployment result and format message
        const structuredResult = await getDeploymentStructuredResult(
          deploymentResult,
          projectId,
          env
        );
    
        /**
         * Format deployment result into user-friendly message
         * @param deploymentResult The structured deployment result
         * @returns Text message describing the deployment status
         */
    
        // Append deployment logs to the result
        const logs = formatLogs();
        const finalText = `${logs}
    
    results:
    ${JSON.stringify(structuredResult, null, 2)}`;
    
        return finalText;
      } catch (error) {
        // Ensure logs are captured even on error
        const logs = formatLogs();
        const errorMessage = error instanceof Error ? error.message : String(error);
        const finalText = `${logs}Deployment failed: ${errorMessage}`;
        throw new Error(finalText);
      } finally {
        // Always restore console
        restoreConsole();
      }
    };
  • index.ts:62-87 (registration)
    MCP server.tool registration for 'deploy_folder_or_zip', including input schema, description, and thin wrapper calling the main handler.
    server.tool(
      'deploy_folder_or_zip',
      'Deploy a built frontend directory (or zip file) to EdgeOne Pages. Returns: the deployment URL and project metadata.',
      {
        builtFolderPath: z
          .string()
          .describe(
            'Provide the absolute path to the built frontend folder(or zip file) you wish to deploy.'
          ),
      },
      async ({ builtFolderPath }) => {
        try {
          const result = await deployFolderOrZipToEdgeOne(builtFolderPath);
          return {
            content: [
              {
                type: 'text' as const,
                text: result,
              },
            ],
          };
        } catch (e) {
          return handleUncaughtError(e);
        }
      }
    );
  • Zod schema for the tool input parameter 'builtFolderPath'.
      builtFolderPath: z
        .string()
        .describe(
          'Provide the absolute path to the built frontend folder(or zip file) you wish to deploy.'
        ),
    },
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. It states this is a deployment operation (implying a write/mutation) and mentions return values, but doesn't cover critical aspects like authentication requirements, rate limits, error conditions, whether deployment is reversible, or what happens to existing deployments. For a mutation tool with zero annotation coverage, this leaves significant gaps.

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 appropriately concise with two sentences: one stating the action and one stating the return values. It's front-loaded with the core purpose. While efficient, it could be slightly more structured by separating usage guidance from return information.

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 deployment/mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'deploy' entails operationally, what permissions are needed, how deployments are managed, or what the return metadata includes. The mention of return values is helpful but insufficient given the tool's complexity and lack of structured documentation.

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 fully documents the single parameter. The description adds marginal value by reinforcing that it accepts 'built frontend folder (or zip file)' but doesn't provide additional syntax, format details, or constraints beyond what's in the schema. 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.

Purpose4/5

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

The description clearly states the action ('Deploy'), the resource ('built frontend directory (or zip file)'), and the target ('EdgeOne Pages'). It distinguishes from the sibling tool 'deploy_html' by specifying it handles directories/zip files rather than HTML content. However, it doesn't explicitly contrast with the sibling, keeping it at a 4 rather than a 5.

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 provides no guidance on when to use this tool versus alternatives like 'deploy_html'. It mentions the return values but doesn't explain prerequisites, constraints, or appropriate contexts for deployment. There's no explicit when/when-not usage advice.

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

Related 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/TencentEdgeOne/edgeone-pages-mcp'

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