Truto vs Merge Agent Handler: Auto-Generated MCP Tools vs Pre-Built Tool Packs

If you are evaluating platforms to connect your AI agents to enterprise SaaS platforms, you are facing a strict architectural fork in the road. The difference boils down to one critical question: do you want your Model Context Protocol (MCP) tools hand-curated and pre-built, or dynamically generated from API documentation with zero hardcoded integration logic?

The choice between these two approaches dictates how fast you can scale your integration catalog, how your agents handle custom fields, whether your system can survive the brutal realities of third-party rate limits, and how quickly your engineering team ships new integrations.

This guide is a direct comparison of two fundamentally different approaches to giving AI agents structured, executable access to third-party enterprise APIs through the Model Context Protocol. We will break down the architectural differences between Merge Agent Handler and Truto, examining how Merge utilizes curated tool packs and a security gateway, comparing it against Truto's zero integration-specific code architecture, and explaining why how you handle HTTP 429 rate limit errors will make or break your agentic workflows in production.

The 2026 AI Agent Bottleneck: Why Custom Connectors Fail

The shift toward agentic workflows is accelerating faster than traditional SaaS integration methods can support. Forty percent of enterprise applications will be integrated with task-specific AI agents by 2026, up from less than 5% in 2025, according to Gartner. Furthermore, they project that by 2029, 70% of enterprises will deploy agentic AI to operate their IT infrastructure.

To facilitate this, the Model Context Protocol has become the de facto standard. MCP has recorded approximately 97 million monthly SDK downloads as of March 2026, and by early 2026, 28% of Fortune 500 companies have already implemented MCP servers in production workflows.

Those numbers mean your product will need to talk to your customers' Salesforce, Workday, Jira, and NetSuite instances through AI agents, not just REST calls from a backend service. But connecting a Large Language Model (LLM) to a third-party API is fundamentally different from a standard backend integration. Before MCP, developers faced an N×M scaling problem. If you have ten different AI models that need to interact with fifty different SaaS platforms, building point-to-point integrations requires 500 custom connectors. You have to hand-code JSON schemas for every single tool, map the query parameters, and explicitly define the required fields so the LLM knows how to call the endpoint.

Hand-coding these tool definitions is an unscalable architecture. Vendor API documentation is notoriously unreliable. Endpoints change, required fields are modified, and maintaining static JSON schemas across dozens of integrations quickly consumes your entire engineering team.

Here is the part that rarely makes the pitch deck: over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value, or inadequate risk controls, according to Gartner. The integration layer is where a huge chunk of those costs accumulate. Every hand-coded JSON Schema tool definition is a maintenance liability. Every undocumented API field change breaks an agent workflow silently. You need a managed infrastructure layer, but the platform you pick to manage these connections determines whether your team spends time improving agent reasoning or patching broken schemas.

That brings us to the two leading architectural approaches in this space.

Merge Agent Handler: Pre-Built Tool Packs and a Security Gateway

Merge approached the AI agent integration problem by launching the Merge Agent Handler in October 2025. It is a separate product from Merge's traditional unified API, designed to securely connect AI agents to third-party tools via MCP.

Their architecture is built around two core concepts: pre-built "Tool Packs" and a centralized security gateway. Instead of exposing the raw underlying API, Merge provides curated Tool Packs—bundles of predefined actions that map to specific use cases (like "Create a CRM Contact" or "List ATS Candidates"). When you call the platform to list tools, the tools defined in your selected Tool Pack are returned.

The architecture works like this:

sequenceDiagram
    participant Agent as AI Agent
    participant AH as Merge Agent Handler
    participant GW as Security Gateway / DLP
    participant API as Third-Party API
    Agent->>AH: tools/call (MCP)
    AH->>GW: Scan tool inputs
    GW->>API: Execute API request
    API-->>GW: Response
    GW-->>AH: Scan response for sensitive data
    AH-->>Agent: MCP result

