EdgeOne Pages MCP
This server enables automated deployment of web content to Tencent Cloud's EdgeOne Pages platform with globally accessible URLs.
Core Deployment Options:
Deploy HTML content: Upload raw HTML markup directly via the
deploy_htmltool, stored in EdgeOne KV storage with edge accelerationDeploy folders or zip files: Deploy complete built frontend directories or zip archives using the
deploy_folder_or_ziptool for static websites or full-stack applicationsDeploy full-stack projects: Use the
deploy_foldertool (via stdio MCP server) for entire full-stack applications
Key Features:
Automatic URL generation: Instantly receive publicly accessible URLs with global edge acceleration after each deployment
Custom domain support: Automatically uses custom domains when configured in EdgeOne Pages console for brand display, SEO optimization, and HTTPS
Project management: Create new projects or update existing ones by specifying project names, with access to project metadata and console URLs
Edge distribution: Content deployed to EdgeOne's global edge network for fast worldwide access
Serverless architecture: Leverage EdgeOne Pages Functions for serverless execution at the edge
Multiple transport protocols: Supports stdio transport (full features) and HTTP streaming transport (HTML deployment only)
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@EdgeOne Pages MCPdeploy this HTML code to a live website"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
EdgeOne Pages MCP
An MCP service for deploying HTML content, folders, or full-stack projects to EdgeOne Pages and obtaining publicly accessible URLs.
Demo
Deploy HTML

Deploy Folder

