A managing partner asked Claude what was on a colleague's Clio calendar and got the browser instead. Clio's API supports it: calendar_id on entries, calendar_owner on every entry, visible and writeable on calendars. Most connectors don't ask.
[ KEY TAKEAWAYS ]
Yes, Claude can see a colleague's Clio calendar, provided your own Clio login can see it and the connector asks Clio's API the right way. The calendar entries endpoint takes a calendar_id filter and can return calendar_owner, with an id and a name, on every entry. The calendars endpoint can list every calendar you can see, not only the ones you can write to. Most connectors do neither: they filter entries by date only, return no owner, and list only writeable calendars, so Claude receives everyone's entries mixed together with nothing marking whose is whose, and gives up. That is what happened live on a call this week. The permission ceiling never moves: Claude sees exactly what the signed-in person sees in Clio, and a connector cannot widen that.
filter that answers the question: calendar_id on the calendar entries endpoint.
calendar types the API distinguishes: AccountCalendar, AdhocCalendar, UserCalendar.
arguments a date-only connector accepts: from, to, limit, page token. None of them names a person.
owner fields in its output. Every entry comes back without the one attribute that answers "whose".
A managing partner of a five-person firm tested this in front of us. He asked Claude what was on a colleague's Clio calendar that day. Claude tried the connector, got a list it couldn't attribute, and opened the browser instead. He wasn't annoyed; he said he wouldn't be the only managing partner who wants to know what events are on whose calendar, and he's right. So this post is the whole answer: what Clio's API offers, why most connectors don't ask, what the permission ceiling is, and how to test yours in two minutes.
"Only through the browser right now. His entries do not come back through the connector because they are mixed in with everybody else's and nothing marks which ones are his." Claude's own explanation, read aloud by a managing partner on a call this week, after it fell back to the web app. It was right about the connector and right about the API.
| Endpoint | Parameter or field | What it does | Needed for "his calendar"? |
|---|---|---|---|
| /calendar_entries.json | calendar_id | Filters entries to one calendar. Does not accept null. | Yes |
| /calendar_entries.json | fields=calendar_owner{id,name} | Returns the calendar each entry belongs to, with its name, on every entry. | Yes |
| /calendar_entries.json | owner_entries_across_all_users | With matter_id, returns the matter's entries for all users related to it. | For matter views |
| /calendar_entries.json | permission | The current user's view permission on the entry; viewer when the underlying permission is limited viewer and the user is an attendee. | For honesty |
| /calendar_entries.json | from, to, expanded | Date window; expanded returns one record per occurrence of a recurring event. | Already common |
| /calendars.json | visible, writeable, owner | Which calendars come back: visible to you, writeable by you, owned by you. | Yes, and not writeable only |
| /calendars.json | type | AccountCalendar, AdhocCalendar or UserCalendar. A colleague's calendar is a UserCalendar. | Useful |
Put together, "what is on his calendar today" is two calls. List the calendars you can see, find his by name, take the id. Then list entries for today with that calendar_id and the owner field requested. The web app does the equivalent in one click because it already knows the id.
Because the calendar tools were written for one person. The first version of any connector is built by someone reading their own calendar, and for that, a date range is enough. Ours is the example we can show rather than guess at: in the published 2.4.0 code, the entries tool accepts from, to, a limit and a page token, requests id, summary, description, start, end, matter and attendees, and nothing about the owner. The calendars tool sends writeable set to true and returns id, name, type and colour. So Claude can list calendars it can write to (usually its own), and entries from every calendar it can see, with no way to join the two.
The fix is small and we have ticketed it: return calendar_owner and permission on each entry, accept an optional calendar_id, accept matter_id with owner_entries_across_all_users, make writeable optional so viewable calendars appear, and return each calendar's permission. None of it needs a new Clio permission. It needs the connector to ask for what the API already offers. If your connector is someone else's, the same five lines are what to ask them for.
None of this widens access. Clio's API applies the same visibility as the web app: calendars you cannot see are not returned, and each entry carries a permission value for the current user. If a colleague's calendar is shared with you as a viewer, you can read it through the connector too. If it isn't shared, no parameter changes that. A connector can narrow what Claude sees (read-only mode, a date cap, a calendar filter); it cannot grant what the person doesn't have.
One trap worth knowing from an earlier post: a Clio application's permissions are frozen into each token when it is issued. If the application was registered without the Calendars permission and you add it later, sign out of the connector and back in, or the 403 will outlive the fix. Full detail in the connector setup guide.
Test on one colleague before a skill depends on it Ask "what is on [name]'s calendar this week" once, by hand, and check the answer against the web app. If Claude opens the browser or answers with everyone's entries, your connector is date-only. Fix that first; a "who is in court next week" report built on a date-only connector will be wrong quietly.
Ask these, or test them yourself
A no on any of the three means "who is in court next week" cannot be answered, whatever the sales page says. The same three apply to MyCase and other systems with shared calendars.
"Who is in court next week?"
Entries for the week across all visible calendars, grouped by owner, filtered to hearing-type events. A Monday report once the connector runs on a server, since a read-only skill can run on a schedule.
"When are all three of us free for an hour?"
The team-availability question Clio's calendar does not answer natively. With owners on entries, Claude can intersect three calendars over a date range. The calendar and scheduling post covers the durable fix.
"Does this matter have a hearing on the calendar at all?"
matter_id with owner_entries_across_all_users, which returns the matter's entries regardless of whose calendar they sit on. The right call for a quiet-matters sweep.
Want the calendar tools fixed in your connector?
The open-source connector gets this in its next release; if your firm runs it on a server we deploy the update once for everyone. If you use another connector, send us its tool list and we will tell you in one reply whether it can answer the question.
The partner's test took forty seconds and settled a question most firms never ask until a report is wrong. Ask it now, on one colleague, before you build the Monday report.
Yes, if two things are true. Your Clio login can see that calendar in the web app, and the connector between Claude and Clio asks the API the right way: filter calendar entries by that calendar's id, and return the calendar owner on each entry. If the connector only filters by date and returns no owner, Claude receives everyone's entries mixed together and cannot tell whose is whose, which is what happened on the call that prompted this post.
On GET /api/v4/calendar_entries.json, the calendar_id filter narrows entries to one calendar, and the fields parameter can request calendar_owner with id and name on each entry. There is also owner_entries_across_all_users, which requires matter_id and returns a matter's entries for all users. On GET /api/v4/calendars.json, the visible, writeable, owner and type filters decide which calendars come back; type takes AccountCalendar, AdhocCalendar or UserCalendar.
Most likely it lists calendars with writeable set to true, which returns only calendars you can write to. Calendars shared to you as a viewer are left out, so you never get their ids, so you can never filter entries to them. The fix on the connector side is to make writeable optional and to return the permission on each calendar.
No. Clio's API applies the same permissions as the web app. Each calendar entry carries a permission field for the current user, and calendars you have no access to are not returned at all. The connector can narrow what Claude sees; it cannot widen it.
Yes. Both make the same API call with the signed-in person's token. What differs is who can run the question on a schedule: a desktop connector only while that laptop is on, a server connector any time, which is what makes 'who is in court next week' a Monday morning report instead of a question someone has to remember to ask.
The Calendars permission on the Clio application, which Clio's developer documentation says covers calendars, calendar entries, calendar visibilities and reminders. Reading needs Read; creating entries needs Write. Remember that a token carries the permissions the application had when it was registered, so after changing the application's permissions, sign out of the connector and back in.
NEWSLETTER
[ WRITTEN BY ]
Petar Jovanović
Co-Founder & Technical Lead
Co-Founder and Technical Lead at Oktopeak. Builds regulated software for legal and healthcare teams, and leads the rescues of codebases other vendors left half-finished.
[ LEGAL TECH ]
LEGAL TECH INTEGRATION
Jul 2, 2026
Clio's calendar is fine for one person and strains in two places: staying in sync with Outlook or Google, and answering when several attorneys are all free at once. Here is how Clio's calendar actually works, why the sync feels off, and how firms solve the team-availability problem Clio cannot do natively.
Read ArticleLEGAL TECH
Jul 13, 2026 · 10 min read
Step-by-step setup for the Clio MCP connector, from the team that built it. The Clio developer app path that actually works, the redirect URI trap, the TRANSPORT flag that silently breaks the install, and the Clio plan tier that blocks integrations entirely.
Read ArticleLEGAL TECH
Oct 9, 2026 · 8 min read
A lawyer sorted his own skills in one sentence: anything with a yes/no gate needs a person, anything that only reads can run alone. The three-question test, his skills sorted, and what the server actually changes.
Read Article[ GET STARTED ]
30-minute call. No pitch deck. Just an honest conversation about your project.