What Merge does well:

• Security gateway with DLP: With Tool Packs, you can create a dedicated "Sales Call Prep" pack that just includes the connectors you need and only enables a small set of read-only tools. Tool inputs and outputs pass through a security gateway that can block, redact, or mask sensitive data.
• Evaluation suite: Merge Agent Handler's Evaluations Suite lets you identify vulnerabilities before pushing your agentic integrations to production by giving you a structured, repeatable way to test the full tool calls. You can define realistic test scenarios that mirror how users will actually prompt the agent.
• Connector Studio: You can add a new connector by pasting in the API documentation URL or the GitHub URL. Merge will then use AI to auto-generate the connector on your behalf, and their team will review it afterwards to make sure it is production-ready.
• Observability: Every tool call is logged, including underlying API requests, enabling debugging, monitoring, and compliance reviews.

Where the pre-built approach hits walls: This approach offers strict control, but it introduces a severe bottleneck: you are entirely dependent on Merge's engineering team to maintain the Tool Packs.

• Connector coverage ceiling: As of writing, Merge Agent Handler supports around 110 connectors. If the integration you need is not covered, you must fall back to public MCP servers or wait for a custom build.
• Custom tool call rigidity: You cannot build custom tool calls on the platform. If the pre-built tools do not cover your niche endpoint in Jira, there is no way to extend the platform with your own logic.
• Custom fields pain: Pre-built tool calls may not handle custom fields in platforms like Salesforce, where enterprise customers heavily customize their data models. If a tool pack is hardcoded to expect first_name, last_name, and email, it will fail when the customer's CRM requires a custom industry_segment_id.
• Context window bloat: Multiple generic tool calls increase the context size for your AI Agent and can cause hallucinations.
• Opaque Middleware: The security gateway acts as an opaque middleware layer. If an API call fails due to a bizarre edge case in the vendor's system, the middleware often obscures the raw error, making it incredibly difficult for the LLM to autonomously debug and retry the request.

The fundamental tension is that pre-built tool packs are curated for quality but structurally lag behind what the underlying APIs actually support. Every new endpoint, every custom field, every vendor API update requires someone at Merge to explicitly write, test, and deploy an update to their connector definition.

Truto: Auto-Generated MCP Tools via Zero Integration-Specific Code

Truto takes a radically different approach. Instead of maintaining hardcoded Tool Packs for each provider, Truto dynamically generates MCP tools directly from API documentation and JSON schemas.

The entire Truto platform—across 100+ integrations—operates on a zero integration-specific code architecture. There are no if (provider === 'hubspot') statements anywhere in the codebase. The same generic execution pipeline handles every provider. Integration behavior is defined entirely as data, not a code deployment.

How tool generation works in Truto: When an AI client connects to a managed MCP server URL in Truto, it does not load a static list of tools. Instead, it dynamically assembles them based on two existing data sources: an integration's resource configuration and its documentation records.

1. Resource Iteration: Truto iterates over every resource and method defined for that specific integration (e.g., contacts.list, tickets.create).
2. Documentation Gating: It checks for a documentation record containing the human-readable description and JSON schemas for the query and body parameters. If no documentation exists, the tool is silently skipped. This acts as an automated quality gate.
3. Dynamic Assembly: For each valid pair, Truto automatically generates a descriptive snake_case name (e.g., list_all_hub_spot_contacts), injects pagination instructions (like next_cursor or limit) directly into the schema descriptions, adds id fields for individual-resource methods, and serves the tool via a JSON-RPC 2.0 endpoint.

graph TD
  subgraph Merge Agent Handler
    A[AI Agent] --> B[Merge Security Gateway]
    B --> C[Pre-Built Tool Pack]
    C --> D[Unified Model Mapping]
    D --> E[SaaS API]
  end
  subgraph Truto MCP Server
    F[AI Agent] --> G[Truto JSON-RPC Endpoint]
    G --> H[Dynamic Tool Gen via Docs]<br>Zero Custom Code
    H --> I[Pass-Through Proxy API]
    I --> J[SaaS API]
  end

