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., "@XO MCP Server Deploy my container to XO"
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.
A powerful Model Context Protocol (MCP) server that provides seamless integration with the XO platform for container deployment, application lifecycle management, and knowledge base operations. This server enables AI assistants to deploy, manage, and interact with applications on the XO infrastructure through natural language commands.
One-click deployment to XO platform
Lifecycle management (start, stop, remove applications)
Real-time logging and monitoring
Application exposure with automatic domain provisioning
Dynamic knowledge base updates using text content
Intelligent question answering with context-aware responses
Multi-project support with isolated knowledge bases
Flexible agent types for different use cases
Simple setup with environment-based configuration
Comprehensive error handling with detailed feedback
Modern MCP architecture using FastMCP
Cross-platform compatibility
Related MCP server: Docker Manager MCP
Python 3.11 or higher
uv package manager
XO platform account with valid credentials
MCP-compatible client (Claude Desktop, Cursor, etc.)
Add this configuration to your MCP client settings:
{
"mcpServers": {
"xo-mcp-server": {
"command": "uvx",
"args": [
"git+https://github.com/sharmasuraj0123/xo-mcp-server.git"
],
"env": {
"ACCESS_TOKEN": "your_access_token",
"DEPLOYMENT_ID": "your_deployment_id"
}
}
}
}Clone the repository:
git clone https://github.com/sharmasuraj0123/xo-mcp-server.git
cd xo-mcp-serverAdd to your MCP client settings:
{
"mcpServers": {
"xo-mcp-server": {
"command": "uv",
"args": [
"--directory",
"/path/to/xo-mcp-server",
"run",
"-m",
"xo_mcp_server"
],
"env": {
"ACCESS_TOKEN": "your_access_token",
"DEPLOYMENT_ID": "your_deployment_id"
}
}
}
}Variable | Description | Required |
| Your XO platform access token | ✅ |
| Unique deployment identifier from XO Launchpad | ✅ |
Visit XO Launchpad
Login and create a new project
Note down your DEPLOYMENT_ID
Contact the XO team for your ACCESS_TOKEN
deploy_to_xo()Deploy your containerized application to the XO platform.
Usage: "Deploy my application to XO"
start_xo_app()Start a previously deployed application.
Usage: "Start my XO application"
stop_xo_app()Stop a running application without removing it.
Usage: "Stop my XO application"
remove_xo_app()Completely remove an application from the platform.
Usage: "Remove my XO application"
get_xo_app_logs()Retrieve real-time logs from your running application.
Usage: "Show me the logs for my XO app"
expose_xo_app()Expose your application to the internet with a custom domain.
Usage: "Expose my XO app to the internet"
update_knowledgebase_using_text(project_name, text_content, text_id?)Add or update text content in your project's knowledge base.
Parameters:
project_name (string): Name of your XO project
text_content (string): The text content to add/update
text_id (string, optional): Unique identifier for the text content
Usage: "Update my knowledge base with this documentation"
ask_question(project_name, question, user_id?, agent_type?, message_type?)Query your project's knowledge base with intelligent responses.
Parameters:
project_name (string): Name of your XO project
question (string): Your question
user_id (string, optional): User identifier (default: "default_user")
agent_type (string, optional): Type of agent response (default: "normal")
message_type (string, optional): Message type (default: "@xo")
Usage: "Ask my knowledge base about deployment procedures"
Go to XO Launchpad
Login and create a new project:
{
"project_name": "my-awesome-app"
}Save your DEPLOYMENT_ID and obtain your ACCESS_TOKEN
Build and push your Docker image to the XO registry:
# Login to XO registry
docker login registry.xo.builders -u 'your-robot-name' -p 'your-robot-secret'
# Build your image
docker build --platform linux/amd64,linux/arm64 -t registry.xo.builders/your-project/your-app:latest .
# Push to registry
docker push registry.xo.builders/your-project/your-app:latestAdd the server configuration to your MCP client (Claude Desktop, Cursor, etc.) with your credentials.
Once configured, you can use natural language commands:
"Deploy my application to XO"
"Show me the application logs"
"Expose my app to the internet"
"Update my knowledge base with the latest documentation"
The XO MCP Server is built on the FastMCP framework and provides:
RESTful API integration with XO backend services
Robust error handling with detailed error messages
Environment-based configuration for security
Modular tool architecture for easy extension
Fork the repository
Create a feature branch: git checkout -b feature/amazing-feature
Commit your changes: git commit -m 'Add amazing feature'
Push to the branch: git push origin feature/amazing-feature
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Documentation: XO Launchpad
Issues: GitHub Issues
Contact: Contact the XO team for access tokens and support
Built with ❤️ by the XO team
Ask a question to the knowledge base
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | default_user | |
| question | Yes | ||
| agent_type | No | normal | |
| message_type | No | @xo | |
| project_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool asks a question, with no information about safety (read-only vs destructive), authentication needs, rate limits, or side effects. This is completely inadequate.
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 one sentence, which is brief but under-specified. It lacks structure and important context, making it insufficiently informative. True conciseness would include key details without excess.
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 5 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain how to construct effective questions or what the response format will be, leaving the agent without essential information.
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 0%, meaning the description must explain parameters. The description does not mention any of the 5 parameters (user_id, question, agent_type, message_type, project_name) or their expected values. This provides no value beyond the schema.
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 states it asks a question to the knowledge base, which is clear but vague. It does not specify the type of questions or differentiate from sibling tools, though most siblings are about deployment, not querying. The description borders on tautology with the tool name.
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?
No guidance on when to use this tool versus alternatives. The description provides no context about prerequisites, expected inputs, or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy to XO
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description omits any behavioral traits such as whether the operation is destructive, idempotent, or requires authentication. For a deployment tool, critical details like deployment impact or rollback capabilities are absent, leaving the agent blind to consequences.
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 extremely brief, but this brevity is under-specification rather than conciseness. Every word should earn its place; here, the single phrase adds no information beyond the name, making it insufficient for the agent.
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 tool has no parameters, no output schema, and no annotations, the description is the sole source of context. It completely fails to explain what deploying to XO entails, such as deployment source, environment, or expected outcome, leaving a severe information gap.
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?
Although there are zero parameters, the description fails to add any meaning beyond the schema. With no parameters to document, the description should clarify what the tool does without inputs, but it offers only a tautology, providing no semantic value.
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 'Deploy to XO' is a tautology that merely restates the tool name without specifying what action is performed, what resource is deployed, or any context. It fails to use a specific verb+resource structure or distinguish itself from sibling tools.
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?
There is no guidance on when to use this tool versus its siblings (e.g., expose_xo_app, start_xo_app). The description provides no context about prerequisites, alternatives, or typical use cases, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expose the XO app to the domain name by calling the /expose-xo-app endpoint
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the endpoint call without mentioning any side effects, required permissions, or domain name constraints, which is insufficient.
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 sentence that is concise and front-loaded. While it is efficient, it could benefit from slightly more context to improve completeness without becoming verbose.
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 tool's simplicity (no parameters, no output schema), the description is minimal but covers the core action. However, it lacks contextual details like prerequisites or domain name specification, making it just adequate.
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?
There are no parameters, so the schema coverage is 100%. Per guidelines, a tool with 0 parameters receives a baseline of 4. The description does not add any parameter info, but none is needed.
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 tool's purpose: exposing the XO app to a domain name via an endpoint. It uses a specific verb and resource, and it distinguishes itself from sibling tools like 'deploy_to_xo' or 'start_xo_app' which handle different operations.
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. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage without additional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the XO app logs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description gives no behavioral context such as read-only nature, required permissions, or output format. The agent has no clue about side effects or safety.
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, front-loaded sentence with no extraneous words. It is concise but lacks depth.
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?
With no parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain what the logs contain, how they are returned, or any constraints, making it incomplete for effective use.
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 zero parameters, so schema coverage is 100%. The description adds nothing beyond the schema, but baseline is 3 for high coverage. No parameter information needed.
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 (Get) and the resource (XO app logs), avoiding tautology. However, 'XO app' is ambiguous without further context, though sibling tools suggest it is understood.
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?
No guidance is provided on when to use this tool versus siblings like 'start_xo_app' or 'stop_xo_app'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the XO app
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear the burden. Only states 'Remove' with no details on side effects, irreversibility, or what happens to associated data.
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?
Single sentence with no wasted words. Appropriate length for a tool with no parameters.
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?
Minimally complete given the tool's simplicity. Lacks details on return value (no output schema) or behavioral effects, but sufficient for basic understanding.
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?
No parameters exist (0 params, schema coverage 100% trivially). Baseline score of 4 applies as per instructions when no params are present.
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?
Description clearly states the action 'Remove the XO app', using a specific verb and resource. It effectively distinguishes from sibling tools like 'deploy_to_xo', 'start_xo_app', etc., which have different purposes.
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?
No guidance on when to use this tool versus alternatives. No context about prerequisites or situations where removal is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the XO app
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Start the XO app' without disclosing side effects, safety profile, or required state. This is insufficient for an agent to understand the behavioral implications of invoking this tool.
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, concise sentence, but it lacks important context. While not verbose, it does not fully earn its place because it omits details that would aid tool selection and usage.
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 tool's simplicity (no parameters, no output schema), the description should still cover prerequisites, effects, or relation to sibling tools. It does not, leaving the agent with insufficient context.
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?
There are zero parameters, and the input schema provides full coverage. Following the guideline, the baseline is 4, as no additional parameter descriptions are needed.
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 'Start the XO app' provides a specific verb and resource, clearly indicating the tool's action. It distinguishes from sibling tools like deploy, stop, or get logs, which have different purposes.
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?
No guidance is given on when to use this tool versus alternatives. For example, it does not mention prerequisites like prior deployment or conditions for starting, which limits its utility for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the XO app
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the action but does not mention whether the stop is graceful, if it may affect other services, or if it requires the app to be running.
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 extremely concise and front-loaded. However, it could be restructured to include more context without being verbose.
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 tool's simplicity (0 parameters, no output schema), the description is minimally adequate. However, it lacks behavioral context such as whether the stop is immediate or graceful.
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?
There are no parameters, and schema coverage is 100%. The description adds no additional parameter meaning, which is acceptable since no parameters exist.
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 'Stop the XO app' uses a specific verb and resource, making the action clear. It implicitly differentiates from sibling 'start_xo_app', though no explicit distinction is made.
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?
No guidance on when to use this tool versus alternatives, nor any prerequisites or side effects. The description is too minimal to provide context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update knowledgebase using text content
| Name | Required | Description | Default |
|---|---|---|---|
| text_id | No | ||
| project_name | Yes | ||
| text_content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'update', implying mutation, but gives no details on consequences, permissions, or side effects.
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?
Extremely short but not usefully concise. Fails to provide necessary details, making it underspecified rather than efficient.
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 tool with 3 parameters, no output schema, and no annotations, the description is wholly inadequate. Missing return values, input requirements, and behavioral context.
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 0% and description adds no parameter explanations. text_id, project_name, and text_content are not elaborated beyond their names.
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?
Description states verb 'Update' and resource 'knowledgebase', giving basic purpose. However, it is vague about what 'update' entails (replace, append, patch) and does not distinguish from sibling tools.
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?
No guidance on when to use this tool vs alternatives like ask_question or deploy_to_xo. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ask_questiondeploy_to_xoexpose_xo_appget_xo_app_logsremove_xo_appstart_xo_appstop_xo_appupdate_knowledgebase_using_textScored across 8 tools
Each tool has a clear, distinct purpose: two for knowledge base operations and six for app lifecycle management. No overlapping functionality.
Most tools follow a verb_noun pattern (e.g., start_xo_app, remove_xo_app), but 'deploy_to_xo' and 'update_knowledgebase_using_text' deviate slightly in structure, causing minor inconsistency.
With 8 tools, the set is well-scoped for managing XO apps and a knowledge base—neither too few nor too many for the domain.
The app lifecycle is well-covered (deploy, start, stop, remove, logs, expose), but the knowledge base is limited to ask and update via text, missing delete or query options, which is a minor gap.
Deploy and manage your apps, databases, storage, and scheduled jobs from your AI agent
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Integrate Connext AI into agentic workflows, enabling Connext product-aware assistance.
