Connected systems
Integration setup and connection types
Choose the connection that matches the task, then verify its identity, permissions, data path, and result.
Browse the enterprise integrations directory for Salesforce, SAP, Oracle, Sage, and other systems. Each listing describes a connection to scope and validate for your environment.
Several connection types serve different work
Proto can work with a system through native operations, the built-in browser, or a configured plugin. These routes have different capabilities and authorization boundaries. A signed-in browser session does not automatically provide an API connection, and a plugin does not grant permissions beyond its own credentials and service account.
| Connection | Suitable work | What to verify |
|---|---|---|
| Native ERP•AI operations | App structure, records, pages, reports, and workflows | The selected app and the user’s permissions |
| Built-in browser | Tasks carried out through a website’s interface | The signed-in identity, destination, and saved result |
| Approved API or CLI | Vendor operations called through configured tools or scripts | The service endpoint, credentials, scopes, and implementation |
| MCP plugin | Structured actions exposed by a configured server | Server ownership, credentials, available actions, and data handling |
| Model provider | Inference for the agent’s reasoning | Provider selection, account terms, and usage billing |
Choosing a model and connecting a business system are separate decisions. The model interprets the task; the system connection performs its authorized operations.
ERP•AI operations are native
Proto’s ERP•AI actions cover app structure, records, views, workflows, reports, dashboards, and pages, among other app resources. They operate with the signed-in user’s authority. Roles, deletion settings, and provider credentials still matter when the requested task reaches those boundaries.
For an external action inside an ERP•AI workflow, the workflow needs the relevant provider connection. Building or testing the graph does not supply missing credentials. Keep the workflow inactive until the necessary connection and test are complete, and verify live execution separately from preview behavior.
Browser sessions support interface-based work
The built-in browser can reuse sessions imported from supported desktop browsers. Session import is an interactive local operation and may not be sufficient for every site’s login flow. Check the visible account and organization before reading or updating business data.
Browser work is useful when the website is the available interface. It depends on that interface’s current behavior, including authentication, page changes, and human verification steps. It should not be represented as a guaranteed connector for every service with a website.
MCP connects configured tools
Proto supports the Model Context Protocol through local subprocess servers and remote HTTP or SSE servers. Remote connections can use OAuth where supported, and configuration can reference environment variables for credentials.
Global configuration is stored in ~/.proto/mcp.json. Workspace configuration can use .mcp.json or .proto/mcp.json. In the current release, plugin-management controls are hidden in the app, while servers defined in configuration files can still load. This path is intended for evaluators who can inspect and maintain the configuration.
A local server executes on the machine. A remote server receives the data passed to its actions. Review the actual server and its requested authority; the protocol alone does not establish that an integration is safe or suitable for a particular dataset.
Validate the connection with a bounded task
Begin with a read operation against a known record. Check which account performed it, whether the returned data is complete, and where the action is visible. For writes, use a disposable or explicitly approved target and inspect the saved result in the destination system.
Use the managed model plan or a supported provider connection for inference. Local-model selection is hidden in the current release, so do not assume an offline configuration. Proto’s internal action names are not a published stable application API; an integration plan should rely on the supported connection and the target service’s own contract.