Integration models
Every integration carries the same three labels in the app's catalog, on each connection's page and in the connector table; the public integrations page shows the first. They describe the vendor's interface, not its quality. A vendor's own MCP server and a connector Discontinue built can both be the right choice; they work differently, and the labels say how.
Your own MCP servers and APIs have no vendor, so they carry no "Who stands behind it" label.
Who stands behind it
- Discontinue verified: Discontinue built or tested the integration and keeps it working; see Discontinue verified.
- External: the vendor runs the API or MCP server and Discontinue connects to it as it is. Its tools, their names and their descriptions come from the vendor.
- Coming soon: listed, but not connectable yet.
Discontinue verified
Discontinue built the integration itself, or tested the vendor's server end to end, and keeps it working. The label says who stands behind the integration. What an agent may do with it and what a report gets from it are the two labels below.
Agent permissions
- Per area: an admin grants an agent one or more areas of the integration, for example reservations but not finance, each with its own actions.
- Whole connection: an agent gets every tool of the connection. Each tool is labeled read or write, and the labels decide what asks for approval.
In both models every call acts as the connected account. Neither limits the data that account can see in the vendor's system.
Report data
Whether a report gets all the data depends on the tool it reads, not on the integration. Every connection's page marks each read tool:
- Complete: Discontinue fetched everything. It paged through the vendor's result to the end, or the vendor returns the whole result in one answer.
- Not guaranteed: nobody has confirmed that the vendor returns everything. The data may be complete, but a report built on it is marked as not guaranteed. Narrow the request so one answer holds what you need.
After every run a report shows the result per data source: Complete with the row count, Incomplete when a limit was hit, with how many rows of how many, or Not guaranteed.
In the app's catalog and the connector table an integration reads Complete report data when every read tool is Complete, otherwise Report data varies by tool.
One account per connection
A connection to an MCP server (from the catalog or your own) or to a Custom API acts as the one account the admin connected, for every member's chat, every report and every agent that uses it. The vendor sees that account: its own log shows that account on every read and write, whoever asked in Discontinue. The connection's page shows who connected it and when, and the vendor account where the vendor names it at sign-in.
- Use a dedicated account, named after Discontinue or after the agent, rather than a person's. The vendor's log then says where a change came from, and you can remove the access without touching anyone's own account.
- One connection per purpose. Connect the same vendor more than once when the purposes differ, for example a read-only account for chat and reports and a separate account for the one agent that writes. Each connection has its own labels and its own agent grants.
- Scopes are fixed at connect. More permissions mean a reconnect.
Two caveats: each account may take a seat in the vendor's plan, and when two connections offer the same tools, name the connection you mean in chat.