Beyond 1:1 API mapping: why DataTether's composite tools are the secret to token-efficient agents

When teams first connect an enterprise system or database to an AI assistant, the default instinct is simple: map every API endpoint to an individual MCP tool.

If your ERP or service has 40 endpoints, you expose 40 tools. If creating a sales order involves a header table, line items, pricing condition records, and partner assignments, you expose create_sales_order_header, create_sales_order_item, create_pricing_condition, and create_order_partner.

On paper, this feels clean and modular. The model has full granular access, and your tool registry mirrors your OpenAPI or OData catalog 1:1.

In production, it is an architectural dead end.

It leads to catastrophic token waste, slow multi-turn latency, and brittle agents that fail halfway through an operation. The solution is not to prompt-tune the agent or expose smaller tools—it is to bundle common, multi-entity operations into DataTether's composite tools.

Cloud infrastructure platforms learned this lesson early. Neon famously introduced createWithCompute—an ergonomic shortcut that folded project initialization, branch provisioning, and compute endpoint creation from three sequential API calls into a single call.

Enterprise systems like SAP and Microsoft Dynamics need this exact pattern. Here is why 1:1 API mapping fails for enterprise AI agents—and how DataTether's composite tools solve it from the data layer up.

---

The hidden token tax of 1:1 API mapping

The cost of 1:1 tool mapping shows up immediately on your inference invoice and your context window ceiling. There are three compounding failure points:

1. Catalog bloat in the system prompt

Every tool exposed to an LLM must have its JSON schema injected into the system prompt or tool catalog. A service with 30 entities and standard CRUD operations dumps 120 tool definitions into every single request.

Even with concise field descriptions, 120 schemas consume 6,000 to 15,000 tokens before the user has typed a single word. Because this overhead is re-sent on every conversational turn, your context budget is starved before the agent even begins reasoning.

2. Quadratic conversation accumulation

Business transactions are almost never single flat records. Creating a standard SAP sales order with two line items, pricing, and a ship-to partner requires a sequential cascade:

1. Call create_order_header $\rightarrow$ wait for response containing SalesOrder: 48618.
2. Parse response, call create_order_item for item 10 $\rightarrow$ wait for response.
3. Call create_pricing_condition for item 10 $\rightarrow$ wait for response.
4. Call create_order_item for item 20 $\rightarrow$ wait for response.
5. Call create_order_partner $\rightarrow$ wait for response.
6. Synthesize the final confirmation to the user.

In an LLM interaction, conversation history accumulates quadratically. Every turn re-transmits the previous turns:

Turn 1: [System + Tools + User Prompt]                                      ~10,000 tokens
Turn 2: [Turn 1] + [Header Call] + [Header Response (48618)]                ~12,000 tokens
Turn 3: [Turn 2] + [Item 10 Call] + [Item 10 Response]                      ~14,000 tokens
Turn 4: [Turn 3] + [Pricing Call] + [Pricing Response]                      ~16,000 tokens
Turn 5: [Turn 4] + [Item 20 Call] + [Item 20 Response]                      ~18,000 tokens
Turn 6: [Turn 5] + [Partner Call] + [Partner Response]                      ~20,000 tokens
──────────────────────────────────────────────────────────────────────────────────────────
Cumulative Tokens Billed:                                                   ~90,000 tokens

What should have been a single business action burns nearly 100,000 tokens and 30 to 45 seconds of latency across 5 to 7 roundtrips.

3. Intermediate verbose payloads

Enterprise APIs are notoriously chatty. An OData or REST response from an ERP rarely returns just the created ID. It returns __metadata, OData entity links, hundreds of default fields, audit timestamps, and system flags.

When an agent executes five intermediate calls, those verbose JSON bodies sit permanently inside the chat history, choking the context window with metadata the user will never see.

4. Turning agents into fragile distributed coordinators

When an agent strings together five API calls, it is forced to act as a stateful distributed orchestrator:

• It must parse the ERP-generated key (48618) from Step 1 and manually wire it into Steps 2, 3, 4, and 5.
• It must maintain strict dependency ordering.
• If Step 4 fails due to a validation error, Steps 1 through 3 have already committed. As we explored in the half-created order, you now have orphaned records polluting production, and the LLM has no built-in transaction rollback.

---

The industry precedent: Neon's createWithCompute

Modern developer platforms ran into this exact wall when building developer APIs.

