1,784 actions, 62 verbs

The ModuleX catalog exposes 1,784 actions across its integrations. Our published library of 65 task recipes calls 62 of them.

That is 3.5% of the action surface, and it is the most interesting number we have found in our own data. Both figures come from files that ship with this site — the integration registry behind the catalog pages, and the recipe modules behind the use-case pages. The action names in the recipes are validated against the registry when the site builds, so a recipe cannot reference an action that does not exist.

The usual caveat applies and it is a real one: this counts the actions our published recipes call. It is evidence about how described tasks decompose into tool calls. It is not production traffic, and we are not claiming otherwise.

Two actions are a quarter of every call

Across the 65 recipes there are 276 tool calls. The two most common are create_page (34) and post_message (34) — together, one call in four.

Those two are not domain operations. One writes a page in Notion; the other posts to Slack. They are the two ways a task can end — put the result somewhere durable, or put it somewhere people will see.

The next tier says the same thing from the other end: search (20), send_message (14), list_charges (10), create_issue (10). Read something specific, produce something specific. The middle of a task varies enormously; the beginning and the end barely do.

Four verbs carry the set

Grouping the 62 used actions by their leading verb: create (16 distinct actions), get (13), list (8), search (7). Everything else — retrieve, send, post, read, schedule, set, assign — is a handful.

This is a plainer vocabulary than the catalog's. A registry of 1,784 actions contains a great deal of precision: specific reports, specific object types, specific sub-resources. The slice that recurs across real task descriptions is closer to four verbs applied to whatever noun the tool happens to own.

The design implication is not "ship fewer actions". The long tail exists because somebody's workflow ends there, and the narrow integrations we have written about elsewhere earn their place precisely by covering one specific thing well. The implication is about naming: an action that reads as a verb-plus-noun gets selected correctly far more often than one named after an endpoint.

We are asserting that from our own experience, but selection error is independently measurable. Work presented at the ICML 2026 Workshop on Failure Modes in Agentic AI, benchmarking six frontier models over 580 tool-use scenarios, separates picking the wrong tool from omitting a call and from repeating one — and found wrong selection accounted for up to a quarter of weaker models' failures, with the strongest configuration still reaching only 74.8 overall accuracy. Those scenarios are adversarially weighted and use simulated tool responses, so the rate is not a production figure; what it establishes is that selection is a distinct failure mode worth naming for.

Reads are more varied; writes are more frequent

Half the used actions are read-shaped — get, list, search, run a report: 34 of the 62.

But by call count the split inverts. Read-shaped calls are 117 of 276; the remaining 159 write something.

That inversion is the shape of a task. Gathering is exploratory, so it reaches for many different reads. The payoff is singular: one page created, one message posted, one issue filed. A task that reads five things and writes one is normal; the reverse almost never happens.

It also explains why the approval gate falls where it does. If writes were rare and incidental, gating them would be a formality. They are not incidental — they are the point of the task — which is why the gate is on the step that matters rather than sprinkled across the run.

Forty tools, and the same three keep appearing

The 276 calls touch 40 distinct integrations. We have written before that the recipes declare 41 integrations and concentrate heavily on Notion, Slack, and Gmail; the call-level data agrees and sharpens it.

The concentration is not that those three are more capable. Notion exposes 19 actions and Slack 8 — neither is near the top of the catalog by breadth. They recur because they are where things are kept and where things are said. The domain tool in the middle of a task changes constantly; the endpoints of a task are stable across teams in a way we did not expect when we started writing.

What we take from it

Three things, and the third is the one that changed how we write.

A catalog's breadth is insurance, not utility. 1,784 actions exist so that the one your workflow terminates in is present. Almost none of them will appear in any given task, and that is fine — but it means counting actions is a poor way to evaluate a platform, including ours.

Selection quality beats surface area. Sixty-two actions carried 65 distinct tasks. What made them usable was that their names describe what they do to what — not that there were many of them nearby.

Write the ending first. Once we noticed that a quarter of all calls were "put this in Notion" or "say this in Slack", the recipes got easier to write, because the last step was the part we actually knew. A task without a clear ending was consistently a task we had not finished thinking about.