B2B SaaS scope and inclusion
The Atlas centers B2B SaaS and the adjacent data, interface, and integration infrastructure used to extend it. 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 system-and-experience 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.
- Unreviewed leads are not published. A capability appears in the Atlas only after review against qualifying evidence.
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 export, artifact, feed, interface, agent, workflow, or composition idea—not a claim that the vendor ships it.
Publisher and reader corrections
Every platform profile links to a private review form. Employees, authorized partners, customers, users, and independent researchers can identify a precise statement, propose a correction, and provide first-party evidence. Publisher input is treated as evidence for editorial review—not control over the listing.
A submission does not change a profile automatically, create a verified badge, alter an assessment, or imply endorsement. Identifying details are not published through the form and are retained for no more than 12 months.
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.
Default BYO-UI relevance order
The Atlas default sort is an architectural discovery score, not alphabetical order and not a buying recommendation. It combines the published maturity level; the ten editorial dimensions for data, actions, events, identity, governance, agent access, UI extensibility, portability, observability, and documentation; explicit API, MCP, SQL/query, event, SDK, UI-extension, and Reverse ETL evidence; documented action depth; production posture; source coverage; confidence; catalog evidence; and verification recency.
Occasionally, the author highlights especially instructive examples when the published evidence makes their relevance clear. Any such judgment is documented and does not change the underlying facts or capability evidence.
When a visitor searches, text-match strength comes first and BYO-UI relevance resolves the remaining order. Alphabetical, maturity, and last-verified sorts remain available as explicit alternatives.
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
Where the site's words come from
Editorial and interface copy follows BYO-UI Message House v1.1. Research listings retain their source-record language.
Editorial copy follows a documented BYO-UI language standard. Research listings preserve cited facts and source wording where accuracy requires it.
Thesis by Harry Hawk. Site researched, designed, built, and optimized by Codex Sol 5.6 Extra High.