I read the Google Calendar API release notes so you don’t have to (yes, that’s the sort of thing I do for fun at the weekend, and no, I’m not proud of it). Two entries from the last few weeks are worth a blog post, because together they say a lot about where calendars, and software in general, are heading.

The first one, on 3 November: you can now read and update a Google Workspace user’s working hours through the API, via a new workingHours property on the calendar. The second one, announced in October, has a deadline this week: OAuth clients calling Google’s Calendar MCP server have to be marked as “an AI-powered agent” in Google’s Auth Platform, and from 11 November the Workspace MCP servers reject requests from clients that aren’t. In other words, Google now wants agents to say they’re agents, and it’s handing those agents the data they need to behave.

Working Hours Finally Become Data

Working hours have been one of those funny bits of calendar data that everybody sets and almost nothing could read. You’d tell Google you work 9 to 5, Monday to Friday, and then a scheduling tool would cheerfully propose a 7am call because, as far as it could tell, your calendar was empty at 7am. Technically correct. Practically useless.

We hit exactly this when building the Smart Scheduler in Calendrz. Our MCP tool for finding free slots, find_free_slots, takes optional working-hours parameters: a start and end time, an IANA timezone (store the zone, not the offset, as I keep banging on about) and a list of days. Under the hood it’s a small Java record called WorkingHours, and when the caller doesn’t pass anything, or passes something invalid, it falls back to anytime(), meaning no constraint at all. That’s a reasonable default for a tool, but it puts the burden on the agent: it has to know your working hours and remember to pass them every time. Some do. Some… don’t.

Now that Google exposes working hours as proper data, the source of truth can live where the user already maintains it, rather than in an agent’s memory or a prompt. That’s the right place for it, and it’s the sort of change I’d want any calendar tool (ours included) to take advantage of. Bear in mind it only covers Workspace users’ primary calendars, so if you juggle a work Google account, a client’s Microsoft 365 and a personal calendar, you still need something that pulls those together. Which, needless to say, is precisely the problem that got me building Calendrz.

Agents Have to Introduce Themselves

The second change is the more interesting one to me. Google is drawing a line between “an app a human clicks around in” and “an agent acting on someone’s behalf”, and making the agent declare itself. I think that’s spot on, and I suspect every serious API will end up doing the same.

In Calendrz we got there from the other direction. Our MCP server supports dynamic client registration: an agent registers itself with its name, and the consent screen shows the user which client is asking for access to their calendars before anything happens. Every client on that endpoint is, by definition, an agent, so we never had to ask. But for providers like Google, whose APIs were built for apps and humans, this is a big shift. Rate limits, audit trails, permissions, even pricing can now be different for agents, and the users can see who did what.

I believe UIs are on their way out: your agent (Claude, ChatGPT and the likes) will do the clicking, filling in and navigating for you. When that happens, the API and the MCP server are the product, and agent experience matters more than how polished the buttons are. Clear tool descriptions, sensible defaults, real data such as working hours, and an honest way for agents to identify themselves: that’s the new UX. Google adding all of this in the space of a few weeks tells me they’ve come to the same conclusion.

So What Now?

If you build anything that touches calendars: check whether your OAuth client calls Google’s MCP server and, if it does, mark it as agentic before the deadline (Murphy’s law says you’ll find out on Wednesday morning otherwise). Start reading working hours from the source instead of asking users to type them in again. And look at your own APIs with an agent’s eyes: what would an agent need to know to not book someone at 7am?

Moral of the story: agents are becoming first class citizens of the calendar. Better they arrive knowing when you’re actually free 😉