Introducing Truto Agent Toolsets

Built the True Truto Way ®️, the Truto Agent Toolset feature let you use the existing Truto Proxy APIs as tools in your LLM Agent workflows. Like everything else in Truto, these tools are fully customizable and extensible - because we believe in giving you the freedom to build integrations your way, without any platform lock-in.

! Truto Agent Toolset Demo

Turning your Proxy API into a Truto tool is incredibly simple. Just add a description to your Integration's API method and specify any query parameters it accepts. That's it! Your Proxy API method will automatically be exposed through a new /tools endpoint for each integrated account.

All the new integrations built by Truto will be Agent First and support tool calling. We are rapidly increasing the coverage for the existing integrations and aim to have 100% tool calling coverage by end of this year.

As part of this feature, we have also released a brand new Langchain.js Toolset SDK which integrates with Langchain.js and seamlessly provides a set of tools ready to use for an integrated account. Check it out here.

Executive TL;DR: Truto Agent Toolsets vs Merge Agent Handler

If you're evaluating Truto vs Merge Agent Handler for AI tool calling, the trade-off comes down to control vs opinionation. Truto Agent Toolsets expose every integration's Proxy API method as a tool with a description and schema you fully own and can edit per environment or per account. Merge Agent Handler offers a fixed, vendor-managed action set across a category.

Recommendation checklist:

• Need per-customer tool descriptions that update without a redeploy? -> Truto
• Need integrations outside a vendor's supported catalog? -> Truto
• Want a standardized, opinionated schema across all connectors in a category? -> Merge
• Need direct access to the raw provider API alongside a unified layer? -> Truto
• Prefer configuration as versionable data (JSON in a repo) over a managed black box? -> Truto
• Happy to accept a vendor's tool taxonomy in exchange for less setup? -> Merge

Feature-by-feature comparison

Buyer scenarios: when to choose each

Choose Truto Agent Toolsets when:

• You need to tune tool descriptions per customer as you learn which prompts trigger the right tools.
• Your customers require integrations that aren't on any unified API vendor's roadmap - you can define the integration in config yourself.
• You want the agent to have both a normalized unified view and direct Proxy access for raw provider data.
• You care about portability and want config to live in your repo, not behind a vendor UI.
• You're running multi-tenant SaaS and want per-account overrides for tool behavior.

Choose Merge Agent Handler when:

• You're happy accepting a fixed, opinionated schema across every connector in a category.
• Your entire integration list is covered by the vendor's supported connectors and you don't foresee adding niche providers.
• You want the vendor to own the whole abstraction and you don't need direct provider API access.
• Per-customer customization of tool descriptions or schemas is not a requirement.

Migration checklist: moving from Merge Agent Handler to Truto

If you're migrating an existing agent from Merge Agent Handler (or any managed agent tooling layer) to Truto, plan the work in three tracks:

Auth and scope mapping

• Inventory every OAuth app, API key, and connected account currently in use.
• Recreate OAuth apps in Truto's integration config, or reuse existing client credentials at the environment level.
• Map scopes 1:1 - Truto uses the underlying provider's native scopes, so there's no proprietary scope translation to unlearn.
• Recreate any per-customer credential overrides at the integrated account level.
• Confirm token refresh behavior; Truto refreshes OAuth tokens ahead of expiry so your agent doesn't see auth failures mid-run.

Tool semantics mapping

• Enumerate every tool the agent currently calls and match it to a Truto integration + resource + method.
• For managed tools that wrap multiple provider calls behind a single action, decide whether to compose that in your agent code or model it as a custom resource in Truto.
• Port existing tool descriptions verbatim as a starting point, then iterate using Truto's real-time description updates.
• Move any input constraints (required fields, enums, formats) into the method's query schema so the LLM sees them at tool-selection time.
• Decide whether the agent needs Unified APIs, Proxy APIs, or both. For most agent workflows, Proxy APIs are sufficient since the model can normalize raw data itself.

Testing

• Diff tool responses between the old handler and Truto for a representative integrated account.
• Replay a sample of production agent traces against the new tools and compare tool-selection behavior end-to-end.
• Load-test against provider rate limits and confirm Truto's backoff behavior matches your SLA.
• Verify webhook and event coverage if your agent reacts to provider events.
• Run a shadow period where both handlers execute in parallel and log divergences before flipping traffic.

Lock-in considerations and best practices

Every agent handler creates some lock-in. The trick is keeping the migration cost low regardless of which platform you're on:

• Keep tool descriptions in your own repo. Treat them as prompt assets and push them to the platform via API. Descriptions are the highest-leverage piece of an agent stack and the most annoying to lose.
• Model auth at the provider level, not the abstraction level. Store provider OAuth app IDs, client secrets, and scope sets in your own config. Truto's integrated account model maps cleanly to this pattern.
• Prefer thin tools that map 1:1 to provider endpoints. Avoid tools that hide multiple provider calls behind a single opaque action - compose multi-step workflows in your agent, not in the tool layer. Thin tools port cleanly across platforms; composite tools do not.
• Version your resource and method definitions. Truto's integration config is JSON; check it into Git alongside your app so tool changes flow through code review.
• Prefer Proxy APIs for agent workflows. Unified APIs are great when you're building programmatic integrations; for agents, Proxy APIs give the model the full provider surface and reduce the risk of a unified schema silently hiding a field the agent needs.
• Test tool selection, not just tool execution. Migration bugs usually show up as the agent picking the wrong tool because the description shifted, not as a broken API call.

Why use it?

Our tools platform is designed with real-world usage in mind. A tool's effectiveness depends on how well the tool description matches your customers' queries. If you notice a tool isn't being called for certain types of questions, you can easily enhance its description to improve its usage. Best part? All tool description updates are reflected in real-time through the /tools endpoint - no need to redeploy your LLM!

Also, Truto already does the heavy lifting stuff related to integrations like auth management, pagination normalization, rate limit header normalization, etc. And you can also add your own integrations, resources and methods. A truly open platform.

Dive-in

We have written a detailed documentation around tool calling here. Excited to see what you build!

What's next?

MCP of course. We're developing fully customizable MCP servers that will leverage the same tool descriptions used by the /tools endpoint. These servers will include additional features like permission levels and more. Stay tuned for updates!