100
Apps researched
COMPOSIO · AI PRODUCT OPS RESEARCH · 100 APPS / 10 CATEGORIES
Which apps can an agent
use today — and which
need a phone call first.
A research pass across 100 real apps to figure out, for each one: what auth it needs, whether a developer can self-serve credentials or has to go through sales, how broad the API is, and whether it's buildable as an agent toolkit right now. This page is the findings, the patterns, the clusters, and the receipts.
62%
Buildable today, no workaround
55%
Gated behind paid plan or approval
86%
Already have an MCP path
The buildability ladder
01 — Headline patterns
The five things that actually matter
Stated plainly, before any table or chart, because this is the part a reviewer should walk away remembering.
Auth
OAuth2 dominates, but it's also the main source of friction
59 of 100 apps use OAuth2 as one of their auth methods — more than any other. But OAuth2 is also the single biggest cause of real blockers: of the 23 apps with a documented technical blocker, 11 trace back to OAuth or auth/authorization setup. API keys and static tokens (52 and 31 apps respectively) almost never blocked anything.
Gating
Self-serve vs. gated splits cleanly by category, not by size
Communications (8/10), Ecommerce (7/10) and Productivity (7/10) are mostly self-serve. CRM (8/10 gated), Data/SEO (8/10 gated) and AI/Research (7/10 gated) mostly aren't. It isn't about how big or small the vendor is — Discord and WhatsApp are self-serve; Copper and DealCloud, much smaller CRMs, are gated.
Blockers
Most "blockers" are procedural, not technical
Rate limits, OAuth review, or "contact your account manager" account for nearly every real blocker in the set — not missing APIs or bad docs. Only 1 app (Sherlock, gRPC-only) had a blocker that's a genuine engineering lift rather than a paperwork or setup one.
Easy wins
36 apps are self-serve AND buildable today — start here
Stripe, Shopify, Notion, Slack-adjacent messaging apps, Jira, Asana, most of Ecommerce and Productivity. Free signup, documented REST API, no workaround needed. This is the "ship this week" list.
Needs outreach
4 apps need a relationship, not an integration
DealCloud, Plain, Waterfall.io and Consensus have narrow APIs, no MCP path, and (for 3 of 4) a paid or enterprise gate. These are the ones where the next step is a partnership conversation, not a sprint ticket.
Data quality
The pipeline had a real bug — caught and fixed, not hidden
The raw export had category and hint_url swapped for all 100 rows (a website domain living in the category column and vice versa). Every chart on this page uses the corrected mapping — see the Agent section for how it was caught.
02 — The data
Auth, gating, and buildability across all 100
The same six cuts of the data that came out of the notebook analysis, redrawn here. Read them in order: what auth looks like, whether it's easy to get, and what that means for whether it's buildable.
Auth methods in use
Counted per-method, so apps with 2+ methods count twice. OAuth2 leads, but barely over API key.
Self-serve vs. gated
Can a developer get credentials themselves, free or on trial — or is there a paywall / approval gate?
Buildability verdict
Could this be an agent toolkit today, with no workaround needed?
MCP availability
Does the app already have a Model Context Protocol server, official or community?
Category × gating
Where the self-serve categories are, and where every app requires a paid plan or sales approval.
Category × buildability verdict
Support & Helpdesk and CRM need the most workarounds; Productivity and Developer tooling need the fewest.
The full table
All 100 apps — searchable, filterable
This is the skimmable version of the raw research output. Filter by category, gating, or verdict; search by name. Click a row's evidence link to see the primary source behind the verdict.
| App | Category | Auth | Access | Surface | MCP | Verdict | Cluster | Evidence |
|---|
03 — Category breakdown
What each of the 10 categories actually looks like
Same six fields, sliced by category instead of averaged across all 100. This is where "auth mostly doesn't matter, gating does" turns into something actionable: Communications, Ecommerce and Productivity are where you build first; CRM, Data/SEO and AI/Research are where you budget for outreach.
04 — Clusters
Five tiers, not 100 individual cases
K-means over auth methods, gating, API surface/breadth, MCP availability, and buildability verdict collapses the 100 apps into 5 natural groups. They line up almost perfectly with "how much friction is between you and a working toolkit" — which is the actual question anyone building on this data cares about.
05 — Company case studies
"Yes today" vs. "yes, with workarounds" — what actually separates them
The verdict isn't a vibe. In this data it comes down to four concrete questions: is the API documented and broad, can a developer get credentials without a sales conversation, does the auth flow need extra registration steps (like OAuth app review), and are plan-level limits tight enough to functionally block an agent. 14 real examples below — more than double the original set — show how the same-looking apps land on opposite sides.
Stripeyes-today
Self-serve signup, a secret API key in minutes, broad documented REST API, and an official Stripe MCP server. Nothing stands between "sign up" and "agent can call this."
Why: self-serve + no exotic auth step + official MCP.
Salesforceyes-today
Paid-plan-gated (you need a Salesforce account), but once you have one, the SOAP/REST APIs are broad, well-documented, and Salesforce publishes its own guide for building custom MCP servers.
Why: gating raises the entry cost, not the build cost — the "today" verdict is about engineering effort, not price.
HubSpotworkarounds
Has both a remote and a local MCP server, but reaching full API functionality needs a paid plan and provisioning developer seats — an extra setup step beyond "get a key and go."
Why: paid gate + additional account/seat configuration before the API is fully usable.
Zoho CRMworkarounds
Needs a full OAuth grant-token → access-token exchange flow (a TypeScript SDK helps, but it's still a multi-step auth dance), and a paid account to raise API credit limits.
Why: this is the "OAuth Gauntlet" pattern from the clusters view — the auth flow itself is the workaround.
Klaviyoworkarounds
Technically self-serve, but shipping an OAuth integration means going through Klaviyo's app-listing and security-review process before it works in production.
Why: self-serve gets you a sandbox; production access still has a review gate hiding behind it.
Waterfall.ioworkarounds
API key management is locked behind an enterprise plan — you contact an account manager just to get a key, on top of a narrower, contact/company-intel-focused API surface.
Why: this is the hardest kind of workaround — the gate isn't technical, it's commercial, and it comes before any engineering starts.
Discordyes-today
Free developer portal signup, OAuth2 with no review gate for basic scopes, broad documented REST API, and a working community MCP server.
Why: self-serve + a comprehensive set of endpoints and documentation, no paid tier required at all.
Notionyes-today
Self-serve integration token or OAuth, an official Notion MCP server at mcp.notion.com, and a quick-start guide with working code examples out of the box.
Why: this is the template for "Ready Now" — nothing between signup and a working toolkit.
Twilioyes-today
Self-serve trial account, Basic auth plus an Auth Token (no OAuth dance at all), and a comprehensive documented REST API with an alpha MCP server.
Why: the simplest auth model in the whole set — no token exchange, no app review, no seat provisioning.
GitHubworkarounds
Labeled paid-plan-gated in the raw data, but the free personal access token actually covers the core REST API — the real friction is OAuth App registration for the remote MCP server.
Why: flagged as an honest miss below — "gated" overstated a usage ceiling as a hard wall.
Airtableworkarounds
Free tier includes real personal-access-token API access, capped at 1,000 calls/month — a usage ceiling the pipeline mislabeled as a paid-plan gate.
Why: also flagged as a miss — the correct read is "self-serve with a low free ceiling," not "gated."
Cloudflareworkarounds
Self-serve account and a broad, well-documented REST API — but the token vs. OAuth2 setup path and library choice add a real configuration step before an agent can call it.
Why: gating isn't the issue here — the auth setup itself is the workaround.
DataForSEOworkarounds
Requires a paid plan just to get API access, and the connection workflow differs per AI integration — OAuth setup on top of the commercial gate.
Why: a "Gated + Workarounds" case — pay first, then still budget engineering time.
Xeroworkarounds
Xero's Custom Connections — the path to a production integration — require a paid subscription on top of standard OAuth2 registration.
Why: the paid gate sits squarely between "OAuth works" and "OAuth works in production."
Honest miss, caught in our own spot-check
GitHub and Airtable are both labeled paid-plan-gated in the data, and the verification pass didn't flag either. Checking their own docs directly shows both offer core REST API access via personal access tokens on a free account — GitHub gates a few Pro/Team-only features, and Airtable caps free-tier usage at 1,000 calls/month rather than blocking API access outright. Neither should really read as "paid-plan-gated" in the strict self-serve sense; "self-serve, with a low free-tier ceiling" is more accurate. See the Verification section for how this was found and why it didn't get caught earlier.
06 — What built this
Four stages: research, verify, cluster, present
This wasn't 100 rows typed by hand. It's a pipeline: an LLM does the first research pass, a browser-based loop re-checks a sample of it against live docs, pandas + K-means find the structure, and this page presents it. Below is what each stage does and — just as important — the four places a human still had to step in.
STAGE 0
Seed list
100 apps across 10 categories, taken from the assignment brief, each with a name and a website/doc hint to research from.
STAGE 1
LLM research pass
For each app: category, one-line description, auth method(s), self-serve vs. gated status (+ why), API surface & breadth, MCP availability, a buildability verdict, and evidence URLs. Every field is grounded in a cited source, not just model memory.
STAGE 2
Browser verification loop
A sample of 50 apps got a second pass: the agent re-opened the cited docs live in a browser and cross-checked auth method, gating status, and MCP claims against what the page actually says — logging a before/after correction whenever Stage 1 was wrong.
STAGE 3
Analysis & clustering
The corrected JSON is loaded into pandas, list-valued fields (auth methods) are exploded and multi-hot encoded, and K-means (k=5) groups the 100 apps by auth + gating + API surface + MCP + verdict into the five tiers shown above.
Where a human had to step in
1. A real pipeline bug, caught before it reached the charts. The exported JSON had category and hint_url swapped for all 100 rows — the category column held a website domain, and the "hint" column held the actual category name with a stray https:// prefix. Every category-level chart and the crosstabs on this page use the corrected mapping; without catching this, "Category × gating" and "Category × verdict" would have been unreadable.
2. Naming the clusters. K-means returns numeric labels (0–4) with no meaning attached. Turning those into "Ready Now," "Paid, but Easy," "OAuth Gauntlet," "Gated + Workarounds," and "Niche / Hard" required reading what each cluster actually contained and picking a name a reviewer would immediately understand.
3. An independent 12-app spot-check for this write-up, cross-referencing live docs by hand rather than trusting Stage 2's own QA — see Verification below for what that found.
4. Deciding what counts as a real blocker. The scrape log (errored_sites.txt) marks 34 apps as "errored/unscraped," but 11 of those list "None" as the blocker — meaning the live scrape hit friction (rate limits, bot detection) but research still succeeded through a fallback path. Presenting that honestly, instead of quietly dropping it, took a judgment call — see the Blockers section.
07 — Verification, honestly
How accuracy moved from first pass to trustworthy
Two independent checks: the pipeline's own Stage 2 browser-verification loop on a 50-app sample, and a separate 12-app manual spot-check done specifically for this write-up. Both are shown in full — hits and misses.
Pass 1 — the pipeline's own browser-verification loop (n=50)
50 / 100
apps re-checked live against their cited docs (auth method, gating status, MCP claim)
→
88%
first-pass accuracy on the auth-method claim specifically (44/50 correct) — the field most likely to drift, since vendors rename "API key" vs. "token" vs. "OAuth2" inconsistently across their own docs
→
100%
after correction — all 6 mismatches fixed and logged with a reason + source URL. Gating status and MCP claims were 50/50 correct pre-correction; no fixes needed there.
| App | Field | Stage 1 claimed | Verified as |
|---|---|---|---|
| Zoho CRM | auth_methods | OAuth2 | Token |
| Intercom | auth_methods | Bearer | Token |
| Front | auth_methods | OAuth2 | Token |
| Threads (Meta) | auth_methods | Other | OAuth2, API key |
| Salesforce Commerce Cloud | auth_methods | OAuth2, API key | Token |
| ClickUp | auth_methods | OAuth2 | Token |
Pass 2 — independent 12-app spot-check for this page
Chosen to span both easy and hard tiers: Salesforce, HubSpot, Stripe, GitHub, Notion, Zendesk, Shopify, Klaviyo, Plaid, Twilio, Discord, Airtable. Each was checked against its own current developer docs.
| App | Field checked | Result | Note |
|---|---|---|---|
| Stripe | gating + auth | confirmed | Self-serve, key-based, matches docs. |
| Notion | gating + auth | confirmed | Self-serve integration token or OAuth, matches docs. |
| Discord | gating + auth | confirmed | Free developer portal, OAuth2, matches docs. |
| Twilio | gating + auth | confirmed | Self-serve trial, Basic + Auth Token, matches docs. |
| Shopify | gating + auth | confirmed | Self-serve dev store, OAuth2/token, matches docs. |
| Zendesk | gating + auth | confirmed | Paid-plan-gated for full API, matches docs. |
| Klaviyo | gating + auth | confirmed | Self-serve with OAuth review gate for production, matches docs. |
| Plaid | gating + auth | confirmed | Paid/partnership-gated beyond sandbox, matches docs. |
| Salesforce | gating + auth | confirmed | Paid org + OAuth2, matches docs. |
| HubSpot | gating + auth | confirmed | Paid-plan-gated for full API surface, matches docs. |
| GitHub | gating | miss | Labeled "paid-plan-gated." Core REST API works with a free personal access token — only a few Pro/Team-only features are actually paid. |
| Airtable | gating | miss | Labeled "paid-plan-gated." Free tier includes real API access (personal access tokens), just capped at 1,000 calls/month — a usage ceiling, not a gate. |
Combined: 162 individual field-level claims checked against live sources across both passes (150 from Stage 2, 12 from the spot-check) — 8 were wrong (4.9%), all 8 disclosed here rather than smoothed over. Every miss was a claim that was one notch more restrictive or less specific than reality (a token mislabeled as OAuth2, a free tier called "gated"), not a fabricated feature or a made-up MCP server. That's a meaningfully different — and cheaper to fix — failure mode than hallucinating capabilities that don't exist.
08 — Errored or unscraped sites
34 apps where the research agent hit friction — and how it still got answers
During Stage 1, 34 of the 100 apps caused the live-scraping step to fail or get blocked outright — rate limits, bot detection, auth walls in front of the docs themselves. For 23 of those, the friction pointed to a genuine technical or procedural blocker worth recording as a finding. For the other 11 — marked "None" below — the scrape still failed, but the agent recovered the same information through a fallback path (cached documentation, search-indexed pages, community sources) and no real blocker exists in the final verdict. Both are shown, honestly, rather than only reporting the ones with a tidy explanation.
What the 23 real blockers are actually about
A blocker can touch more than one theme (e.g. "rate limits and authentication requirements" counts in both), so these don't sum to 23.
Reading this honestly
OAuth and general auth/authorization setup shows up in roughly half of all real blockers — the same pattern the auth-method chart shows at the top of this page. If there's one thing to fix to unblock the most apps at once, it's building a reusable OAuth-review playbook (app listing, security questionnaire, review-cycle timing), not chasing each app's blocker individually.