How I Connected Claude to Our Content Calendar With MCP (and Stopped Burning API Tokens)

This is part 2. In part 1 I wrote about how ContentCal grew from replacing an Excel sheet into the marketing team's daily tool. This post is about the one change that finally fixed our AI costs: connecting Claude to the calendar through MCP.

The problem: the tokens kept running out#

ContentCal uses AI in a few places:

• Generating a whole month of posts for a brand
• Writing captions and descriptions for each post
• AI insights, such as one person's efficiency or a whole team's

Every one of those spends tokens. I had connected the app to Claude Haiku 4.5 through the API, which is a good, fast, cheap model. But the free credit sat under five dollars, and monthly planning is exactly the kind of request that is long on input and long on output. The budget was gone far quicker than I expected.

I did not want to switch the features off. I wanted a different way to pay for the thinking.

First idea: run a local model#

The obvious alternative was a local LLM. Tokens on your own machine cost nothing, so I looked at running Ollama with a Qwen model.

The problem is not the model. It is where it lives:

• A free hosting server cannot run a model of that size.
• So it would have to run on a laptop that acts as a server.
• And that laptop would need to be on all the time. Mine cannot be.

A server that is only available when my laptop is awake is not something a team of ten can depend on. I needed another route.

The breakthrough: MCP#

Then I looked properly at the Model Context Protocol. MCP is an open standard that lets you connect your own apps to Claude. You write a small server that lists what your app can do, and Claude can call those actions during a conversation.

That flips the design.

The app no longer needs to ask a model for a plan. Claude can read the calendar, make the plan and write it back using the app's own tools.

What Claude can now do#

I exposed a deliberately small set of actions from ContentCal. Claude can see which workspaces exist, read the planning context for a brand and month, look at post templates, check trade shows, and then propose posts for the calendar. The same goes for design briefs and email templates.

Because the tools are named for what they do, a request becomes plain language:

Plan next month's content for the Canada workspace.
Use the planning context and our post templates,
avoid the trade-show dates already on the calendar,
and propose the posts.

Claude reads the context, builds the month and writes it back as proposals in the calendar. It is the same job the in-app AI planner did, but the model work happens in the conversation.

Why "propose" matters#

One design choice I would repeat: the tools propose content rather than publishing it. A proposed post sits in the calendar for a person to review, edit or delete before it goes anywhere.

That is a safety rule, not a detail. An AI with write access to a team's calendar should be able to do a lot of the typing and none of the final deciding. If a month comes back wrong, you delete the proposals and ask again.

What it did not fix#

I want to be straight about the limits:

• It is conversational, not automatic. Someone has to start the conversation. For things that must run on a schedule without a person, a direct API call is still the correct tool.
• You are building a server. The MCP server is real backend work: tool definitions, authentication, and careful thought about what is exposed.
• Access is a security decision. Anything you expose, Claude can use. Keep the tool list short and review it as you would any new API.

If you want to try this#

1. List the five or six things a person actually does in your app. Those become your tools.
2. Make every tool narrow. "Create a draft post" is safer than "edit anything".
3. Prefer propose over publish. Keep a human at the last step.
4. Add the server to Claude and test with small requests before asking for a full month.
5. Keep the API route for features that must run unattended.

Where this leaves us#

The AI features that used to drain a small API budget now run through a Claude conversation connected to the calendar. We still use the API where a feature has to run on its own, but the big, token-heavy work - the monthly plans - no longer depends on it.

If you have an internal tool and want Claude connected to it safely, with a short list of tools and a human at the final step, share a short brief through the project form on this site and we can scope it together. You can also read about the AI automation service or browse more case studies.