The way we interact with infrastructure is changing. A year ago, the typical workflow was: open a terminal, run a command, switch to a browser dashboard, click through a few screens, copy a URL, go back to the terminal. Today, an increasing number of developers are spending most of their time inside an AI-assisted editor — and when they need to do something outside that editor, the context switch is expensive. You lose your train of thought. You forget what you were doing. You open twelve browser tabs.
What MCP changes
The Model Context Protocol gives AI assistants a structured way to call external tools. Instead of describing your deployment problem to Claude and waiting for instructions you then have to execute yourself, you describe what you want and the assistant does it — by calling the Glinr MCP Server directly. Deploy a service, tail logs, check CPU usage, trigger a rollback. All without switching context, all with the AI understanding the full picture of what you're trying to accomplish.
This isn't about replacing the dashboard. The dashboard is where you go when you want to explore, compare services side by side, or understand your system at a glance. The MCP Server is for when you know what you want and you want to do it fast — especially when you're in the middle of debugging something and the deployment action is just one step in a longer workflow your AI assistant is helping you execute.
What Glinr's MCP Server exposes
// Tools available to MCP clients
deploy_service(service_id, ref?)
rollback_service(service_id, deployment_id)
get_logs(service_id, lines?, since?)
get_metrics(service_id, window?)
list_services(project_id?)
get_deployment_status(deployment_id)Each tool is designed to be useful in a real workflow, not just a thin wrapper over a REST API. `get_logs` returns structured log entries the assistant can reason about — not a raw string blob. `get_metrics` returns CPU and memory time-series with anomaly annotations. The goal is to give the AI enough context to make good decisions, not just execute commands blindly.
We think AI-native deployment is where the industry is heading. The teams that build infrastructure tooling with AI in mind from the start will have a significant advantage as AI-assisted development becomes the default way engineers work. We're building Glinr to be that platform.