Because tools are generated dynamically from documentation data, adding a new endpoint or even a completely new integration is a data-only operation. There is no waiting for a vendor to update a Tool Pack. If the endpoint is documented in Truto, it is immediately available as a highly capable MCP tool for your agent.

The Flat Input Namespace Resolution

When an LLM calls a tool, it typically passes all arguments as a single, flat JSON object. Truto handles this elegantly. The MCP router intercepts the tools/call request and splits the flat arguments into query parameters and body parameters by mapping them against the generated JSON schemas. The agent does not need to know the difference between a URL query string and a POST body—Truto handles the routing automatically while executing the request through its pass-through Proxy API.

Context Window Optimization via Tag-Based Filtering

One of the practical problems with MCP is that LLMs degrade in quality when they have too many tools in context. If you connect an agent to a massive platform like Salesforce or ServiceNow, generating tools for every single endpoint might result in 300+ tools. Injecting 300 JSON schemas into an LLM's system prompt will obliterate your context window and severely degrade the model's reasoning capabilities.

Pre-built tool packs solve this by simply limiting what you can do. Truto solves this through dynamic Tag-Based Filtering at the MCP server level.

In Truto, integration resources are assigned tags via config.tool_tags by functional area. For example, a Zendesk integration might tag tickets and ticket_comments with ["support"], while tagging users with ["directory"].

When you create an MCP server in Truto, you can pass a configuration filter:

{
  "name": "Support-only MCP",
  "config": { 
    "tags": ["support"], 
    "methods": ["read", "write"] 
  }
}

Truto applies this filter at the documentation-fetching stage. The resulting MCP server URL will only expose tools that match the support tag. Your support-triage agent never sees CRM or directory tools, keeping the context window tight and reducing hallucination risk. You can combine tags and method filters to spin up highly scoped, context-efficient MCP servers tailored to specific agent personas, without writing any custom filtering logic.

The Rate Limit Reality: Middleware Absorption vs. Standardized Headers

One of the most painful realities of software engineering is dealing with vendor API rate limits. Providers enforce limits inconsistently. Some use rolling windows, some use fixed hourly quotas, and almost all of them return wildly different HTTP headers when you hit the ceiling. When your AI agent hammers a Salesforce or HubSpot API, it will eventually get a 429 response. What happens next depends entirely on your platform's design.

Merge's approach: Merge Agent Handler sits as middleware between your agent and the third-party API. The security gateway processes requests and responses, but the specifics of how rate limit errors are handled—whether they are retried, queued, or passed through—are often abstracted. Many middleware platforms attempt to "help" by absorbing HTTP 429 (Too Many Requests) errors and applying silent, exponential backoff on your behalf. For traditional backend syncing, this is sometimes acceptable. For AI agents, it is catastrophic. If an LLM is waiting on a tool call, and the middleware silently retries a request for 45 seconds because of a rate limit, the LLM session will often time out. The agent loses its context, the workflow fails, and the user is left staring at a spinning loading indicator.

Truto's approach: Truto is brutally honest with your agents. Truto does not retry, throttle, or apply exponential backoff when an upstream API returns a rate limit error. This is a deliberate design choice, not a gap.

When a provider returns an HTTP 429, Truto passes that exact error directly back to the calling agent. However, Truto normalizes the chaotic upstream rate limit data (whether it is Salesforce's Sforce-Limit-Info headers or HubSpot's X-HubSpot-RateLimit-*) into standardized response headers based on the IETF RateLimit specification:

These headers appear on every response, not just 429s.

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "isError": true,
    "content": [{
      "type": "text",
      "text": "HTTP 429 Too Many Requests. Headers: ratelimit-limit: 100, ratelimit-remaining: 0, ratelimit-reset: 60"
    }]
  }
}