Consider Neon's serverless Postgres platform. In their foundational API, spinning up a working database environment required three discrete calls:

1. POST /projects to create a project container.
2. POST /projects/{id}/branches to initialize the primary branch.
3. POST /projects/{id}/endpoints to launch compute resources for that branch.

For human developers writing scripts, three calls were manageable. For AI agents, it was a constant source of friction: three network hops, intermediate state handling, polling for compute readiness, and orphaned projects if compute provisioning failed.

Neon introduced createWithCompute: a single API operation that accepts the project configuration, creates the branch, spins up compute, and returns the ready connection URI in one roundtrip.

For agents, this ergonomic bundling changed everything:

• 1 tool call instead of 3.
• Zero intermediate state to parse or hallucinate.
• Atomic failure: if compute provisioning fails, the project does not linger as an orphan.
• Immediate token savings: turns and payload history collapse.

Enterprise data systems require the exact same pattern. But while a database vendor can hardcode a bespoke createWithCompute endpoint into their cloud API, an enterprise cannot write custom middleware for hundreds of SAP, Dynamics, or Salesforce transactions.

It requires an action layer that models and generates DataTether's composite tools dynamically from enterprise metadata.

---

How DataTether's composite tools solve the problem in depth

DataTether takes the bundling principle and turns it into a metadata-driven engine for enterprise APIs and OData services.

Instead of exposing dozens of fragmented CRUD endpoints, DataTether's composite tools model an entire document hierarchy (header, items, pricing, partners) as a single, governed MCP tool.

DataTether's composite document tree: primary entity with attached child sources alongside the unified tool schema

Here is how the architecture eliminates token waste and solves the orchestration dilemma:

1. Document tree hierarchy modeled naturally as one tool

Enterprise data is structured as documents, not flat tables. In DataTether, you select a primary entity (such as A_SalesOrder) and attach related child sources (A_SalesOrderItem, A_SalesOrderItemPrElement, A_SalesOrderHeaderPartner).

The platform reads your OData $metadata document, derives navigation paths, evaluates foreign key relationships, and models the full hierarchy:

A_SalesOrder (Root Header)
  ├── A_SalesOrderItem (Items)
  │     └── A_SalesOrderItemPrElement (Nested Pricing Conditions)
  └── A_SalesOrderHeaderPartner (Header Partners)

2. Unified JSON schema with strict token pruning

Instead of registering separate tools for every child table, DataTether's composite tools generate one unified tool (e.g., create_SalesOrderFull).

To prevent prompt bloat, the platform applies strict token pruning:

• Field Whitelisting: Only exposed, operator-selected fields appear in the schema. Unused internal flags, administrative timestamps, and read-only system properties are stripped out.
• Parent Key Omission: Child inputs omit foreign keys entirely. Line items do not accept a SalesOrder field, and pricing conditions do not accept a SalesOrderItem field. The schema strictly contains the business attributes the agent must specify.

The resulting JSON schema mirrors how a business user naturally structures an order:

{
  "header": {
    "SalesOrderType": "OR",
    "SoldToParty": "17100001"
  },
  "items": [
    {
      "Material": "MZ-FG-C980",
      "RequestedQuantity": "10",
      "pricing": [
        { "ConditionType": "PR00", "ConditionRateValue": "450.00" }
      ]
    }
  ],
  "partners": [
    { "PartnerFunction": "WE", "Customer": "17100002" }
  ]
}

3. Automated server-side key propagation

Notice what is absent from the payload above: the agent never passes order numbers or item numbers to child records.

In a naive 1:1 setup, the agent must wait for the header call to return SalesOrder: "48618", then manually copy "48618" into every child item and condition payload. If the model mistypes or hallucinates an ID, child rows attach to the wrong document or fail outright.

With DataTether's composite tools:

• The agent provides only the nested business data.
• The platform creates the header, captures the ERP-generated key from the response, and propagates it down the tree into child line items, pricing, and partner rows on the server side.
• Key mismatches become impossible because the agent never handles internal keys.

4. Collapsing 5–7 roundtrips into 1 single call

Because the complete document is submitted in a single call, the multi-turn conversational cascade collapses:

Turn 1: [System + Composite Tool + User Prompt]                               ~6,000 tokens
        [Single Composite Tool Call with Nested Document]
        [ERP Success Response with Created Keys]                              ~2,500 tokens
