Inclusion
A platform belongs when it owns consequential customer, campaign, content, identity, revenue, workflow, media, or operational state; exposes meaningful access; anchors a significant category; or demonstrates a distinct interface-separation pattern.
“Best in class” here means architecturally instructive and strategically relevant—not highest market share or an endorsement.
Research layers
- Representative platform source: a first-party page used to summarize the platform’s accessible core.
- Targeted agent-role review: first-party evidence used to distinguish providers, hosts, bridges, infrastructure, and developer-context servers.
- Supporting source inventory: official links retained for implementation research but not necessarily reopened endpoint by endpoint.
SQL, structured-query, and Reverse ETL evidence
These capabilities use explicit, per-profile evidence records rather than connector-name inference. SQL can mean a native SQL editor, warehouse-mediated SQL, or a vendor query surface; GraphQL, DAX, GROQ, HogQL, SOQL, and similar languages are labeled as structured query rather than silently described as database SQL.
Reverse ETL is classified separately from MCP. A platform can support warehouse activation or writeback without exposing that action through its MCP server, and a database connector alone does not establish SQL access to the platform.
Tool and connector catalogs
Registries and directories are discovery aids, not proof that a server is first-party or that a listed capability is currently available. A name enters a public profile only after it is checked against first-party documentation, a first-party source repository, a first-party machine-readable catalog, or a directly observed tools/list response.
- MCP tools stay separate from connectors. A tool is an operation exposed by a particular MCP server; a connector links a product to another system or data source.
- Scope is explicit. Each catalog states the server variant or product surface, evidence basis, completeness, source, and review or observation date.
- Partial lists stay partial. Capability families are not expanded into invented tool names, and marketplace apps are not relabeled as native connectors.
- Discovery data stays private. Unreviewed registry matches and machine-extracted candidates are not copied into the public site data directory.
Evidence labels
Verified fact
Tied to a reviewed first-party source for the dated snapshot.
Source inventory
An official link recorded for deeper research; reachability and current scope should be rechecked.
Editorial assessment
System role, maturity, inclusion rationale, or architectural interpretation.
Proposed design
An interface or composition idea—not a claim that the vendor ships it.
Access-maturity model
- Application-bound: the native interface remains the primary practical surface.
- Extensible SaaS: APIs, events, SDKs, or extensions support meaningful external applications.
- Agent-accessible SaaS: governed capabilities are available through MCP or an equivalent agent surface.
- BYO-UI-ready platform: multiple access modes, identity, action controls, governance, and externally built experiences form a credible platform architecture.
The level is not a quality grade. A focused Level 2 API may be a better fit for a particular job than a broad but immature agent surface.
What still requires implementation validation
- Exact endpoints, tools, and event payloads
- OAuth registration, scopes, service accounts, and delegated identity
- Plan, region, beta, preview, partner, and administrative requirements
- Rate limits, quotas, data freshness, retention, and asynchronous behavior
- Terms, automated-publishing restrictions, AI-processing terms, and application review
- Idempotency, rollback, audit, observability, prompt-injection defenses, and security testing