How installation normally works
What a forward deployed engineer does by hand today.
No install and no redirect. The customer receives a server URL and a token and adds an MCP server under Settings, Tools and Integrations.
IntegrationsCursor
Cursor
The same inward shape as Claude, aimed at a different room. Where a customer's engineers already work inside an editor, the vendor's product reaches them there rather than asking them to leave it.
PreviewSee the deployment model
MeetextDestination network Live
One productevery customer workspaceClaudeChatGPTAtlassianGoogle ChatHubSpotMicrosoft 365SalesforceServiceNowSlackAsanaCursorLinearNotionVS CodeZendesk
✓Customer scoped✓Least privilege✓Continuously checked
Available today
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
Who has to approve it
The person whose calendar decides your go-live date.
Whoever administers the team's Cursor configuration. In a company this is usually set once centrally rather than by each developer.
Identity and OAuth model
Whose identity the product acts as, and where that grant lives.
A token Meetext issues for this environment alone, separate from the same customer's other connectors.
What Meetext owns
The repeatable half, turned into software.
The hosted MCP endpoint, the per-customer token, the frozen package behind it, and revocation.
What the customer owns
The half that is theirs and should stay theirs.
Their Cursor configuration, and which of their developers it reaches.
Capability and permission model
How capabilities map onto what the platform will let you do.
Not provider scopes. The token reaches this customer's entitlement at their approved version, and nothing else the vendor has published.
Validation
What has to execute before anyone is told it works.
The connector proves itself by connecting. Nothing is marked connected until a request arrives carrying this environment's token.
Credential lifecycle
Rotation, expiry, revocation, and who notices first.
One token per environment, rotatable, independent of every other destination this customer runs.
Deployment versioning
What happens to this customer when you ship version four.
A new vendor version does not move an installed customer. Their editor keeps calling the package approved for them.
Typical failure modes
What actually goes wrong, named rather than generalised.
An endpoint that is not publicly reachable, which fails silently on the customer's side. Refused at publish rather than discovered later.
Operational monitoring
How you learn it broke without the customer telling you.
Token issued, endpoint publicly reachable, and whether the client has ever connected.
Common questions
- Does Meetext support Cursor?
- Cursor support is in preview. The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling. Meetext does not yet operate production Cursor customer deployments.
- Who has to approve a Cursor installation?
- Whoever administers the team's Cursor configuration. In a company this is usually set once centrally rather than by each developer.
- What goes wrong with Cursor deployments?
- An endpoint that is not publicly reachable, which fails silently on the customer's side. Refused at publish rather than discovered later.
Current support status
PreviewCursor
The adapter is real and something is incomplete, either a part of the destination or real-provider proof for part of the lifecycle. The gap is stated on the page rather than discovered during an evaluation.
The adapter is complete and every path is covered by tests against a provider simulator, which proves our logic and not the provider's. Not yet exercised with real provider credentials: authorization, installation, execution, refresh and reconnect, validation, failure handling.
- Implementation
- A complete adapter.
- Proof
- Covered end to end against a provider simulator. Never run against the real provider.
Lifecycle coverage
- authorization · simulated
- execution · simulated
- failure handling · simulated
- installation · simulated
- refresh and reconnect · simulated
- validation · simulated
This label is generated from a proof registry in the deployment code, not written on this page. Available requires a complete adapter and either dated real-provider evidence or an explicit owner attestation after simulator-complete testing. The proof row above keeps those foundations apart.
2 environments free
Stop assigning an engineer to every customer.
Connect a source, publish, and send one link. Your next enterprise customer installs itself.
2 customer environments free, forever. No card required.