Best custom tool-call providers for agent API integrations

TL;DR

• Nango: The best custom tool-call provider for agent API integrations. Start with prebuilt tools, customize them with coding agents and native API access, and run them with managed customer authentication. It supports managed execution, backend-hosted handlers, and enterprise deployment options.
• Arcade: A fit for teams building Python MCP tools that want managed hosting and per-user authorization through its MCPApp framework.
• Pipedream Connect: A fit for teams that want private Node.js actions discovered and executed alongside catalog tools through an API or MCP. Publishing custom tools requires the Business plan.
• Paragon ActionKit: A fit for teams keeping custom handlers and schemas in their application while using managed API authentication.
• Composio: A fit for SDK-based agents combining catalog tools with application-local functions. Your team hosts the functions; the custom-tools extension is experimental.

Building API integrations for agents often means adapting provider operations to your product’s workflows. You may need customer-specific filters, custom fields, or several API requests behind one tool call. These requirements make control over tool behavior an important part of choosing an integration provider.

For example, a support agent may call a list_urgent_tickets tool to find tickets that need attention. The tool must restrict the search to the customer’s approved project and return up to five tickets with their titles, priorities, and links. To produce that result reliably, it also needs authenticated API access, pagination, and error handling.

Custom tool-call providers differ in how much of this work they handle. Some host your custom code and manage its execution. Others provide authentication and API access while your application runs the handler. This guide compares five providers on that division of responsibility and the control they give you over your tools.

How to evaluate custom tool-call providers

To compare these approaches, follow an operation your agent needs from development through execution. For the ticket-search tool above, that means checking how you implement customer-specific filters, deploy the code, and investigate a failed request. Use these criteria to assess the full workflow:

• Coverage beyond the catalog: Can you change an existing tool and add missing endpoints or APIs? Verify the required operations, including whether a custom field can be created, read, and updated, rather than relying on a provider’s logo in the catalog.
• Control over custom behavior: Look for editable schemas, provider requests, filters, and outputs. Confirm that your code can use the native API when a packaged action is insufficient.
• Tool discovery and schema quality: Check how agents find relevant custom tools and retrieve their current input schemas. Test whether tool names, descriptions, and outputs help the agent select and use the intended operation.
• Execution and scale: Establish who hosts custom code and handles retries, rate limits, and logs. Test the expected workload across several customer connections.
• Customer isolation: Your backend should select the connection for the authenticated customer. Check how the provider restricts each execution to that connection and its allowed operations. Hiding a tool from discovery must not be your only access control.
• Development workflow: Check how engineers and coding agents test changes with development connections and deploy reviewed code.
• Enterprise deployment: Determine whether BYOC or self-hosting covers the custom execution runtime, credentials, and logs. Clarify who operates each component.

Best providers for custom agent tool calls

Nango combines a workflow for building custom tools with managed execution and native API access. Arcade and Pipedream also host custom tools, using their respective server and component frameworks. Paragon ActionKit and Composio’s SDK leave custom handlers in your application, so evaluating them also means accounting for the runtime your team operates.

1. Nango

Overview

Nango is the best custom tool-call provider for agent API integrations. It provides 7,000+ prebuilt tools for 1,000+ APIs, with managed authentication and a runtime for custom tools. You can start with an existing action, customize its behavior, or build a new tool for an operation outside the catalog.

To make those changes, use Nango’s integration builder skill with Claude Code, Cursor, or Codex. The coding agent can customize the tool, test it against a real development connection, and deploy it. The source stays in your repository, so your team can review changes and release them through CI/CD.

Once deployed, the tool runs on Nango’s infrastructure with token refresh, configurable retries and rate-limit handling, and execution logs. Set the retry policy in your custom code. Each execution uses a specific customer connection, keeping provider credentials out of the agent. Your application invokes the tool through an API or SDK from any backend language. If your agent uses MCP, agent sessions let your backend choose the connections and tools it can access.

Best for

Teams shipping custom API tools across agents and products that need control over tool behavior, customer authentication, and deployment. Nango supports both adapting prebuilt actions and building new operations, with coding-agent development and infrastructure for running them at scale.

