Click on "Install 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 provided, so description carries full burden. It implicitly indicates a pure read-only calculation with no side effects, but does not explicitly state safety, permissions, or behavior like handling division by zero.
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 is concise and front-loaded, but lacks structure. No waste, but could include brief usage context 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 simple tool with no output schema and full schema coverage, the description is minimally adequate. However, it does not address sibling distinction or edge cases.
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 clear descriptions for each parameter. The description adds no additional meaning beyond the schema, so baseline 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 name 'calculate' and description 'Perform basic arithmetic calculations' clearly specify the verb and resource. It distinguishes from sibling tools like 'convert_temperature' (different operation) and 'generate-plan'/'execute-step' (different domains).
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 (e.g., 'convert_temperature' for conversions). The description does not mention context or exclusions.
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?
With no annotations, the description must describe behavior fully. It claims support for 'direct input' but the required schema fields (file_name, file_type, file_content) contradict this. The return format and error handling are not mentioned, and the tool's behavior with missing optional parameters is unclear.
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 concise (two sentences) and front-loaded with the core purpose. However, given the complexity of the tool, it could be more structured, but the brevity does not harm clarity significantly.
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 6 parameters, no output schema, and the ambiguity between file vs. direct input modes, the description is incomplete. It does not explain how file content is used (e.g., format expectations), how to use value/from_unit for direct input, or what the response contains. The agent is left with unresolved questions.
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 descriptions cover 100% of parameters, so baseline is 3. However, the description adds confusion by mentioning 'direct input' while optional parameters value and from_unit are not required. The description fails to clarify how the file-related parameters interact with direct input, reducing the value added 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 clearly states the tool converts temperature units between Celsius and Fahrenheit. It distinguishes from sibling tools (calculate, generate-plan, execute-step) which are unrelated. However, it could be more specific about whether it handles single values or bulk conversions.
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 alternatives. The description mentions two modes (file content or direct input) but fails to clarify when each is appropriate. No exclusions or prerequisites are stated.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
Give your AI agents the tools to build, manage, and run automation workflows.
Workflow planning, recovery checkpoints, coordination, fixtures, and compatibility tools for agents.
The AI orchestration agent for modern software teams.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CodeSmiths2026/AtlasOSv1'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
