Connect your product once. Deploy it into every customer.

One MCP server URL. Acme has built a sponsorship analytics product and already runs an MCP endpoint for their own agent. They point Meetext at it once.

Meetext initializes, lists tools and imports every operation it can describe. Anything whose input schema is not an object is refused with its reason shown, rather than silently dropped.

Each operation is classified read, write or destructive. Acme enables the ones customers should get. The destructive ones cannot be published at all until somebody approves them explicitly.

Nike bought twelve capabilities, not the whole product. Entitlement narrows the package, which also narrows the permissions Nike will be asked to grant. A customer is never asked to consent to scopes for capabilities they did not buy.

Nike's security team gets an artifact naming exactly what the integration does: the capabilities, the permissions each one needs and why, where credentials live, what data crosses which boundary. Every claim is tagged with who is standing behind it, and Meetext's own observations are distinguished from Acme's assertions.

Approval is recorded against the exact snapshot they saw, identified by digest. An approval recorded against "the integration" would silently start covering whatever Acme published next.

One link. Not a call, not a shared Slack channel, not a configuration document. From here Acme is not required to be present.

The consent screen names Acme's application, not Meetext's, and lists each scope with the reason it is needed. Nike runs Microsoft 365 as well as Slack, so admin consent is a distinct step and Meetext reports it as waiting on Nike's administrator rather than as a failure.

The grant is stored under a name scoped to one customer environment. No credential is shared between two of Acme's customers, which is the property that makes the isolation claim in the security review true rather than aspirational.

The deployment package is frozen: these capabilities, these permissions, this product version. Acme publishing something new tomorrow does not change what Nike is running.

Not a token check. Meetext runs an actual read capability against Acme's system through Nike's credentials, and only then does anything claim to work.

The moment Nike gets value rather than the moment OAuth returned. This is the milestone the whole system is measured against, and the only one that counts.

A new capability, a changed schema, a fix. It goes out as a product version.

Nothing moves Nike automatically. Their security review approved a specific package, and a version that needs a permission they have not granted cannot silently apply to them. The fleet now shows Acme on four and Nike on three, which is not a problem, it is the design.

Somebody decides, and the record says who and when. If version four needs a new scope, Nike is asked for it before the upgrade rather than after it fails.

Capabilities start failing. Nike's deployment goes degraded. The protocol layer is still fine, which is exactly the disagreement that makes a single health number useless.

The failure is fingerprinted and named: Slack is rate limiting. That is a dependency, not Acme's product being broken, and the incident says so. Nobody at Acme spends a day debugging their own code during somebody else's outage.

The incident records what changed shortly before it, as correlation and only correlation. Version four went out eleven minutes earlier. Meetext notes that and stops, because a system that concludes causation from proximity will be confidently wrong at the worst moment.

If the dependency recovers, the deployment does. If version four turns out to be the cause, rollback goes to an earlier deployment of this environment that actually reached a working state, and it revalidates rather than assuming the old package still works today.