Pros

• Start quickly and extend beyond the catalog: The quickstart takes you through authorizing a connection and calling a prebuilt tool. Then customize and test the operations your product needs. Custom tools run on Nango’s infrastructure built for scale and security.
• Control over custom behavior: Customize action inputs, outputs, and logic, including per-customer filters. Drop down to native API requests through the authenticated proxy for endpoints or fields a packaged tool does not expose.
• Choice of where custom logic runs: Deploy tools to Nango’s runtime, or keep handlers in your own backend and use its authenticated proxy for API requests. Both approaches can use the same customer connections, so existing handlers can work alongside Nango actions.
• Auth, tool calls, triggers, and syncs together: A ticket-change trigger can start an agent workflow that invokes your custom tool. A sync can keep a local copy of ticket data ready for searches, reducing API requests during tool execution.
• Logs for debugging custom tools: Function and request logs help trace a failed tool call to the underlying API request. Inspect the customer connection, error, and execution duration when investigating a failure.
• Deployment control on Enterprise: Deploy Nango in your cloud with Nango-managed BYOC or a self-managed instance. Both require Enterprise, so include that plan requirement when evaluating data residency needs. BYOC lets Nango operate the instance; self-managed deployment leaves operations with your team.

Cons

• Customer-specific behavior still needs engineering review and maintenance. Nango’s builder skill helps implement and test that logic against development connections; your team owns the access rules and expected results.

2. Arcade

Overview

Arcade provides a Python framework for custom MCP servers. Each tool you define through MCPApp specifies its inputs and authentication requirements, which Arcade uses when executing the tool for a user.

Best for

Teams building Python MCP tools that want per-user authorization and managed server hosting through one framework.

Pros

• Python tool definitions support custom behavior and per-user authorization.
• Arcade Deploy hosts compatible MCP servers and registers their tools in the catalog. Gateways let you select which tools to expose to MCP clients.

Cons

• The documented arcade deploy path expects a Python MCPApp entrypoint. Check compatibility with your integration codebase before choosing it as your tool execution runtime.

3. Pipedream Connect

Overview

Pipedream Connect lets you publish private Node.js actions through its Components API. You package custom logic in Pipedream’s component format, then invoke the published action for a specific external user. That user’s connected account supplies the credentials for execution.

Best for

Teams that want custom Node.js actions to appear alongside catalog actions in the same discovery and execution interfaces, including hosted MCP.

Pros

• Published custom actions appear in Connect’s list, retrieve, and run APIs and are automatically exposed through its hosted MCP server for the relevant app.
• Public component source provides implementation examples.

Cons

• Publishing custom tools through Connect requires Business, so confirm plan access before evaluating a custom action in Connect.
• Custom tools are Node.js components built with the Pipedream Components API. Existing handlers need to fit that format before publication.

4. Paragon ActionKit

Overview

Paragon ActionKit supports custom tools through schemas defined in your application and its authenticated Proxy. Your handler uses the Proxy to make authenticated API requests, then shapes the response for the agent. Because your application defines these tools, it also supplies their schemas to the agent.

Best for

Teams that want authenticated API access while keeping custom tool execution and schemas in their own application.

Pros

• The authenticated Proxy lets custom handlers use existing Paragon connections.
• A handler can combine provider requests into one operation.

Cons

• The documented ActionKit custom-tool path leaves orchestration and response shaping in your application.
• ActionKit’s List Tools endpoint excludes these custom tools. Your application must maintain and supply their schemas separately.

5. Composio

Overview

Composio’s custom-tools SDK feature adds application functions to a session’s tool set, with execution in your application process. For custom tools accessed through its MCP gateway, a separate feature connects a server that you host.

Best for

Teams combining catalog tools with application-local functions and accepting responsibility for hosting those functions.

Pros

• SDK agents can use catalog tools alongside functions that query your application’s database or internal services, within the same session.
• Custom handlers can extend toolkit behavior through authenticated proxy calls.

Cons

• Composio’s hosted MCP endpoint cannot execute local callbacks. Using its external MCP path requires you to host a server and resynchronize tool definitions after changes.
• Both custom-tool extension paths are documented as experimental.