Related MCP server: Self-Hosted EdgeOne Pages MCP Server
Requirements
Node.js 18 or higher
Deployment on Tencent Cloud
This MCP service supports multiple deployment options. Choose the one that best fits your needs.
Option 1: Deploy Self-Hosted Version to EdgeOne Pages (Recommended)
This is the simplest and fastest deployment method, suitable for scenarios requiring HTTP access.
Step 1: One-Click Deploy to EdgeOne Pages
Visit the self-hosted repository
Click the "One-Click Deploy" button to deploy the service to EdgeOne Pages
Complete the deployment configuration as prompted
Step 2: Configure KV Storage
After deployment, configure KV storage for storing website files:
Go to EdgeOne Pages console
Find KV Storage configuration
Follow the KV Storage Setup Guide
Step 3: Bind Custom Domain (Optional)
Add a custom domain in project settings
Configure DNS CNAME record
Wait for domain verification
Refer to Custom Domain Binding Guide
Step 4: Configure MCP Client
After deployment, add to your MCP configuration file:
{
"mcpServers": {
"edgeone-pages": {
"url": "https://your-custom-domain.com/mcp-server"
}
}
}Advantages:
✅ Zero server maintenance cost
✅ Auto-scaling and high availability
✅ Global edge acceleration
✅ Custom domain and HTTPS support
Option 2: Deploy on Tencent Cloud CVM
Suitable for scenarios requiring full server control or stdio transport.
Step 1: Prepare CVM Instance
Log in to Tencent Cloud Console
Create or select a CVM instance
Recommended configuration:
OS: Ubuntu 20.04 LTS or CentOS 7+
CPU: 2 cores or more
Memory: 4GB or more
Network: Configure public IP or elastic IP
Step 2: Install Node.js Environment
Ubuntu/Debian:
# Update system packages
sudo apt update
# Install Node.js 18.x
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt-get install -y nodejs
# Verify installation
node --version
npm --versionCentOS/RHEL:
# Install Node.js 18.x
curl -fsSL https://rpm.nodesource.com/setup_18.x | sudo bash -
sudo yum install -y nodejs
# Verify installation
node --version
npm --versionStep 3: Deploy MCP Service
# Clone project (or upload project files)
git clone https://github.com/TencentEdgeOne/edgeone-pages-mcp.git
cd edgeone-pages-mcp
# Install dependencies
npm install
# Build project
npm run build
# Configure environment variables
cat > .env << EOF
EDGEONE_PAGES_API_TOKEN=your-api-token-here
EDGEONE_PAGES_PROJECT_NAME=your-project-name
EOFStep 4: Configure Process Management (Using PM2)
# Install PM2
sudo npm install -g pm2
# Start service
pm2 start dist/index.js --name edgeone-pages-mcp
# Set auto-start on boot
pm2 startup
pm2 save
# Check service status
pm2 status
pm2 logs edgeone-pages-mcpStep 5: Configure Firewall
# Ubuntu/Debian (UFW)
sudo ufw allow 22/tcp # SSH
# If using HTTP transport, open corresponding port
# sudo ufw allow 8080/tcp
# CentOS (firewalld)
sudo firewall-cmd --permanent --add-service=ssh
# sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reloadStep 6: Configure MCP Client
If using stdio transport (local or SSH):
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"command": "node",
"args": ["/path/to/edgeone-pages-mcp/dist/index.js"],
"env": {
"EDGEONE_PAGES_API_TOKEN": "your-api-token",
"EDGEONE_PAGES_PROJECT_NAME": "your-project-name"
}
}
}
}Advantages:
✅ Full control over server environment
✅ Support for stdio transport
✅ Suitable for enterprise intranet environments
Option 3: Deploy Using Tencent CloudBase
Suitable for scenarios requiring quick deployment with Tencent Cloud managed services.
Step 1: Create CloudBase Environment
Create a new environment or select an existing one
Choose Node.js 18+ runtime
Step 2: Deploy Code
Select "Cloud Functions" in CloudBase console
Create a new function or upload code
Configure function entry as
index.jsSet environment variables:
EDGEONE_PAGES_API_TOKENEDGEONE_PAGES_PROJECT_NAME
Step 3: Configure HTTP Trigger
Add HTTP trigger in function configuration
Configure access path and authentication
Get trigger URL
Step 4: Configure MCP Client
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"url": "https://your-function-url.tencentcloudapi.com"
}
}
}Advantages:
✅ No server management required
✅ Auto-scaling
✅ Integrated with Tencent Cloud services
Security Recommendations
Regardless of deployment method, it's recommended to:
Protect API Token:
Use environment variables for sensitive information
Don't commit
.envfiles to repositoryRotate API tokens regularly
Network Security:
Use HTTPS for service access
Configure firewall rules to limit access sources
Use VPN or intranet access (if applicable)
Monitoring and Logging:
Configure log collection and monitoring
Set up alert rules
Regularly check service status
Troubleshooting
Issue: Service won't start
Check if Node.js version meets requirements (18+)
Verify dependencies are correctly installed:
npm installCheck logs:
pm2 logsor check cloud function logs
Issue: Invalid API Token
Verify token is correctly configured
Check if token has expired
Refer to API Token Documentation
Issue: Deployment failed
Check network connection
Verify API token permissions
Check detailed error logs
MCP Configuration
stdio MCP Server
Full-featured MCP service that supports the deploy_folder tool for deploying full-stack projects.
// Tencent Cloud International (Default)
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"timeout": 600,
"command": "npx",
"args": ["edgeone-pages-mcp-fullstack@latest"]
}
}
}
// Tencent Cloud China
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"timeout": 600,
"command": "npx",
"args": ["edgeone-pages-mcp-fullstack@latest", "--region", "china"]
}
}
}The following MCP Server will be deprecated soon:
Supports both deploy_html and deploy_folder_or_zip tools.
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"command": "npx",
"args": ["edgeone-pages-mcp@latest"],
"env": {
// Optional.
// If you need to deploy folders or zip files to
// EdgeOne Pages projects, provide your EdgeOne Pages API token.
// How to obtain your API token:
// https://edgeone.ai/document/177158578324279296
"EDGEONE_PAGES_API_TOKEN": "",
// Optional. Leave empty to create a new EdgeOne Pages project.
// Provide a project name to update an existing project.
"EDGEONE_PAGES_PROJECT_NAME": ""
}
}
}
}Streaming HTTP MCP Server
For MCP clients that support HTTP streaming, only supports the deploy_html tool.
{
"mcpServers": {
"edgeone-pages-mcp-server": {
"url": "https://mcp-on-edge.edgeone.site/mcp-server"
}
}
}Tool Details
deploy_html Tool
Architecture Design
The architecture diagram shows the complete workflow of the deploy_html tool:
Large Language Model generates HTML content
Content is sent to the EdgeOne Pages MCP Server
MCP Server deploys the content to EdgeOne Pages Edge Functions
Content is stored in EdgeOne KV Store for fast edge access
MCP Server returns a publicly accessible URL
Users can access the deployed content via browser with fast edge delivery
Implementation Details
This tool integrates with EdgeOne Pages Functions to deploy static HTML content:
EdgeOne Pages Functions - A serverless computing platform that supports executing JavaScript/TypeScript code at the edge
Core Implementation Features:
Uses EdgeOne Pages KV storage to save and serve HTML content
Automatically generates publicly accessible URLs for each deployment
Provides comprehensive API error handling and feedback
How It Works:
MCP server receives HTML content through the
deploy_htmltoolConnects to EdgeOne Pages API to obtain the base URL
Deploys HTML content using the EdgeOne Pages KV API
Returns an immediately accessible public URL
For more information, refer to the EdgeOne Pages Functions documentation and EdgeOne Pages KV Storage Guide.
The source code is open source and can be self-deployed with custom domain binding: https://github.com/TencentEdgeOne/self-hosted-pages-mcp
deploy_folder Tool
This tool supports deploying complete projects to EdgeOne Pages:
Supports full deployment of static website projects
Supports deployment of full-stack applications
Option to update existing projects or create new ones
Custom Domain Configuration
EdgeOne Pages MCP supports custom domain deployment. After configuring a custom domain in the EdgeOne Pages console, the deployment will automatically use your custom domain instead of the default temporary URL.
Benefits of Custom Domain
Brand Display: Use your own brand domain name to enhance professional image
SEO Optimization: Beneficial for search engine indexing and ranking
Better Control: Full control of DNS records
Flexibility: Configure multiple custom domains for different markets or purposes
How to Configure Custom Domain
Step 1: Add Custom Domain in Console
After deploying your project, open the EdgeOne Pages Console
Navigate to your project settings page
Find the "Domain Management" module
Click "Add Custom Domain" button
Input your root domain (e.g.,
example.com) or subdomain (e.g.,www.example.com)
Step 2: Configure DNS CNAME Record
The console will display a CNAME record value (e.g.,
a4285573.xxx.example.com.dns.edgeone.site.)Go to your domain registrar's DNS management page
Add a CNAME record with:
Type: CNAME
Name: Your subdomain (e.g.,
www) or@for root domainValue: The CNAME value provided by EdgeOne Pages
TTL: 600 seconds (recommended for faster propagation)
Save the DNS record
Step 3: Verify Domain
Return to the EdgeOne Pages console
Click "Verify" button or wait for automatic DNS detection
DNS records typically take effect within minutes, up to 48 hours maximum
Once verified, the domain status will change to "Pass"
Step 4: Configure HTTPS (Recommended)
After domain verification, go to "HTTPS Configuration" section
Apply for a free SSL certificate or use a managed SSL certificate
The certificate will be automatically configured for your custom domain
Step 5: Deploy with Custom Domain
After completing the above steps, when you deploy using deploy_folder_or_zip:
If your project has a custom domain configured and verified (Status: "Pass"), the deployment will automatically use your custom domain
The returned URL will be
https://your-custom-domain.cominstead of the temporary URLNo additional configuration is needed in the MCP tool
Important Notes
ICP Filing Requirement: If your project's acceleration region is "Chinese Mainland Availability Zone" or "Global Availability Zone (including Chinese Mainland)", you must complete ICP filing with the Ministry of Industry and Information Technology before adding custom domains
Domain Status: Only domains with status "Pass" will be automatically used in deployments
Multiple Domains: If multiple custom domains are configured, the first domain with "Pass" status will be used
Console URL: After deployment, you can access the project console URL provided in the deployment result to manage domains
Example Deployment Result with Custom Domain
{
"type": "custom",
"url": "https://www.example.com",
"projectId": "your-project-id",
"projectName": "your-project-name",
"consoleUrl": "https://console.tencentcloud.com/edgeone/pages/project/your-project-id/index"
}For more information, refer to:
License
MIT
Available Tools
2 toolsdeploy_folder_or_zipC
Deploy a built frontend directory (or zip file) to EdgeOne Pages. Returns: the deployment URL and project metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| builtFolderPath | Yes | Provide the absolute path to the built frontend folder(or zip file) you wish to deploy. |
TDQS
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.
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.
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.
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.
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.
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.
deploy_htmlC
Deploy HTML content to EdgeOne Pages, return the public URL
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Provide the full HTML markup you wish to publish. After deployment, the system will generate and return a public URL where your content can be accessed. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deploys HTML content and returns a public URL, but does not cover critical aspects like authentication requirements, rate limits, whether the deployment is permanent or temporary, error handling, or what happens to previous deployments. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and outcome without any wasted words. It is appropriately sized for a tool with one parameter and clear functionality, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a deployment tool. It does not explain the return value format beyond 'public URL', nor does it address potential errors, side effects, or integration details. For a tool that modifies external resources, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'value' clearly documented as 'full HTML markup' for publishing. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deploy HTML content') and target resource ('to EdgeOne Pages'), with a specific outcome ('return the public URL'). It distinguishes from the sibling tool 'deploy_folder_or_zip' by specifying HTML content deployment rather than folder/zip deployment, though it could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'deploy_folder_or_zip' or other alternatives. It mentions the outcome but lacks context about prerequisites, limitations, or typical use cases, leaving the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.0.15- First observed
deploy_folder_or_zip - First observed
deploy_html
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: deploy_folder_or_zip handles deploying pre-built frontend files (directories or zip archives), while deploy_html deploys raw HTML content. There is no overlap or ambiguity between these functions.
Both tools follow a consistent verb_noun naming pattern with 'deploy_' as the prefix, making them predictable and easy to understand. The naming is uniform and follows the same convention throughout.
With only 2 tools, the server feels under-scoped for a deployment service. While the tools cover basic deployment scenarios, the lack of operations like listing, updating, or deleting deployments limits functionality and may cause agent workarounds.
The toolset is severely incomplete for a deployment service. There are no tools for managing deployments (e.g., list, update, delete) or projects, creating significant gaps that will lead to agent failures in handling full deployment lifecycles.
Maintenance
Related MCP Connectors
- hoasterOAuthapp.hoaster
Hosts AI-generated web content (HTML, images, SVG, JSON) at a public URL, with custom domains.
Publish a single HTML file as a live HTTPS site in seconds. Versioned deploys, no delete tool.
Host AI-generated HTML/CSS/JS instantly. Files, zips, or clone an existing page. Live in seconds.
Publish AI-generated HTML to a live page on your own domain — from Claude, ChatGPT, or Cursor.
Related MCP Servers
AlicenseBqualityDmaintenanceA service that enables rapid deployment of HTML content to EdgeOne Pages and automatically generates publicly accessible URLs for the deployed content.2546 npm434MIT- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to deploy and manage static websites directly on EdgeOne Pages. Provides simple one-click deployment with KV storage for hosting website files accessible through custom domains.-
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to deploy and manage static websites directly through EdgeOne Pages. It provides a self-hosted solution for hosting website files using KV storage and managing content through the Model Context Protocol.-
- AlicenseBqualityDmaintenanceEnables deployment of HTML content, folders, and full-stack projects to EdgeOne Pages to generate publicly accessible URLs. It utilizes EdgeOne Pages Functions and KV storage for high-performance edge delivery of web applications.24 npmMIT