NACC - Network Agentic Command Control
AI-Powered Network Orchestration via MCP
Imagine this scenario: You're a developer juggling multiple machines - your MacBook for coding, a Kali Linux VM for security testing, and a home server running your projects. Every task requires manual SSH connections, remembering IP addresses, navigating different filesystems, and context-switching between terminals.
What if you could just... talk to all of them at once?
That's the problem NACC (Network Agentic Command Control) was born to solve. Not through another dashboard, not through another monitoring tool, but through natural language powered by the Model Context Protocol (MCP).
NACC started as an ambitious project for the HuggingFace MCP Birthday Hackathon 2025 - celebrating the first anniversary of Anthropic's Model Context Protocol. But it wasn't built as a "hackathon project" in the traditional sense. It was built as a real solution to a real problem I face daily as a cybersecurity student and developer.
The Original Architecture:
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ MacBook Pro │ │ Kali Linux VM │ │ Ubuntu Server │
│ (Development) │ │ (Pen Test) │ │ (Production) │
│ │ │ │ │ │
│ NACC Node ✓ │ │ NACC Node ✓ │ │ NACC Node ✓ │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
│ Local Network (192.168.x.x) │
│ │ │
└───────────────────────┼───────────────────────┘
│
┌────────▼────────┐
│ NACC Brain │
│ (Orchestrator) │
│ + AI Agent │
└─────────────────┘
How it worked:
nacc-node initThe Model Context Protocol isn't just about connecting AI to tools - it's about creating a standardized language for agents to communicate. For NACC, this meant:
We built the entire MCP stack from scratch - no pre-existing SDKs, no templates. Every JSON-RPC handler, every tool definition, every security handshake was custom-written to truly understand the protocol.
Then came the reality check.
The hackathon required submissions to be deployable on HuggingFace Spaces. But NACC was fundamentally designed for local networks with full system access. The challenge was immense:
🚫 No Real Network: HuggingFace Spaces run in isolated containers. You can't SSH to other machines. You can't discover nodes on a LAN.
🔒 Security Restrictions: File operations are sandboxed. Shell commands are limited. Root access? Forget it.
🏗️ Single Runtime: Spaces run one app. But NACC needs multiple nodes to demonstrate orchestration.
📦 Static Environment: Can't install agents dynamically. Can't pair new nodes during runtime.
It would have been easy to:
But that wouldn't be NACC. That wouldn't be true to the vision.
After days of testing constraints and pushing boundaries, a radical idea emerged:
What if we use TWO separate HuggingFace Spaces and connect them via HTTP?
┌─────────────────────────────────────────────────────┐
│ MAIN SPACE (Gradio SDK) │
│ https://huggingface.co/spaces/.../NACC │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────┐ │
│ │ Gradio UI │ │ Orchestrator │ │ AI Agent │ │
│ │ (Frontend) │ │ (Brain) │ │ (Blaxel) │ │
│ └──────┬───────┘ └──────┬───────┘ └─────┬─────┘ │
│ │ │ │ │
│ │ ┌────────────▼─────────────────┤ │
│ │ │ hf-space-local (Node) │ │
│ │ │ Local filesystem access │ │
│ │ └──────────────────────────────┘ │
└─────────┼──────────────────────────────────────────┘
│
│ HTTP Bridge (Cross-Space Communication)
│ - JSON-RPC over HTTPS
│ - Tool invocation protocol
│
┌─────────▼──────────────────────────────────────────┐
│ VM SPACE (Docker SDK) │
│ https://huggingface.co/spaces/.../NACC-VM │
│ │
│ ┌──────────────────────────────────────────────┐ │
│ │ vm-node-01 (NACC Node Server) │ │
│ │ - Isolated Docker container │ │
│ │ - Simulates remote machine │ │
│ │ - RESTful API endpoints for tool execution │ │
│ │ - Whitelisted command execution │ │
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
First Dual-Space Architecture: No one had used two separate HuggingFace Spaces to simulate a distributed system before.
Maintained Core Concepts: We preserved the fundamental NACC experience - AI reasoning, multi-node orchestration, cross-machine operations.
Real MCP Implementation: The Main Space and VM Space communicate via actual MCP-style JSON-RPC. The protocol is real, not simulated.
Constraints as Features: Limited filesystem access became a security showcase. Containerization became deployment flexibility.
Problem: Gradio Spaces (main) can't directly communicate with Docker Spaces (VM) through Spaces' internal networking.
Solution: Implemented an HTTP-based tool invocation system:
# In Main Space (Orchestrator)
response = requests.post(
"https://huggingface.co/spaces/MCP-1st-Birthday/NACC-VM/tools/execute-command",
json={
"command": ["ls", "-la", "/app"],
"timeout": 30
}
)
# In VM Space (Node Server)
@app.post("/tools/execute-command")
async def execute_command(request: CommandRequest):
if request.command[0] not in ALLOWED_COMMANDS:
raise HTTPException(403, "Command not allowed")
result = subprocess.run(
request.command,
capture_output=True,
timeout=request.timeout
)
return {"stdout": result.stdout, "exit_code": result.returncode}
Key Innovation: The Main Space's orchestrator treats the VM Space as a "remote node" - identical to how it would treat a real machine on a network. The abstraction is seamless.
Problem: Each space is stateless. How do we maintain session context (current directory, active node) across commands?
Solution: Session management with state persistence:
class SessionState:
session_id: str
current_node: str = "hf-space-local" # Default to local
current_path: str = "/tmp"
created_at: datetime
last_activity: datetime
# Store in orchestrator memory
sessions: Dict[str, SessionState] = {}
# Every chat message includes session context
@app.post("/chat")
async def chat(query: str, session_id: str, current_node: str, current_path: str):
session = sessions.get(session_id)
# AI uses current_node to route commands
# Updates session state based on user actions
return {
"response": ai_response,
"context": {
"current_node": updated_node,
"current_path": updated_path
}
}
Impact: Users can say "switch to vm-node-01" and all subsequent commands automatically target the VM Space - even though it's a separate deployment!
Problem: Anyone can access these Spaces. We can't allow arbitrary command execution.
Solution: Multi-layer security model:
ALLOWED_COMMANDS = {
"ls", "cat", "pwd", "echo", "python3", "head", "tail",
"find", "grep", "wc", "hostname", "whoami", "df", "du"
}
ROOT_DIR = "/app" # All operations must stay inside /app
RUN useradd -m -s /bin/bash user
USER user
Result: The demo is safe for public access while still showcasing NACC's capabilities.
Problem: How do we make a demo with limited permissions feel like the real NACC?
Solution: Enhanced UI feedback and intelligent error handling:
def parse_and_enhance_response(self, result: Dict, message: str) -> str:
# Detect intent and provide contextual feedback
if "install" in message.lower():
if exit_code == 0:
return "✅ Installation completed successfully!"
else:
return "⚠️ Installation restricted in demo mode. See the GitHub repo for full capabilities."
if "navigate" in message.lower():
# Parse the path change and update UI sidebar
self.update_file_browser(new_path)
return f"📁 Navigated to {new_path}\n{file_listing}"
Impact: Despite restrictions, users get a polished experience with real-time feedback and helpful guidance.
| Feature | Original NACC (Local Network) | HF Space Demo (Cloud) |
|---|---|---|
| Nodes | Unlimited (Mac, Linux, VMs) | 2 (hf-space-local + vm-node-01) |
| Filesystem | Full access across all machines | Sandboxed to /tmp and /app |
| Commands | All shell commands available | Whitelisted safe commands only |
| Node Pairing | Dynamic via 6-digit codes | Pre-configured for demo |
| File Sync | Real-time cross-machine sync | Simulated via API |
| AI Backend | Blaxel, OpenAI, Gemini, Modal | Blaxel (default) |
| Security | SSH keys + firewall rules | Command whitelist + path restrictions |
| Accessibility | Local network or VPN required | Public URL, accessible anywhere 🌍 |
| Deployment | Manual setup on each machine | One-click Space deployment 🚀 |
The Insight: By adapting for Spaces, we actually made NACC more accessible to the world. The core innovation - AI-powered multi-node orchestration - is fully demonstrable without requiring users to set up their own infrastructure.
One of the most challenging decisions was to build the entire MCP stack from scratch instead of using existing libraries. Here's why it mattered:
class MCPServer:
"""Lightweight MCP-compliant JSON-RPC server"""
def __init__(self):
self.tools = {} # Tool registry
def register_tool(self, name: str, schema: Dict, handler: Callable):
"""Register an MCP tool with JSON schema"""
self.tools[name] = {
"name": name,
"description": schema["description"],
"inputSchema": schema["parameters"],
"handler": handler
}
async def handle_list_tools(self) -> Dict:
"""MCP ListToolsRequest handler"""
return {
"tools": [
{
"name": t["name"],
"description": t["description"],
"inputSchema": t["inputSchema"]
}
for t in self.tools.values()
]
}
async def handle_call_tool(self, name: str, arguments: Dict) -> Dict:
"""MCP CallToolRequest handler"""
if name not in self.tools:
return {"error": "Tool not found"}
handler = self.tools[name]["handler"]
result = await handler(**arguments)
return {"content": [{"type": "text", "text": result}]}
Security Control: We know exactly what each line of code does. No black-box dependencies executing on root-level machines.
Performance Optimization: Tailored for low-latency local network communication. No unnecessary abstractions.
Learning & Demonstration: Building from scratch shows deep understanding of MCP principles - crucial for a hackathon celebrating the protocol itself.
Flexibility: We added custom features like node aliases, session persistence, and cross-space routing that weren't in standard MCP SDKs.
# Filesystem tools
tools.register("read_file", read_file_handler)
tools.register("write_file", write_file_handler)
tools.register("list_directory", list_directory_handler)
# Execution tools
tools.register("execute_command", execute_command_handler)
tools.register("check_command_status", status_handler)
# Node management tools
tools.register("get_node_info", node_info_handler)
tools.register("switch_node", switch_node_handler) # Our custom addition!
tools.register("sync_files", sync_files_handler) # Multi-node innovation!
Each tool follows the MCP specification but is implemented to work across our two-space architecture.
Discovery: Initial tests revealed HF Spaces' strict limitations.
Pivot: Decided to embrace constraints and build around them rather than fighting them.
Breakthrough: The two-space architecture concept was born.
Challenge: Getting Gradio and Docker Spaces to communicate.
Attempts:
Result: Stable, fast cross-space communication.
Initial Plan: Use Modal's free tier for LLM.
Problem: Modal's authentication flow broke in Gradio iframe context.
Discovery: Blaxel - an ultra-fast serverless LLM platform with <25ms cold starts.
Integration: Added Blaxel in under 10 minutes. Perfect experience.
Praise: Blaxel's seamless API made them the hero of this project. Their performance enabled real-time AI responses even in the cloud demo.
Issue: After "switch to vm-node-01", file browser still showed local files.
Root Cause: Session ID wasn't being returned correctly from chat handler.
Fix:
# Before (BROKEN)
return history, "", dashboard, files, session_id # Input session_id
# After (FIXED)
return history, "", dashboard, files, session.session_id # Actual session object
Learning: State management in multi-node systems is hard. Even small bugs break the entire UX.
Tasks:
The Spaces limitations forced us to create the two-space architecture - which is now a reusable pattern for any distributed demo on HF.
By treating the VM Space as just another "node", we maintained code reusability. The orchestrator doesn't "know" it's talking to a different HF Space - it just sees a node at a URL.
We could have built a more "correct" MCP implementation, but the Blaxel + fallback regex approach gave users a better experience. Sometimes pragmatism wins.
The in-UI help system, the detailed READMEs, and this article are all part of the "product". Good docs make complex systems accessible.
List available nodes:
list nodes
Switch to the VM:
switch to vm-node-01
Explore files:
navigate to /app/src
list files
Create a test file:
navigate to /tmp
write "Hello from NACC!" to demo.txt
Read it back:
read file demo.txt
Switch back to local:
switch to hf-space-local
Try this penetration testing simulation:
switch to vm-node-01
navigate to /app/demo
read file target_info.txt
switch to hf-space-local
create a file named scan_results.txt with content "Analysis complete"
The context switches are seamless - that's the magic of NACC.
This hackathon demo is just the beginning. Here's what's next:
NACC aims to be the "Terraform for Human Language" - where infrastructure is declared through conversation, not code.
Imagine:
"I need a 3-tier web app: React frontend, Node.js API, PostgreSQL database.
Deploy the frontend to Vercel, the API to Railway, and the database to Supabase.
Set up CI/CD and Slack alerts."
NACC would understand this, plan the architecture, provision the resources, configure the networking, and deploy the stack - all autonomously.
To everyone who believed in this project - from initial skepticism ("you can't demo a network app in the cloud!") to seeing the two-space architecture come to life.
To the MCP community - for pioneering a protocol that will change how we build AI systems.
And to you, reading this - for taking the time to understand not just what NACC is, but why it matters.
I'm Vasanthadithya Mundrathi (SHADOW) - a 3rd year B.E. Computer Science student at CBIT, Hyderabad. Not a senior engineer. Not a startup founder. Just a college kid who loves building things and refuses to wait for graduation to start making an impact.
Let me paint you the picture of building NACC:
November 14, 2024 - Hackathon starts. I'm excited. I have this crazy idea about AI orchestrating networks.
November 18, 2024 - My college announces semester exams starting November 25th. Major project submission deadline: November 22nd.
November 20, 2024 - I'm debugging why Gradio and Docker Spaces can't talk to each other while also studying for Operating Systems exam and finishing my college IoT project.
November 23, 2024 - 2 AM. I finally crack the two-space architecture. I have an exam at 9 AM. I study for 3 hours, take the exam, come back and code for 12 hours straight.
November 28, 2024 - Exams are over. I have 2 days left before the hackathon deadline. The demo works locally but fails on HuggingFace Spaces. Git LFS is refusing to upload my 100MB video. I'm questioning every life choice.
November 29, 2024 - I push the final commit at 9 PM. The Spaces are live. The demo works (mostly). I'm exhausted, terrified, and oddly proud.
This is what building a hackathon project looks like when you're a student. No fancy co-working space. No team. Just you, your laptop, caffeine, and the stubborn refusal to give up.
Here's what goes through my head when I look at other hackathon submissions:
But then I remember: Everyone starts somewhere. Every expert was once a beginner.
This project isn't perfect. The Spaces demo is slower than I'd like. Some features don't work as smoothly as the local version. There are probably bugs I haven't found yet.
But I shipped it anyway. Because done is better than perfect. Because trying and failing is better than not trying at all.
You know what keeps me going through the 2 AM debugging sessions and the rejection emails from companies?
The vision.
I genuinely believe we're at the cusp of a paradigm shift. In 5 years, controlling complex infrastructure through natural language will be normal. Junior developers will deploy multi-region Kubernetes clusters by just describing what they want. DevOps will be democratized.
And I want to be part of building that future. Not as a spectator, but as a contributor.
I'm in my 3rd year. Placement season starts in 6 months. Here's what I'm up against:
So I build. Because if I can't compete on grades or pedigree, I'll compete on innovation, grit, and the ability to ship complex projects from zero.
NACC is my way of saying: "I might not be the smartest or the most credentialed, but I can learn, adapt, and build real solutions to real problems."
I'm not looking for a job (yet - that's next year). I'm looking for opportunities to learn, grow, and prove myself:
Internships where I can:
What I bring:
What I need:
If you're reading this and you:
I'd love to talk.
I'm not claiming to be the next tech genius. I'm just a student who:
Check my work:
Because I know I'm not the only one. There are thousands of students like me:
If you're one of them: Keep building. Keep shipping. Your projects don't need to be perfect. They need to exist.
Your first 100 GitHub stars won't come from marketing. They'll come from solving real problems and sharing your journey honestly.
Your dream internship won't come from cold applications. It'll come from someone seeing your work and thinking: "This person is hungry. Let's give them a shot."
You won't remember the sleep you lost or the exams you stressed over. You'll remember the moment your project went live and someone, somewhere, said: "This is actually useful."
To fellow students reading this: We're in this together. DM me on LinkedIn. Let's share struggles, celebrate wins, and lift each other up.
To industry folks reading this: We're the next generation. Give us a chance, and we'll surprise you.
Here's the truth: I believe converting every machine and computer into an MCP node will be a game-changer.
Imagine a world where:
This isn't science fiction. This is the future I'm trying to build.
The Model Context Protocol does something revolutionary: it gives AI agents a standardized way to interact with tools and systems. But most MCP implementations focus on individual tools (databases, APIs, code editors).
NACC asks a different question: What if the tool is an entire computer?
When you make a machine MCP-compliant:
This is why I built NACC from zero. To prove that MCP + Agentic AI can orchestrate distributed systems at scale.
I'll be honest with you - this wasn't an easy journey.
The Challenges:
The Honest Truth:
Why I Still Shipped It: Because the vision matters more than perfection. Because showing what's possible matters more than showing what's polished.
Beyond the code, NACC showcases:
Think about it: Controlling an entire company's infrastructure from a chat interface using plain English. Sounds crazy, right? But that's exactly where we're headed.
I built this as a 3rd year pre-final student who's passionate about cybersecurity, AI, and distributed systems. I don't have years of industry experience. I don't have a team or funding.
What I do have is:
If you try NACC and find value in it - please:
I don't have Instagram (too much cybersecurity training made me paranoid 😅), but I'm active on LinkedIn and GitHub. Let's connect!
As a pre-final year student, I'm actively seeking internship opportunities where I can:
If you're building something in AI agents, security automation, distributed systems, or MCP tooling - and you need someone who can learn fast, think creatively, and ship results - I'd love to chat.
Check my GitHub for technical proficiency, my LinkedIn for projects and achievements, and this very article for proof that I can envision, architect, and execute on ambitious ideas.
Building NACC has been one of the most challenging and rewarding experiences of my journey as a developer. It forced me to think beyond single-machine applications, beyond single-cloud deployments, beyond the comfortable patterns I knew.
The two-space architecture wasn't Plan A. It wasn't even Plan B. It was what emerged when we refused to compromise on the core vision - that AI agents should be able to orchestrate real, distributed systems through natural language.
This hackathon celebrates the 1st birthday of MCP - a protocol that gives us the tools to build these kinds of systems. NACC is my tribute to that vision: a real-world application of MCP that pushes boundaries, embraces constraints, and shows what's possible when we think creatively about AI + Infrastructure.
To the judges: Thank you for considering this project. I know it's rough around the edges, but I hope the vision and innovation shine through.
To the community: If this article inspired you, if the demo impressed you, or if you just think the idea is cool - please try it, star it, and share your feedback. This is just the beginning, and the best ideas come from dialogue.
To anyone building with MCP: Keep pushing boundaries. Keep thinking bigger. The future where we control infrastructure through conversation is closer than you think.
Thank you for reading. Now go build something amazing with MCP! 🚀
Built with ❤️, ☕, and countless hours of debugging for the HuggingFace MCP Birthday Hackathon 2025 🎂
"The best way to predict the future is to build it." - NACC Team