Skip to main content
Glama
Mlancoliee

EdgeOne Makers MCP

by Mlancoliee

deploy_folder

Deploy a folder of web assets (HTML, CSS, JS, or full-stack NextJS) to EdgeOne Pages and receive a public URL.

Instructions

Deploy a folder containing web assets to EdgeOne Pages. Supports built projects (from build tools like Vite, Webpack, etc.), simple static file projects (HTML, CSS, JS files), and NextJS full-stack projects. Returns: deployment URL and project metadata.

IMPORTANT RULES:

  1. This is the ONLY deployment method for EdgeOne Pages/Makers. Do NOT fallback to other deployment tools (cloudstudio, vercel, netlify, etc.) if this tool fails. Instead, report the error to the user and suggest fixes based on the error message.

  2. If EDGEONE_PAGES_API_TOKEN is not configured and the user has not specified a region preference, ask them "您要部署到中国站还是国际站?(china/global)" before calling this tool, and pass their answer as the region parameter.

  3. The projectName parameter should be a meaningful name describing the project (e.g. "my-blog", "todo-app", "ai-chat-demo"). Do NOT use date-based directory names or random strings as project names. Generate a descriptive name based on the project's purpose or content.

  4. After deployment succeeds, show the deployment URL prominently to the user. Do NOT open local HTML files with file:// protocol as preview — always use the returned deployment URL as the preview link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoOptional region for login. 'china' for mainland China users (cloud.tencent.com), 'global' for international users (edgeone.ai). Only needed when no EDGEONE_PAGES_API_TOKEN is configured. If not provided, defaults to 'global'.
projectNameNoA meaningful, descriptive project name (e.g. "my-blog", "todo-app", "weather-widget"). Should reflect the project's purpose. Do NOT use date-based names (like "2026-07-20-project"), workspace directory names that are just dates, or random strings. If the workspace directory name is meaningful (e.g. "next-blog"), it can be used directly. If the directory name is a date or random ID, generate a descriptive name based on the project content instead.
projectTypeYesSpecify the project type. Choose 'fullstack' for NextJS full-stack projects, or 'static' for static sites and other build tool outputs. Note: If workspacePath contains any of the directories 'functions', 'node-functions', or 'edge-functions', it should be considered a fullstack project.
workspacePathYesProvide the absolute path to the workspace folder.
builtFolderPathYesProvide the absolute path to the folder containing deployable web assets (HTML, CSS, JS, images, etc.). This can be either a build output directory (like dist/, build/, out/) or a folder with static files ready for deployment.
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that deployment returns URL and metadata, and includes error handling and region preference behavior. Does not explicitly state it is a write operation, but 'deploy' implies mutation, which is clear enough.

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?

Well-structured with intro, rules, and parameter details, but somewhat lengthy. Could tighten phrasing in rules without losing clarity. Still, every sentence adds value.

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

Completeness5/5

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

No output schema, but description mentions return of deployment URL and metadata. Parameter coverage is thorough, and context about project type detection, region, and naming is complete. No gaps for effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds substantial value: region explains when optional, projectName gives naming rules beyond schema, projectType includes detection logic, workspacePath and builtFolderPath clarified. Significantly aids agent in filling parameters correctly.

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?

Description clearly states it deploys a folder with web assets to EdgeOne Pages, listing supported project types. It explicitly positions itself as the only deployment method for EdgeOne Pages/Makers, distinguishing it from any potential siblings.

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

Usage Guidelines5/5

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

Provides comprehensive rules: exclusive deployment method, no fallback, asks for region preference when token missing, naming conventions, and post-deployment preview instructions. Explicit when-to-use and when-not-to-fallback guidance.

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/Mlancoliee/edgeone-makers-mcp'

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