AI
MCP Is the Only Protocol You Need
Adams introduced himself as a software architect at Obot AI and a former high school math teacher. He framed the talk around a core idea from his previous work at Rancher: using Kubernetes to manage Kubernetes. Obot AI applies the same dogfooding principle to MCP. Every part of their agent loop is MCP. The user request triggers a server that assembles conversation history, makes an LLM inference via a sampling request, and runs tool calls. Ask the user is just another tool. The agent response is a tool call response. Nothing else.
Demo: Chat Is an MCP Tool
Adams ran a demo of Obot AI’s chat application. He connected a modified version of the MCP inspector to their production MCP server. The server exposes one tool: chat_with_nanobot. He sent a message with the instruction “always respond in the dopest way imaginable.” The tool returned “Bet.” He switched to the actual chat application. The same message appeared there. He sent “Nope.” The agent replied “What are we building?” He proved the inspector and the chat app use the same server. The chat application is an MCP server running a single tool.
Reliability Problems with Synchronous Tool Calls
Standard tool calls are not durable. Servers restart, HTTP connections drop, a lightning strike can fry a router. Adams said a synchronous call loses the chat message and response forever if the connection goes down. Long-running workflows that take hours require an HTTP connection to stay open that long. Closing a laptop or tending to a screaming baby kills the session. Obot AI needed a solution before tasks were added to the specification.
Ad-Hoc Async Tasks Before the Spec
Obot AI built their own async system. They added a metadata flag AI.nobot.ync to the request. When set to true, the framework treats the tool call as an asynchronous task. Progress notifications send status back to the chat app. A special resource exposes chat progress and chat history. Adams demoed this: he sent “yo” with the async flag. The server returned “chat request has been sent to the service.” He polled the chat_progress resource and found the LLM response “Hey, what do you need help with?” The system works but requires clients to know the metadata keys, the resource URIs, and the notification format. That is not sustainable or universal.
How Tasks Fit and Where Gaps Remain
Tasks formalize what Obot AI built ad-hoc. Servers declare which tools support tasks. Tasks run asynchronously with a defined state machine: working, input required, completed, or failed. Tasks natively send the entire task object in notifications, so clients skip the second round trip to get the status. The task state machine includes an input_required status for asking the user. Adams said the agent loop maps cleanly onto tasks. But his team chose not to use tasks for workflows. They wanted an interactive experience where the user can chat with the workflow, correct mistakes, and change direction mid-execution. Their chat application gave them 80% of the needed functionality. The task specification still has gaps that the maintainers acknowledged.
Demo: A Workflow Engine Built in Gleam
Adams built a workflow engine in the Gleam programming language on his own time. Gleam compiles to Erlang and runs on the BEAM VM. He connected his Gleam MCP server to the inspector. The server exposes one tool: run_workflow. He loaded a workflow file that asks the user for their name and writes a greeting to a file. The run triggered a sampling request to the LLM. The LLM chose the ask_the_user tool, which transitioned the task to input_required. The inspector displayed an elicitation asking for his name. He entered “Donnie.” The task returned to working, the LLM decided to write the file, and the task completed. A cat of hello.txt showed the greeting. The workflow ran using only MCP sampling, tool calls, and elicitations.
Key Takeaways
- A chat application can be a single MCP tool running on an MCP server.
- Synchronous tool calls lose state on connection failure or timeouts.
- Obot AI built ad-hoc async tasks before the spec included tasks.
- Tasks natively support input required, progress notifications, and a defined state machine.
- An interactive chat workflow delivers 80% of the functionality without the gaps in the task specification.
- The BEAM VM is a viable platform for building production MCP servers in Gleam.
About the Speaker
Donnie Adams is a Software Architect at Obot AI, where he builds enterprise MCP infrastructure including the Obot MCP Gateway and agent orchestration systems. ```