MCP
The protocol is the easy part, and it is nearly finished the day you write it. Everything expensive happens around it: whose credentials, which customer, what they bought, which version, whether it actually works, and what happens when it stops.
One endpoint with your credential is the version everybody builds first. It is also the version that cannot scope, revoke or freeze anything per customer.
/mcpEvery customer reaches the same surface with the same credential. Nothing distinguishes them, so nothing can be scoped, revoked or frozen per customer.
/mcp/products/acme·Nike/mcp/products/acme·Adidas/mcp/products/acme·VisaTheir grant, their entitled subset, their frozen version. A token issued for Nike cannot list what Adidas bought.
Two customers must never share a credential, an entitlement or a capability set. Meetext issues an MCP endpoint scoped to a single customer environment, and a token that belongs to Nike cannot list Adidas's capabilities. That isolation is what a security review asks about first.
The MCP endpoint is the easy half. The hard half is the OAuth grant behind it, held in the customer's own workspace or tenant, refreshed before expiry, and revoked by them when they choose. Meetext runs that lifecycle per environment.
A customer who bought twelve capabilities should see twelve, not the whole product with the rest returning errors. Entitlement narrows the deployment package before anything is exposed, which also narrows the permissions the customer is asked to grant.
Publishing a new version of your product changes what new customers get. It does not change what an existing customer's endpoint lists, because their tool set is frozen at install and moves only when somebody moves it.
If your upstream server changes a tool's input schema, the capability's approval is revoked rather than carried forward. An approved contract that quietly became a different contract is the failure mode nobody catches in review.
initialize succeeding proves the protocol works. It proves nothing about whether a capability can execute against your system with this customer's credentials, which is the only thing anybody cares about.
MCP is one of several ways to describe what your product can do. Whichever you use, Meetext normalises it into the same internal capability format, so the destination behaves identically and adding a new source later is an addition rather than a rewrite.
The endpoint Meetext serves speaks Streamable HTTP and negotiates its version per client, so a strict client and a lenient one both work against the same deployment.
Hosted connectors are not yet proven
The endpoint speaks the protocol hosted assistants consume, and compatibility assertions are in the test suite. The hosted path itself, which needs a public URL and an OAuth authorization server, has not been exercised end to end. We would rather say that than let you find out during an evaluation.
For the protocol mechanics, read the docs.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.