By passing the error and the standardized headers back to the LLM, the agent is empowered to make its own decisions. The agent can read ratelimit-reset: 60 and autonomously decide to switch to a different task, notify the user of a delay, or pause its own execution. You retain full control over the retry logic, and you never suffer from silent middleware timeouts.

For a deeper dive into rate limit handling patterns in agentic architectures, see our guide to handling third-party rate limits when AI agents scrape data.

Handling Custom Fields and Undocumented Endpoints

Enterprise SaaS instances are heavily customized. Your enterprise customers do not use vanilla Salesforce—they have dozens of custom objects, required custom fields, and unique validation rules. The standard Account object might have 20 default fields and 150 custom fields unique to that customer.

Platforms that rely on strict unified data models and pre-built tool packs struggle here. A pre-built tool pack that only exposes standard fields is functionally useless for any serious enterprise deployment. Merge Agent Handler does offer a Connector Studio where you can modify tool descriptions and schemas. But this is a manual curation step per connector, per customer, per custom field. At enterprise scale—50 customers, each with unique Salesforce configurations—that becomes a full-time job.

Because Truto's auto-generated MCP tools execute through a pass-through Proxy API, they operate directly on the integration's native resources and schemas. There is no rigid unified model sitting between your agent and the SaaS platform during tool execution. If a Salesforce instance has a custom field Contract_Renewal_Date__c, the agent can query and write to it through the same tool call because the proxy passes it straight through.

Truto handles per-customer variations through environment-level documentation overrides. Each customer environment can have its own documentation records that override the integration-level defaults. If a customer modifies their environment-level documentation in Truto to include a custom field in the body schema, that field immediately appears in the MCP tool description. The LLM sees the requirement, understands the schema, and successfully executes the request with the custom data payload. The customization is a data operation, not a code change. You get the normalization of authentication and pagination, without sacrificing the depth of the native API.

Architectural Comparison at a Glance

Strategic Wrap-Up: Which MCP Server Platform Wins for Your AI Agents?

Neither platform is universally better. The decision between Merge Agent Handler and Truto comes down to how much control you want over your agent's capabilities, how you handle custom schemas, and how you view the future of API integration.

Choose Merge Agent Handler if:

• Your primary concern is DLP and data governance—the security gateway that scans tool inputs/outputs for sensitive data is a genuine differentiator for regulated industries.
• You need a pre-production evaluation suite to systematically validate tool behavior before deployment.
• You are building with a small, fixed set of well-known connectors (Salesforce, Slack, Linear) and do not need deep custom field support.
• You want a highly curated, limited set of actions and prefer a middleware layer to scan and abstract away the underlying API complexities.

Choose Truto if:

• You need maximum API surface area without waiting for someone to manually build and maintain tool definitions for each endpoint.
• Your customers have heavily customized SaaS instances (custom Salesforce objects, custom HubSpot properties) that pre-built tools cannot accommodate natively.
• You want transparent rate limit data flowing back to your agent so it can make informed retry decisions instead of having a middleware layer silently absorb errors.
• You need to add new integrations as data-only operations without code deployments.
• You are building a multi-tenant product where each customer's MCP tools need per-environment customization.

The honest trade-off: Truto gives you more flexibility and API coverage at the cost of building your own retry/backoff logic and DLP layer. Merge gives you more out-of-the-box security controls at the cost of connector coverage ceilings and reduced flexibility with custom fields.

For teams building autonomous agents that need to act across enterprise SaaS at scale, the ability to dynamically generate tools from documentation and pass custom fields through natively is worth more than a curated catalog of 110 connectors. By treating integrations as data and dynamically generating MCP tools from documentation, Truto removes the engineering bottleneck entirely.

Your agents get the exact schemas they need, the standardized rate limit headers required for reliable execution, and the full power of the native API—without writing a single line of integration-specific code.