1074 operations, grouped by what they do

Grouped by capability rather than by vendor, because the question is almost always "who can read text out of an image" and almost never "what does this particular company offer today".

Read, write and destructive are marked

Every operation declares its effect, so a call that deletes something is visibly different from one that lists it before you wire either in. Across the catalogue that split is heavily weighted towards reads, which is the shape you would expect and worth knowing rather than assuming.

A schema per operation, not per provider

Each operation carries its own declared inputs and outputs, and the contract is enforced rather than documented: a field declared a number that arrives as a string is refused at the edge. That is the difference between an integration that fails loudly on day one and one that returns a wrong answer for a month.

Questions

What happens when a provider changes its API?

The operation contract is declared, so a response that no longer matches is a refusal rather than a silently wrong answer. The contract does not coerce types — a field declared a number that arrives as a string is rejected at the edge, on the way in and on the way out.

What is a capability, and why not just name the provider?

A capability is the vendor-neutral verb — ocr.read, weather.current — and 123 of them are fulfilled by at least one provider today. Calling the capability means the provider is a runtime choice rather than a line in your code, so swapping one out is a preference change and not a rewrite. Naming the provider directly still works when you actually mean that provider.