Migrated 4 of 7 Notion automations to an MCP server in one weekend
Two workflows stayed in Notion because the database UI beat any tool call
MCP scope rule: one tool does one verb, never a Swiss Army function
Result: 12 manual steps collapsed into 3 Claude prompts per publish
I spent a weekend pulling four automations out of Notion and rebuilding them as MCP tools. Three of them got faster and one got worse before it got better. The biggest lesson was not about code. It was about deciding which jobs should never leave Notion in the first place.
Why I Moved Off Notion In The First Place
My Notion setup was not broken. It was just slow in a specific way. I had seven automations stitched together with Notion buttons, formula properties, and two third-party connectors. Every blog publish meant clicking through four pages, copying a title here, pasting a tag list there, and triggering a sync that took 90 seconds to confirm. Multiply that by the 18 articles I push in a normal month and the clicking adds up.
The breaking point was a Tuesday where I lost 40 minutes to a connector that silently stopped firing. No error, no log, just a row that never updated. I checked the connector dashboard and it told me everything was healthy. It was not healthy. That kind of invisible failure is the worst kind because you trust it until you do not.
MCP changed the math for me. An MCP server lets Claude call my own functions directly. Instead of Claude writing text and me ferrying that text into Notion by hand, Claude can call a tool that does the writing into my systems. The model becomes the operator, not just the writer. If you want the deeper context on what MCP actually is and why it matters at scale, MCP: The 97 Million Agentic Foundation goes through the bigger picture.
So I made a list. Seven automations, sorted by how much human judgment each one needed. The ones at the top were pure mechanical steps: format this, push that, fetch a status. The ones at the bottom needed me to look at something and decide. That sort, done on a Friday night with a coffee, ended up being the most valuable thing I did all weekend. It told me exactly which four to rebuild and which three to leave alone. I will not pretend the sort was perfect. I moved one workflow I should have kept, and I will get to that mistake later because it taught me the real scope rule.
The 4 Workflows That Became MCP Tools
Four automations made sense as tools because they were mechanical and repeatable. Here is what each one became.
First, the publish formatter. In Notion this was a formula property that built a TLDR string and a tag list. As an MCP tool it is one function that takes a draft and returns clean markdown with the structure already enforced. Claude calls it, gets back validated output, and I never touch a formula again. This alone saved me roughly 6 minutes per article.
Second, the status fetcher. I used to open a database view to check which articles were live, scheduled, or stuck. Now Claude calls a tool that returns the same list in three seconds. No tab switching. The tool reads from the same source of truth, it just hands the data to the model instead of to my eyeballs.
Third, the social scheduler push. My old setup dumped post text into a Notion table that a connector watched. Now the MCP tool sends the post straight into Buffer through their API. Claude drafts three variants, I pick one, and the tool queues it. The 90-second sync wait is gone because there is no middle table to watch anymore.
Fourth, the image prompt builder. This one fetches a product description and returns a structured prompt I can paste into an image tool. I run a lot of those prompts through Magnific for upscaling, so getting the prompt shape right the first time matters. The tool enforces aspect ratio and style notes so I stop forgetting them.
The pattern across all four: they take input, do one transformation, and return output. No judgment required. That is the sweet spot for an MCP tool. If a task can be described as "given X, produce Y, every time," it belongs in a tool. The minute a task needs me to look and decide, the tool stops being the right home. I built each of these as a separate function rather than one big handler, and that decision is the whole point of the next section.
The Scope Rule: One Tool, One Verb
My first version of the MCP server had a single fat tool called manage_content. It took an action parameter. "format", "fetch", "schedule", "build_prompt". I thought I was being clever by keeping it tidy. I was being foolish.
The problem showed up the first time Claude called it. The model had to guess which action it wanted, fill in the right combination of optional parameters for that action, and ignore the parameters that did not apply. It got confused. It passed a tag list to the fetch action, which did nothing, and then acted like the fetch had failed. The tool description had to explain four different jobs in one paragraph and the model picked the wrong branch about a third of the time.
So I split it. Four tools, four verbs: format_draft, fetch_status, schedule_post, build_image_prompt. Each one has a tight description and a small set of required parameters. The error rate dropped to near zero. Claude reads four clear options and picks the obvious one because there is only one obvious one per job.
That is the scope rule I wish someone had told me on Friday: one tool does one verb. If you find yourself adding an action parameter, you actually have multiple tools wearing a trench coat. Split them. The model reasons better over a list of narrow tools than over a single wide one, because each tool name and description acts like a label on a drawer. Wide tools force the model to read the whole cabinet.
There is a cost to this. More tools means more descriptions to maintain and a longer tool list in every request. But the tradeoff is heavily in favor of splitting. A confused model that fails quietly is far more expensive than a slightly longer tool list. I would rather pay a few extra tokens per call than chase a wrong-branch bug that only shows up a third of the time.
The other half of the rule is naming. fetch_status tells the model exactly what comes back. get_data would not. I spent more time on tool names and descriptions than on the actual function bodies, and that ratio felt right. The descriptions are the interface Claude reasons over. For the full setup pattern I lean on, Claude Blueprint lays out how I structure these projects end to end.
What I Left In Notion And Why
Three workflows stayed in Notion, and I am glad they did. The first is my editorial calendar. It is a database with a board view where I drag article cards between columns: idea, drafting, ready, published. That drag-and-drop is faster than any tool call because the value is visual. I look at the board and instantly see I have too many ideas and not enough ready drafts. An MCP tool could return that data as text, but a wall of text does not give me the same gut read that a board does. The UI is the feature here.
The second is my research clipboard. I dump links, screenshots, and half-formed notes into a Notion page as I find them. This is messy by design. There is no structure to enforce because the whole point is to capture before I know what I have. Trying to build a tool around unstructured capture would just slow me down. Notion's quick-add is already two taps. Nothing beats that.
The third is the one I tried to migrate and regretted. My idea-scoring workflow used a Notion formula to rank article ideas by a few weighted factors. I built an MCP tool for it, and it technically worked. But scoring an idea needs me to look at the number and overrule it half the time, because the formula does not know what I am bored of writing. When the tool returned a score, I would just stare at it and decide anyway. So the tool added a step instead of removing one. I moved it back to Notion where I can see all the scores in a table and sort them at a glance.
That failure clarified the whole project. Tools are for tasks where the output is final. Notion is for tasks where I am still thinking. The moment a workflow involves me looking at the result and deciding, the database view wins because it shows me everything at once. A tool hands me one answer; a sorted table hands me the whole field. I covered the storefront side of this split in more depth when I rebuilt my product pipeline on Shopify, where the same logic applied: automate the mechanical, keep the judgment visual.
Bottom Line
The weekend turned 12 manual steps per publish into 3 Claude prompts, and the win was not the code. It was the sort. Knowing which four workflows to move and which three to leave alone is what made the rebuild fast instead of frustrating.
If you take one thing from this, take the scope rule: one tool, one verb. The fat tool with an action parameter feels tidy and reasons terribly. Split it into narrow tools with clear names and your error rate drops on its own. And before you migrate anything, ask whether the task needs your eyes. If it does, keep it in a view where you can see the whole field at once.
I am still tuning the server. Two more workflows are candidates, but I am waiting until I am sure they are mechanical and not judgment calls in disguise. If you want the foundation I built all of this on, Claude Blueprint is where I keep the patterns. Start with one tool, ship it, and let the friction tell you what to build next.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)