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., "@AtlasOS create a workflow to research competitors and summarize findings"
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.
AtlasOS is an intelligent orchestration control plane that transforms natural-language objectives into executable workflows using the Model Context Protocol…
AtlasOS — The AI Operating System for Enterprise Orchestration is an MCP (Model Context Protocol) server that extends AI assistants — like Claude, Cursor, and any MCP-compatible client — with new, real-world capabilities. It is built and deployed on Nitrostack, the fastest way to build, deploy, and share MCP apps.
Related MCP server: workflows-mcp
AtlasOS is an intelligent orchestration control plane that transforms natural-language objectives into executable workflows using the Model Context Protocol (MCP). Instead of acting as a conventional chatbot, AtlasOS plans, coordinates, executes, and synthesizes complex multi-step tasks across connected AI agents, enterprise tools, and external services.
A single prompt is automatically decomposed into a structured execution graph, where each node represents a specialized capability such as web research, code generation, database operations, file analysis, API interaction, or business intelligence. AtlasOS dynamically selects the appropriate MCP capabilities, executes them in real time, streams live execution updates, gracefully handles failures through resilient fallback mechanisms, and combines the outputs into a coherent, actionable response.
Designed with a production-grade architecture, AtlasOS features a FastAPI backend, real-time WebSocket synchronization, dynamic workflow visualization, capability discovery, execution monitoring, and fault-tolerant orchestration. Every workflow is generated dynamically—there are no hardcoded execution paths or static responses—providing complete transparency into how AI systems reason, plan, and execute.
Whether automating enterprise operations, accelerating software development, coordinating cybersecurity investigations, or powering intelligent business workflows, AtlasOS serves as the operating system that connects people, AI models, and tools into a unified execution platform.
Key Features 🧠 Natural Language → Executable Workflows 🔗 MCP-Native Tool & Agent Orchestration 📊 Dynamic Workflow Graph Visualization ⚡ Real-Time Execution Monitoring via WebSockets 🛡️ Fault-Tolerant Execution with Intelligent Recovery 🔍 Transparent AI Planning & Decision Making 🔌 Extensible Plugin-Based Capability Registry 🏢 Enterprise-Ready Architecture
The Model Context Protocol (MCP) is an open standard that lets AI assistants securely connect to external tools, data sources, and services. Instead of being limited to what it was trained on, an AI model can call MCP servers to fetch live data, run actions, and integrate with real systems.
This project is one such MCP server. Learn more about building and shipping MCP apps at nitrostack.ai.
🔌 MCP-native — works with any MCP-compatible client (Claude, Cursor, and more)
🛠️ Tools, resources & prompts — exposes structured capabilities to AI agents
⚡ Deployed on Nitrostack — reliable, hosted, and instantly shareable
🔐 Secure by design — secrets stay in environment variables, never in code
🧩 Composable — combine with other MCP apps to build powerful AI workflows
🚀 Live MCP endpoint: https://atlas0s-6a5a9bad-codesmiths-amrita-university-amritapuri-campus.app.nitrocloud.ai
Point your MCP client at the endpoint above to try it instantly. Prefer a hosted setup? Deploy your own in minutes on Nitrostack.
Node.js 18+ (or your project runtime)
An MCP-compatible client (Claude Desktop, Cursor, etc.)
git clone https://github.com/your-username/your-mcp-project.git
cd atlasos-the-ai-operating-system-for-enterprise-orchestration
npm installCopy the example environment file and add your own values:
cp .env.example .envnpm run startAdd this server to your MCP client configuration. A typical entry looks like:
{
"mcpServers": {
"atlasos-the-ai-operating-system-for-enterprise-orchestration": {
"url": "https://atlas0s-6a5a9bad-codesmiths-amrita-university-amritapuri-campus.app.nitrocloud.ai"
}
}
}Restart your client and the tools from this MCP server will be available to your AI assistant.
Want to build and ship an MCP server like this one? Nitrostack lets you create, deploy, and host MCP apps in minutes — no infrastructure to manage.
👉 Start building: https://nitrostack.ai
🌙 Discover and share MCP projects with the community on r/mcptothemoon
🧰 Browse a growing catalog of MCP apps on Nitrostack
An MCP server implements the Model Context Protocol to expose tools, resources, and prompts that AI assistants can call. It lets an AI model take real actions and access live data.
AtlasOS is an intelligent orchestration control plane that transforms natural-language objectives into executable workflows using the Model Context Protocol…
Any MCP-compatible client, including Claude Desktop and Cursor. New clients are adding MCP support regularly.
Use Nitrostack to build, deploy, and host MCP apps without managing infrastructure.
Enterprise AI & Workplace Automation · AtlasOS — The AI Operating System for Enterprise Orchestration · MCP · Model Context Protocol · MCP server · MCP app · AI tools · AI agents · LLM tools · Claude MCP · Nitrostack · deploy MCP server · build MCP app
MIT © 2026
Built with ❤️ using the Model Context Protocol on Nitrostack. Share your MCP app on r/mcptothemoon.
Perform basic arithmetic calculations
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First number | |
| b | Yes | Second number | |
| operation | Yes | The operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It states it performs calculations but omits potential side effects like division-by-zero errors or whether the tool is read-only, leaving behavior ambiguous.
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, using only four words to convey the entire purpose. There is no redundancy or unnecessary elaboration.
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?
The description lacks essential context such as the return format, error handling, or precision of results. Given no output schema and no annotations, the tool is incomplete for an agent to fully understand behavior without additional inference.
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 schema descriptions cover all parameters, giving a baseline of 3. The tool description itself adds no extra meaning beyond the schema, but the schema already defines 'a', 'b', and 'operation' sufficiently for basic arithmetic.
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 performs basic arithmetic calculations, which is a specific action. It distinguishes itself from sibling tools like convert_temperature by being generic, though it lacks detail on exact 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 such as convert_temperature. There is no mention of typical use cases or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert temperature units based on file content or direct input. Supports Celsius (C) and Fahrenheit (F).
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Temperature value to convert | |
| to_unit | No | Unit to convert to (C or F) | |
| file_name | Yes | Name of the uploaded file | |
| file_type | Yes | MIME type of the uploaded file | |
| from_unit | No | Unit to convert from (C or F) | |
| file_content | Yes | Base64 encoded file content. Will be injected by system. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool works 'based on file content or direct input', but the schema requires file_name, file_type, and file_content for all invocations, making direct input impossible without dummy file data. This contradiction is misleading and fails to disclose the actual required 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, short sentence that gets to the point quickly. It could be slightly more explicit about the file/direct input behavior, but overall it is concise and well-structured.
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?
The description lacks necessary context about the relationship between the file parameters and the temperature conversion parameters, especially given the required fields. There is also no explanation of output format or behavior when both file and direct input are provided, leaving the tool's usage incomplete.
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?
All parameters have descriptions, so schema coverage is complete, meeting the baseline. However, the descriptions are minimal, and the file-related parameters are confusing because they are marked required even for 'direct input' and provide no clarity on their purpose or interaction with the value/from_unit/to_unit parameters.
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 converts temperature units between Celsius and Fahrenheit, identifying the specific verb and resource. However, the mention of 'file content or direct input' introduces some ambiguity about the exact mode of operation, slightly detracting from full clarity.
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 the sibling tools like 'calculate' or 'upload-and-analyze'. The description only explains what the tool does, not the scenarios in which it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a single step from an execution plan with resilience and fallback handling
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action to perform: execute a step or synthesize final summary | execute |
| plan_id | Yes | The plan ID to execute | |
| step_id | No | The step ID to execute | |
| capability_name | No | The capability to execute | |
| input_arguments | No | Input arguments for the capability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'resilience and fallback handling' but does not elaborate on what that entails, whether it is destructive, or what side effects occur. Highly opaque.
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, front-loaded with the key action and resource. Efficient but at the cost of necessary detail; it earns its place but could be expanded without losing conciseness.
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 5 parameters, nested objects, and no output schema, the description is too sparse. It does not explain how parameters interact, what happens on fallback, or the expected result, leaving significant gaps for correct invocation.
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 coverage is 100%, so the description adds no extra parameter meaning. Baseline of 3 is appropriate as the schema already documents each parameter adequately.
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 specifies the exact action ('execute'), the resource ('single step from an execution plan'), and adds context ('resilience and fallback handling'), clearly distinguishing it from sibling tools like generate-plan.
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 explicit guidance on when to use or avoid this tool. The description implies it is for executing steps from a plan but provides no prerequisites, alternatives, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a structured execution plan from a natural language goal
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The natural language goal to plan for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states the basic operation, but does not mention side effects, idempotency, permissions, or output format. Critical details for a plan-generation tool are missing.
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 8 words, no unnecessary information. Highly concise and front-loaded with the core purpose.
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?
Despite low complexity (1 parameter, no output schema), the description fails to explain the output structure, how to use the plan, or any constraints. The tool's purpose suggests a richer description is needed.
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 coverage is 100% with one parameter 'goal' already described as 'The natural language goal to plan for'. The description adds no further meaning beyond restating the schema, so baseline of 3 is appropriate.
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 ('Generate'), the output ('structured execution plan'), and the input ('from a natural language goal'). It is distinct from sibling tools (calculate, convert_temperature, execute-step) which are unrelated to plan generation.
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 does not specify prerequisites, when not to use it, or how it relates to sibling tools like execute-step.
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.
v1.0.0calculateconvert_temperatureexecute-stepgenerate-planScored across 4 tools
Each tool targets a distinct operation: arithmetic, temperature conversion, plan generation, and step execution. No overlap in functionality.
Naming style is inconsistent: 'calculate' and 'convert_temperature' use snake_case, while 'generate-plan' and 'execute-step' use hyphens. All are imperative verbs but the format varies.
Four tools is on the low end but still reasonable for a focused utility server. Each tool serves a clear purpose without redundancy.
Obvious gaps exist: no Kelvin in temperature conversion, no way to list or delete plans beyond generate/execute. Lacks full CRUD for plan management.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Give your AI agents the tools to build, manage, and run automation workflows.
Goal and task planning MCP for Codex and AI agents, with evidence-backed completion.
Workflow planning, recovery checkpoints, coordination, fixtures, and compatibility tools for agents.
