What each server is, and who stands behind it#
Both records are vendor-verified and both sit in the data-and-analytics category. Both namespaces resolve to the domain they claim: com.airtable to airtable.com, with the endpoint host mcp.airtable.com inside that domain, and com.supabase to supabase.com on the same basis. Neither is recorded as a community wrapper around someone else's API — each is published under the namespace of the company whose product it reaches.
The records differ in how much they declare. Airtable publishes com.airtable/mcp at version 0.1.0 and describes it as "Official Airtable MCP server — database and operations layer for agents." It lists no website and no repository. Supabase publishes com.supabase/mcp at version 0.13.0, described as "MCP server for interacting with the Supabase platform", with a website at supabase.com/mcp, a repository at github.com/supabase/mcp, and an npm package @supabase/mcp-server-supabase pinned to the same 0.13.0.
That declaration gap is the whole of the curation score difference. Airtable scores 80, Supabase 100. Both earn the same three components: verified domain (50), reachable endpoint (15) and a well-formed spec auth chain (15). Supabase adds two more that depend on having a repository at all — an OSI licence, recorded as "license Apache-2.0" (10), and a recent release, recorded as "release 0 days ago" (10). The score measures how much independently checkable evidence exists. It is not a rating of how well either server performs, and it should not be read into a security review as though it were.
The scope vocabularies are the clearest statement of what each server is oriented around. Airtable's names records, base schema, record comments, and workspaces and bases. Supabase's names organisations, projects, database, analytics, secrets, edge functions, environment and storage. One addresses a set of structured tables; the other addresses a platform that contains a database among several other services. That distinction matters more than any feature list, because it is what the access token is denominated in.
The two records also differ in how much of the claim graph is filled in at all. Both carry 18 claims. Airtable has 10 of them documented, Supabase 13. The eight claims Airtable's record leaves undocumented are not a list of missing features; they are questions the record cannot answer.
Authentication and the shape of the grant#
Both servers require authentication, and we observed this directly rather than taking it from documentation. On 19 September 2026 a POST of initialize without credentials returned HTTP 401 from both https://mcp.airtable.com/mcp and https://mcp.supabase.com/mcp. Neither exposes anything to an anonymous caller.
Both also publish the complete OAuth discovery chain. Our probe recorded all four compliance bits as present on each: the WWW-Authenticate challenge, protected resource metadata, authorization server metadata, and dynamic client registration. The registration endpoints differ — https://airtable.com/oauth2/v1/register for Airtable, https://api.supabase.com/platform/oauth/apps/register for Supabase — but each record shows a registration endpoint published, which is what lets a compliant client register itself rather than wait for a client id to be issued by hand.
Airtable advertises 7 scopes. Verbatim, from its protected resource metadata: data.records:read, data.records:write, schema.bases:read, schema.bases:write, data.recordComments:read, data.recordComments:write, workspacesAndBases:read.
Supabase advertises 13. Verbatim, from its protected resource metadata: organizations:read, projects:read, projects:write, database:write, database:read, analytics:read, secrets:read, edge_functions:read, edge_functions:write, environment:read, environment:write, storage:read, storage:write.
Read the Airtable list as four resource families. Three carry a read and a write member; workspacesAndBases:read has no write counterpart in the catalogue. The separation worth noticing is schema.bases:write against data.records:write: on the naming, structural change to a base is a distinct grant from writing rows into it. An agent that files a new supplier record would not need the schema grant as well, and the catalogue lets you draw that line. What each scope actually permits is not documented in the record, so treat the names as an indication of surface rather than a specification.
The Supabase list spans eight families and reaches beyond rows. Three members appear with no write counterpart enumerated — organizations:read, analytics:read and secrets:read. On their names, several of the writes read as infrastructure rather than data: projects:write, edge_functions:write and environment:write. secrets:read is the one scope in either catalogue whose name points at credential material, and it deserves an explicit decision of its own rather than arriving inside a bundle.
One caveat applies to both, and it is easy to miss. scopes_supported is what each server's protected resource metadata advertises as available, not what any particular client requests. Both records show read/write scope separation, so a read-first pilot is expressible on either. What neither record captures is which scopes the vendor's own client asks for by default. That set is what a consent screen enumerates, and it is worth reading that screen carefully rather than clicking through it.
Deployment, and whether the process leaves your perimeter#
Airtable declares one remote: streamable HTTP at https://mcp.airtable.com/mcp. Its deploy.self_host claim is unsupported, with the registry evidence "no installable package declared", and its packages list is empty. On the record as it stands, there is exactly one documented integration shape — your client opens a streamable-HTTP session to Airtable's endpoint under an OAuth grant, and every tool call traverses that endpoint.
Supabase declares the same hosted shape at https://mcp.supabase.com/mcp, and in addition npm:@supabase/mcp-server-supabase at 0.13.0. That package declares one environment variable, SUPABASE_ACCESS_TOKEN, marked both required and secret. The record's secrets.declared claim is supported, on the evidence "1 credential input(s), all marked isSecret" — a small but real piece of packaging hygiene, since it marks the value as a credential rather than as ordinary configuration.
The distinction to hold onto is this: self-hosting the server is not the same as self-hosting the data. The record establishes that the MCP process can run on infrastructure you control and names the credential it needs. It says nothing about where the data that process reaches is stored. What genuinely changes when you run the package is narrower than the phrase "self-hosted" suggests — the process, its logs and its credential sit inside your boundary, you choose the host and the egress rules, and you control when the version changes. If the requirement is that no data crosses a border, the package alone does not settle it, and you still need the residency answer covered in the next section.
The repository difference has a second consequence that is often the one that actually blocks an approval. Supabase declares a public repository, recorded as Apache-2.0 licensed, so a reviewer has source to read before anyone grants a production token. Airtable's repo.public is unsupported — the evidence is "no repository declared in the registry record" — so the record gives that review step nothing to point at. For an organisation whose change process requires source review of anything holding a live credential, this is the difference between a requirement the record can satisfy and one it cannot; Airtable would have to be asked directly.
Neither declares SSE; both record transport.sse as unsupported on the evidence "no sse remote declared". A client or gateway that only speaks the older transport needs an adapter in either case, so that constraint does not separate them.
What neither server documents#
Four control claims are unknown on both records, each with the reason not_documented: audit logging, access control, data residency and retention. Unknown means we found no published statement to cite. It does not mean the control is absent. Airtable may well log MCP activity; Supabase may well offer residency options. The directory cannot say so from evidence, and neither should a procurement pack that quotes it.
The practical effect is that this comparison does not separate the two on the questions a regulated buyer usually asks first. For an EU-based food or CPG business moving supplier, specification or recipe data, residency and retention are frequently the gate. Both vendors get the same questionnaire, and the answer comes back from them rather than from a registry record. Budget for that round trip in the evaluation timeline instead of hoping a directory page short-circuits it.
Neither record tells you what the assistant will actually be able to do. toolNames is null on both, because both endpoints returned 401 and our probe does not authenticate. The tool list — the names, the arguments, whether a delete exists, whether a write is a single row or a batch — is not documented in either record. Establishing it in a sandbox tenant with a real credential is the single most valuable thing to do before you scope a grant, because scopes constrain the token while tools determine what is reachable within it.
Three further unknowns sit only on the Airtable side, and all three carry the reason never_attempted rather than a check that came back empty: repo.license, repo.maintained and secrets.declared. With no repository or package declared in the record, no inspection took place. Airtable's maintenance cadence is undocumented, not poor. Supabase's was checked: last push recorded as "last push 0 days ago" at the 19 September 2026 run, from its GitHub repository.
pkg.deprecated is unknown on both, also never_attempted. Both records were last checked on 19 September 2026, and Airtable declares version 0.1.0 against Supabase's 0.13.0 — two pre-1.0 version strings, which on their own say little beyond where each publisher has put its own version marker.
Turning this into a decision#
Four constraints settle this choice, and each maps to a specific field rather than to a preference.
Where the process runs. If your rule is that no third party terminates the session holding your credential, Supabase's record offers a second path and Airtable's does not. That is a documented difference in available deployment shapes, not a judgement about either vendor's hosting.
Whether source review is required. If nothing gets a production token until someone has read the code, only Supabase's record supports the step — Apache-2.0, github.com/supabase/mcp, last push recorded as 0 days before the check. Airtable declares no repository in its record, so the requirement cannot be met from the record and has to be taken up with the vendor.
How tightly you can scope the first grant. Both catalogues contain read-only members, so a read-first pilot is expressible on either. On Airtable that subset is data.records:read, schema.bases:read, data.recordComments:read and workspacesAndBases:read. On Supabase it is organizations:read, projects:read, database:read, analytics:read, secrets:read, edge_functions:read, environment:read and storage:read — eight members, of which secrets:read is worth deciding on separately rather than taking as part of a default read bundle. Whether the tools you need actually function under those subsets is a sandbox question, since the tool list is undocumented for both.
Residency, retention and audit evidence. Both are silent. Do not let the 80 against 100 curation score stand in for an answer here — the 20-point gap is entirely two repository rules that Airtable's record cannot earn because it declares no repository, and it carries no information at all about the four control claims.
One last point that applies whichever you choose. Both catalogues enumerate write scopes, so a grant on either can carry authority to change production state — records and base schema on one side, projects, database, edge functions, environment and storage on the other. Which tools exercise that authority is not documented on either record. The approval that matters is not "can we connect this", which both make easy, but who may grant a write scope, to which workspace or project, and under what change control. Decide that before the consent screen appears, not after.