How to choose and validate a provider

Choose Nango for custom tool calls that need editable behavior, customer-scoped authentication, and a managed runtime. Its prebuilt catalog and coding-agent support help you build the tool, while native API access lets you extend it as requirements change. If part of the logic needs to stay in your backend, use Nango’s authenticated proxy with the same customer connections. BYOC and self-hosting extend that deployment control to the integration infrastructure.

An alternative may fit a narrower requirement. Arcade suits Python MCP tools that need managed server hosting and per-user authorization. Pipedream puts private actions into the same discovery and execution interfaces as its catalog tools. ActionKit supplies authenticated API access for application-owned handlers, while Composio combines local functions and catalog tools in an SDK session. With ActionKit or Composio’s SDK, plan to operate the custom handlers in your own backend.

Validate your choice by implementing one tool that exercises your actual constraints. For the ticket-search example, verify that another customer’s project ID cannot expand access, pagination stays within the request budget, and the response contains only the intended fields.

A successful connection does not establish that every operation will work. Test the required reads and writes with realistic customer roles, OAuth scopes, and field mappings. Repeat after revoking a permission or reconnecting the account. Nango’s connection validation functions can check required permissions during connection creation and reconnect; operation-level tests still matter.

Test authorization through each execution path. Backend proxy handlers must enforce permitted methods and endpoints in trusted code. Nango’s generic session proxy is disabled by default; enabling it permits endpoints beyond the tool allowlist. Keep it disabled for agents that should only call your selected tools.

Choose the data access pattern for the operation. Live reads suit a current ticket status or a record check before a write. Repeated searches across many records may benefit from synced data to reduce request volume and latency, but require an acceptable freshness window and a way to handle revoked access.

After checking the tool’s output and access restrictions, test how it recovers from API failures. Errors should distinguish a disconnected account, insufficient permission, a missing record, and a transient failure, with a clear next step for the agent or user. Confirm that the agent requests reconnection or permission, or stops, when retrying cannot help.

Simulate a provider 429 response and confirm you can see the failed request and retry outcome. For a write tool, also test a timeout after the provider has accepted the change. Since retrying could repeat that change, establish how your application checks the outcome or uses an idempotency key.

Frequently asked questions

When should you customize a prebuilt tool?

Customize a tool when its inputs, outputs, or behavior do not match your product’s requirements. You might need to enforce a customer’s project restrictions, include custom fields, or return fewer fields to the agent. With Nango, you can adapt an existing action and use native API requests for operations outside the catalog.

Do custom tool calls require MCP?

No. You can define a tool in your agent framework and have its handler invoke a Nango action through the API or SDK. If your agent uses MCP, Nango’s agent sessions expose selected actions through that protocol. Choose the interface that fits your application’s execution and access-control requirements.

Can a custom tool call several APIs?

Yes, if the execution environment supports access to each required connection. Nango’s action functions support workflows with multiple API requests. When those requests span providers, authorize each connection separately. Writes across APIs are not transactional, so the tool also needs to handle cases where only some requests succeed.

Should the agent handle pagination itself?

Keep predictable pagination inside the custom tool. With Nango, you can customize an action to fetch up to a specified number of records and return only the fields the agent needs. Include a continuation indicator if more results are available, so the agent can explicitly request them.

Can the same custom tool serve multiple customers?

Yes. With Nango, you can reuse an action across customer connections and store customer-specific settings in per-connection metadata. Your backend selects the authorized connection, and the action applies its project filters or field mappings. Keep those access restrictions in a trusted configuration so agent-supplied inputs cannot override them.

Build your first custom tool with Nango

To try this workflow with Nango, start with a prebuilt tool for an operation your agent needs. Use your coding agent to adapt its behavior and test it against a development connection. Once it returns the expected results and handles failures correctly, deploy it to Nango’s runtime and invoke it from your agent or product. The Nango quickstart walks you through getting started.

Related posts

• Build reliable tool calls for AI agents integrating with external APIs
• Best MCP servers for agent API integrations
• Best practices for building API integrations with AI agents