Execute tools and API requests

Use Axec when an agent needs to retrieve information or update data in a connected service without handling that service’s credentials. The agent sends its request to Axec, which checks access, authenticates to the service, and returns the result.

You can call a single Connector, combine tools from several Connectors through a Gateway Application, or use the HTTP proxy when your Application needs to invoke an API operation without an MCP client.

Before you start

An administrator must configure the required Connectors and give your Application access to the intended operations, either directly or through a Gateway Application. Any required upstream credentials must also be available: a User-owned Connection for personal access, or an eligible shared credential for Workspace-managed automation.

Follow Connect an MCP client for interactive MCP access, Act on behalf of a User for a User workflow, or Run an autonomous Application for shared automation. Obtain an Axec access token for the Connector or Gateway you intend to use; access to one does not grant access to another.

Call MCP tools

An MCP client can use Axec to call tools from an upstream MCP server or operations from an HTTP API that Axec exposes as tools. The client uses the same discovery and tool-call workflow in either case, without needing to implement the upstream service’s authentication.

1. Connect your MCP client to the Axec URL for the Connector or Gateway and authenticate to Axec.
2. Request the available tools through the client’s tool discovery feature. Axec returns the tools permitted by your current access, along with their descriptions and input schemas.
3. Select a returned tool and supply arguments that match its input schema, using its returned name rather than constructing a name yourself.
4. Call the tool and handle its result. Axec checks access again before contacting the service, so a listed tool can still require approval or be denied when called.

Example: A support agent discovers a ticket-search tool, supplies a customer identifier, and receives matching tickets. Axec uses the selected ticketing credential for the upstream request without exposing it to the agent.

Combine tools through a Gateway

A Gateway Application gives an MCP client one Axec endpoint for tools from multiple Connectors, such as ticketing, customer records, and messaging. An administrator configures the Gateway’s Connector dependencies and operation limits, then gives the client Application access to the Gateway.

The client discovers and calls tools through that endpoint just as it would for a single Connector, while Axec routes each call to the appropriate service and selects that service’s credential. Only tools permitted by the caller’s current access appear in discovery, so two agents using the same Gateway can see different tool sets.

Example: A Support Gateway combines ticketing and messaging tools, allowing an agent to retrieve a ticket and then send a summary to a support channel. These remain two separate tool calls: aggregation combines the available tools, but does not automatically chain calls or execute a workflow for the agent.

See Applications for the distinction between a calling Application and a Gateway Application.

Access an HTTP API through the proxy

The HTTP proxy lets an Application invoke an approved HTTP API operation through Axec without using MCP or receiving an upstream credential. Use it when your integration needs an API request rather than a tool call, such as a backend job that reads inventory records from an internal service.

1. Configure an HTTP Connector with a supported OpenAPI contract and the service’s required authentication.
2. Obtain access that permits HTTP proxy requests for the intended operations. Permission to call MCP tools alone does not grant proxy access.
3. Submit the operation and its arguments through Axec’s proxy API, selecting the Connector when using a Gateway.
4. Handle the returned response or any required approval before continuing your workflow.

Axec constructs the upstream HTTP request from the configured operation, applies the service credential, and checks access before sending it. The proxy is not an unrestricted URL forwarder: your Application selects an approved operation rather than supplying an arbitrary destination or authentication header.

Example: A reporting job requests an inventory-read operation with a product identifier. Axec contacts the configured inventory API using its stored API key and returns the response, while an inventory-update operation remains unavailable unless separately allowed.

Handle access changes and approvals

Axec checks each request against current access and applicable policies, so a previously available operation can fail after access is revoked or a Connector is disabled. Treat a denied request as a change in available access rather than repeatedly retrying it, and follow any required approval before attempting the operation again.

See Security Architecture for the boundaries of policy enforcement, approval, Data Protection, and retained execution evidence.