For the build I just used a Python MCP SDK: https://github.com/modelcontextprotocol/python-sdk
Now, I'm not a fast dev. Still, in 2 days I had Claude Desktop filing and responding to emails better than any assistant I've worked with (human or otherwise). None of this was due to my skill. I was basically just wrapping msgraph calls in the same @mcp.tool decorator over and over.
In fact, I spent more time fiddling with msgraph auth & api-calls than I did on the MCP server itself.
Today, in a typical workflow, I just tell Claude to "sort my inbox" and it handles everything from filing mails, creating folders, writing responses, scheduling meetings, flagging actions, etc.
For anyone wondering about MCP, the following struck me:
1. It was the fastest "time-to-capable" I've had on any software build.
2. It was fully "human-capable" in a way that I have not experienced with "agentic workflow" approaches... it just worked.
3. There are nuances to how you "architect" your tool signatures for best results. For example, I had to name one parameter html_code_mail_body to prevent Claude from using plaintext in mails.
4. It was better to make pure, highly cohesive and atomic tools and let the LLM combine them for more complicated tasks.
5. It was so easy to build, all companies are likely to launch official MCP servers eventually.
Overall, I think MCP offers a stark alternative to the "agentic workflows" model. In a technical sense, each step in a workflow is highly coupled to its upstream/downstream counterpart. This makes them both rigid and fragile. That's the source of some of the "RPA smells" people talk about with workflow agents.
MCP is classic dependency inversion. The llm becomes an abstraction that can self-orchestrate using any tool it wants, in any order, based on the task set for it.
Norcim133•6mo ago