Turn 2: [Agent Confirms Order 48618 Created with 2 Items]                     ~8,800 tokens
──────────────────────────────────────────────────────────────────────────────────────────
Total Tokens Billed:                                                         ~17,300 tokens

This is an 80%+ reduction in tokens consumed compared to the 90,000-token cascade of 1:1 tool calling. Latency drops from 30+ seconds across five sequential turns down to a single network hop of under 2 seconds.

5. Transactional atomicity via deep inserts and $batch

The greatest danger of stringing together individual API calls is partial failure. If the second line item fails validation (e.g., missing sales org extension or credit limit exceeded), an agent with 1:1 tools leaves a half-created order in your system.

DataTether's composite tools execute writes with atomic guarantees:

• Atomic Deep Inserts: For document creation, the platform compiles the nested document into a single OData deep-insert HTTP request. The ERP processes the entire tree as a single database transaction. If any condition or line item fails, the entire document rolls back. Nothing is left behind.
• $batch Changesets: For multi-entity updates and deletes, operations are packaged into an atomic OData $batch changeset.
• Row-Level Error Attribution: Deep inserts return a single error document from the ERP, which is often cryptic. The platform inspects navigation targets (such as to_Item(1)/Material) to attribute the exact ERP validation error back to the specific row that caused it. The agent receives a precise, actionable error: "Item 2 (Material MZ-FG-C980): Material not extended to sales organization" rather than a generic 400 failure.

6. Correlated multi-entity reads (solving the N+1 problem)

DataTether's composite tools apply equally to data retrieval.

In a 1:1 model, if an assistant needs to inspect recent high-value orders and their line items, it must call filter_orders, receive 10 order IDs, and execute 10 sequential calls to get_order_items. This classic N+1 query pattern burns tokens, exhausts rate limits, and takes half a minute to resolve.

DataTether's composite read tools (FILTER, GET, SEARCH) execute correlated queries:

1. Fetch primary header records based on the agent's filter criteria.
2. Extract the unique keys and fetch child entities in optimized, chunked batches.
3. Perform in-memory joins (inner, left, or required).
4. Apply field projection—stripping unrequested columns before the payload reaches the LLM.

The agent asks one question and gets back one shaped, complete document response.

7. Enterprise governance: reviewing the document diff in one click

Technical atomicity prevents corrupt data, but governance ensures business accountability.

In a 1:1 tool model, human approval is unworkable. If an agent creates an order across five tool calls, an approver receives five separate notifications in sequence: approve header, approve item 10, approve pricing, approve item 20, approve partner. No business stakeholder will tolerate five interruptions for one transaction, and approving a header without seeing its line items defeats the entire purpose of governance.

Under our reads flow, writes wait architecture, DataTether's composite tools solve this cleanly:

• The entire nested document is held at an approval gate before anything reaches the ERP.
• The designated approver sees a single unified document diff displaying the header, all proposed line items, pricing conditions, and partner assignments in context.
• The approver reviews the business action in ten seconds and approves or rejects it with one click.
• Every action is recorded in a tamper-evident audit trail with identity, payload, approver, decision, and ERP execution outcome.

---

Token efficiency is architectural, not accidental

There is a tendency in the AI ecosystem to treat token optimization as prompt engineering—shortening instructions, trimming descriptions, or switching to smaller models.

Prompt tuning helps at the margins, but it cannot compensate for a flawed interface design. If your tool layer forces an agent to coordinate five sequential network roundtrips to assemble a business transaction, you are paying a heavy tax in tokens, latency, and operational fragility.

Bundling multi-entity workflows into DataTether's composite tools:

1. Preserves context window headroom by replacing dozens of fragmented schemas with a single pruned document model.
2. Eliminates multi-turn conversation bloat by collapsing 5–7 turns into a single roundtrip.
3. Guarantees enterprise data integrity through atomic deep inserts and automated server-side key propagation.
4. Enables realistic governance by presenting a complete document diff to a human approver in one click.

Just as Neon's createWithCompute proved that ergonomic bundling makes infrastructure agents reliable, DataTether's composite tools are the architectural unlock that makes AI agents viable across enterprise ERPs.

---

Read more about preventing orphaned data in The Half-Created Order, or explore our security architecture in Reads Flow, Writes Wait. To test DataTether's composite tools against your own SAP or OData services, request guided access.