Connectors
A Connector gives agents access to external enterprise systems and internal services through Axec, allowing them to retrieve information, update data, and perform actions in those systems.
For example, a support agent might need to search a ticketing platform, retrieve customer records from a CRM, or update an internal inventory service. Each Connector describes how Axec reaches a service, which operations are available, and what credentials Axec needs to authenticate upstream.
Axec provides a catalog of Connectors for popular services such as GitHub, Jira, Slack, and Google Drive, and manages these integrations through their configuration, upstream credentials, and allowed capabilities. You can also connect your own internal HTTP APIs and MCP services using custom Connectors, or include reusable definitions in your deployment’s catalog; see the Connector reference for the bundled integrations and custom service requirements.
Services and capabilities
Section titled “Services and capabilities”Services expose their operations in different ways: an MCP server provides named tools that agents can discover and call, while an HTTP API provides endpoints that clients invoke using HTTP methods such as GET and POST.
Axec supports both through Connectors, using upstream_protocol to distinguish an upstream MCP server (mcp) from an HTTP API (http).
MCP servers
Section titled “MCP servers”The Model Context Protocol (MCP) provides a standard way for agents to discover and invoke tools, with each tool describing its name, purpose, and input schema so the agent can construct a call.
For an MCP Connector, Axec uses configured tool definitions or discovers them from the upstream server, then makes the permitted operations available through Axec.
Example: A ticketing MCP server might expose a search_tickets tool that accepts a query and a create_ticket tool that accepts a title and description.
HTTP APIs
Section titled “HTTP APIs”An HTTP API exposes operations through a combination of HTTP method and endpoint, with parameters or a request body supplying the information needed to perform the operation.
For an HTTP Connector, Axec uses a configured OpenAPI contract, a machine-readable description of the supported API operations and their inputs. Axec can expose these operations as MCP tools, allowing agents to use a service even when the upstream system does not provide an MCP server.
Example: A ticketing API might provide GET /tickets to retrieve tickets and POST /tickets to create one, with the Connector’s OpenAPI contract describing the inputs for each operation.
Capabilities in Axec
Section titled “Capabilities in Axec”A capability is Axec’s term for an individual operation available through a Connector, whether that operation comes from an MCP tool or an HTTP API. This gives Axec a common way to describe and control access to operations across both protocols.
Each capability has a key within its Connector, and Application dependencies use these keys to select which operations an Application may access. The capability contract describes the available operations and their inputs.
For an illustrative ticketing integration, equivalent operations could appear as:
| Operation | MCP tool | HTTP API | Capability key |
|---|---|---|---|
| Retrieve tickets | search_tickets |
GET /tickets |
tickets.read |
| Create a ticket | create_ticket |
POST /tickets |
tickets.create |
An administrator could allow a reporting agent to use tickets.read without allowing tickets.create, regardless of whether the underlying service uses MCP or HTTP. These names are examples, not a fixed provider catalog.
Exposing a capability does not automatically authorize every Application to use it, and an allowed operation still requires an eligible upstream credential when the service needs authentication.
Agents can use a Connector individually or access tools from several Connectors through a Gateway Application. See Execute tools and API requests for both approaches.
Upstream authentication
Section titled “Upstream authentication”Each Connector uses one authentication method to access the upstream service, such as OAuth or an API key. This method determines which credentials Axec needs, while the Application’s allowed capabilities determine which operations the agent can perform.
| Authentication method | Credential source | Owner |
|---|---|---|
| OAuth | OAuth tokens in a Connection | User |
| Personal credential | A typed personal credential in a Connection | User |
| Vaulted credential | A shared Vaulted Credential | Workspace |
| No authentication | No upstream credential | None |
With OAuth, the User authorizes Axec at the upstream provider, and Axec stores the resulting access and refresh tokens in the User’s Connection.
Example: Alex authorizes access to a calendar service. An agent can then use delegated authority to read Alex’s calendar through the Connector.
This uses upstream OAuth authorization, based on OAuth 2.0 (RFC 6749). The provider’s scopes limit what the upstream token permits.
Personal credentials
Section titled “Personal credentials”With personal credentials, the User supplies a credential for the upstream service, using the fields defined by the Connector’s credential profile, which also specifies how Axec applies the credential to requests.
Example: Alex supplies a personal API token for a ticketing service. Axec stores it in Alex’s Connection and uses it only through authorized access to that Connector.
Vaulted credentials
Section titled “Vaulted credentials”With vaulted credentials, Axec uses a shared credential that belongs to the Workspace, such as a bearer token, API key, or Basic credential supported by the Connector’s credential profile.
Example: A scheduled agent reads shared tickets using an Workspace-managed API key. It does not use Alex’s personal ticketing account.
Vaulted credentials are not limited to autonomous access. Delegated authorization can also select a Vaulted Credential when the approved access permits it.
No authentication
Section titled “No authentication”When the upstream service requires no authentication, Axec sends requests without an upstream credential, but still checks whether the agent has permission to use the Connector and the selected operation.
Example: An agent reads a public data endpoint through a no-auth Connector. The upstream endpoint needs no secret, but Axec still enforces the agent’s access limits.
Credential ownership
Section titled “Credential ownership”A Connection holds one User’s upstream OAuth authorization or personal credential for one Connector. The Connector configuration is shared within the Workspace, while each Connection belongs to its User.
Example: Alex and Sam use the same calendar Connector with separate Connections. The endpoint and capabilities are shared, but their upstream accounts and tokens are separate.
A Vaulted Credential holds shared upstream credentials for a Connector. Axec encrypts stored credential material and exposes only safe metadata, not the secret value.
When an agent accesses a service through Axec, Axec applies the upstream credential to the request, so the agent does not need to receive or manage that credential.
Reconnecting a User creates a new Connection identity. Existing authorization does not silently inherit the replacement credential. See Connect an upstream provider for connection setup and replacement.
Continue
Section titled “Continue”- Connect an upstream provider for User-owned credential setup.
- Act on behalf of a User for delegated access.
- Autonomous Applications for shared automation.