It Assumed the Platform Wouldn't Let Us

The assumption

YouTube and TikTok default to reminder-style publishing (defaultToReminders), unlike LinkedIn which rejects schedulingType: notification outright.

Written into two protocol docs as a per-platform requirement, and applied to all ten YouTube and TikTok posts.

What was actually true

defaultToReminders is a per-channel setting, not a platform constraint. On both channels its value is false.

$ get_channel(6a65e5604b2d03035f42a6f4)   # TikTok
{ "service": "tiktok", "metadata": { "defaultToReminders": false } }

Direct API publishing was available the whole time. Switching all ten posts to schedulingType: automatic was accepted without complaint.

Why it looked right

I inferred a capability limit from the existence of a field rather than its value.

The reasoning had a real basis. TikTok genuinely does gate direct posting behind approval for some account types; instagram, youtube and tiktok are exactly the services in Buffer's schema carrying defaultToReminders, and LinkedIn isn't. So "these three need reminders" is a coherent story that explains the schema.

It was also the conservative choice, which is what let it through. Choosing notification felt like the safe default — worst case an extra tap on a phone. That framing hid the fact that it silently defeated the entire purpose of the task. Defensive defaults still need to be checked, because "safe" and "correct" came apart here.

And I had already called list_channels, which returns each channel's id. One more call per channel would have returned the metadata.

How it got caught

Thomas saw "Notify" badges in Buffer's UI and said he didn't want that — he wanted the API to post. The screenshot showed it plainly.

Not caught by any check of mine. Caught because the wrong behaviour was visible in an interface a human looked at. Had these gone into a queue unwatched, the first symptom would have been five videos silently not publishing.

The check that would have caught it

get_channel(<id>) → metadata.defaultToReminders

One call per channel, against an MCP server already connected and already used in the same session.

Notes

Generalises past this API. A field named after a constraint is not the constraint. defaultToReminders, isLocked, canPublish, requiresApproval — the name describes what the field governs, not what it currently says. Reading the schema tells you a limit can exist. Only the value tells you whether it does.

Same session as the homepage case, same mechanism: reasoning from a description of a system instead of querying it. That one read a stale document; this one read a live schema. The schema being current didn't help, because the error was reading structure as state.