Best MCP Server for Oracle NetSuite in 2026: Connect AI Agents to ERP Data

If you are an engineering leader evaluating platforms to connect your AI agents—whether Claude, ChatGPT, or a custom LLM—to your customers' Oracle NetSuite instances, the honest answer in 2026 splits across distinct architectural paths. The right choice depends entirely on your product's scope: are you building internal tools for your own finance team, or are you shipping a B2B SaaS product that requires multi-tenant, scalable ERP access embedded in your application?

The first case has a clear answer: start with NetSuite's own first-party AI Connector Service. The second case—multi-tenant, multi-customer ERP connectivity—is where the architectural decisions get interesting and the engineering pain gets real.

Writing custom API connectors for NetSuite is an engineering nightmare. You are looking for a managed platform to handle the punishing realities of NetSuite's fragmented API surfaces, brutal concurrency limits, and legacy authentication models.

The challenge intensifies when your product also needs to connect to SAP S/4HANA. SAP's enterprise software ecosystem, particularly S/4HANA and its cloud variants, presents both opportunities and complexities for AI integration - and as the world's leading ERP provider, it is one your customers are likely running. SAP brings a different but equally complex API surface - OData v2/v4 services, BAPIs, RFCs, and IDocs - along with its own authentication models and deployment variations across cloud, on-premise, and hybrid environments. This guide focuses primarily on NetSuite MCP servers but also covers where SAP fits in the broader ERP-to-AI connectivity landscape and why the architectural patterns are the same.

Similar to our broader evaluation of the best MCP server platforms for AI agents connecting to enterprise SaaS, this guide breaks down the best MCP (Model Context Protocol) servers available specifically for NetSuite, examines the architectural trade-offs of each approach, and explains how to safely expose complex ERP data to Large Language Models (LLMs) without pretending rate limits will magically go away.

The Shift to Agentic ERP: Why NetSuite Needs an MCP Server

The demand for AI agents that can read, write, and reason over financial data has accelerated dramatically. ERP systems are the last mile for AI agents that need to touch real business data—invoices, purchase orders, journal entries, and employee records.

According to Gartner, 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025. Furthermore, Gartner forecasts that 62% of cloud ERP spending will be allocated to AI-enabled solutions by 2027, up from just 14% in 2024. Within ERP systems specifically, more than 30% of companies will deploy AI agents to optimize business processes.

NetSuite sits at the center of this shift. With over 43,000 customers running financials, inventory, and HR on the platform, it is one of the most common ERPs that AI agents need to access.

Before the Model Context Protocol became the industry standard, exposing ERP data to an AI model meant building custom, point-to-point connectors for OpenAI, Anthropic, Google, and every custom LangChain wrapper your engineering team decided to test.

MCP collapses this integration burden. It standardizes the way AI systems integrate with external tools. Each AI application implements the client protocol once, and each data source implements the server protocol once. An MCP server acts as a lightweight JSON-RPC 2.0 service that translates the LLM's tool calls into standard API requests, returning the results in a format the model understands.

But building an MCP server is only easy if the underlying API is modern, well-documented, and consistent. Oracle NetSuite is none of those things.

The Final Boss of ERPs: NetSuite's API Ecosystem

If you have never built a NetSuite API integration from scratch, you might assume it behaves like a standard REST API. It does not. NetSuite relies on a highly fragmented, multi-protocol public interface backed by an internal scripting engine and a proprietary query language.

Architecting a reliable NetSuite integration requires orchestrating across multiple distinct surfaces, each with different capabilities and failure modes:

• SuiteTalk REST API: The modern interface, but notoriously incomplete. It handles record-level CRUD, but there is no batch endpoint for creates or updates. Every create or update is one record per request. This is the "chatty API" problem and the single biggest reason integrations hit concurrency limits.
• SuiteTalk SOAP API: The legacy XML interface. While painful to work with, it remains mandatory for specific operations, such as retrieving detailed sales tax item configurations.
• SuiteQL: NetSuite's SQL-like query language executed via the REST API. This is the only performant way to execute multi-table JOINs and complex filtering, making it the superior choice for read-heavy operations. However, it is not available for writes.
• SuiteScript (RESTlets): NetSuite's custom server-side JavaScript environment. You must deploy custom RESTlets inside the NetSuite instance to handle dynamic form field metadata, mandatory flag detection, and PDF generation (like Purchase Orders) because the standard APIs cannot do this natively.

Beyond the fragmented API surfaces, authentication is a massive hurdle. NetSuite uses OAuth 1.0 Token-Based Authentication (TBA). Unlike modern OAuth 2.0 where you simply pass a Bearer token in the header, NetSuite TBA requires generating an HMAC-SHA256 signature for every single HTTP request. This signature incorporates the HTTP method, the URL, the timestamp, a cryptographic nonce, and the token secrets. If a single character is out of place, the request fails with an opaque authentication error.

The Concurrency Slot Trap

This is not a theoretical complaint. NetSuite uses a concurrency slot model where all API types (SOAP, REST, RESTlets) share a single pool of concurrent request slots at the account level.

The default concurrency limit is just 15 requests per account. This increases by 10 for each SuiteCloud Plus license, with higher service tiers offering more capacity (Tier 5 allows 55 concurrent requests).

The shared pool is the number one trap. SOAP, REST, RESTlets, and SuiteScript web service calls all compete for the same slots. A runaway scheduled script making HTTP calls eats slots that block your REST integration. Building a custom MCP server means your engineering team must build an abstraction layer over all of these quirks before the AI agent can even make its first tool call.

Evaluating the Best MCP Servers for Oracle NetSuite in 2026

If you want to bypass the custom engineering effort, you have four primary options for hosting a NetSuite MCP server in 2026. Here is how the available options stack up, with honest trade-offs for each.

1. Oracle NetSuite AI Connector Service (First-Party)

NetSuite recently launched its own AI Connector Service, a protocol-driven integration service supporting MCP that gives customers a flexible and scalable way to connect their own AI to NetSuite. At SuiteConnect London in March 2026, Oracle announced expanded support for the NetSuite MCP Apps extension and Analytics Warehouse.

NetSuite provides the MCP Standard Tools SuiteApp, which handles record operations (create, read, update via REST), saved searches, and SuiteQL queries.

• Positioning: Focuses on governed, role-based AI access directly within the NetSuite ecosystem.
• Best for: Internal finance teams who want to use Claude or ChatGPT to query their own company's ledger (e.g., "show me overdue invoices over $10,000").
• The Catch: It is heavily optimized for internal use and not designed for third-party B2B SaaS companies. NetSuite requires the connection to be authorized using OAuth 2.0 Authorization Code Grant with PKCE, established using a non-Administrator role. This scopes the connection to a single NetSuite account. If you are building a product that needs to connect to hundreds of customers' instances, the AI Connector does not solve the multi-tenant orchestration problem.

2. CData Software (JDBC Wrapper)

CData offers an open-source MCP server wrapper around their well-known JDBC drivers, allowing you to connect to NetSuite data from Claude Desktop.

• Positioning: Translates LLM requests into SQL queries using their NetSuite JDBC driver.
• Best for: Data engineers running local analysis or internal BI teams who want to prototype NetSuite AI queries locally.
• The Catch: The open-source server is read-only and runs via stdio on the local machine—not a remote MCP endpoint you can share across a team. For full CRUD capabilities, CData pushes enterprise users toward their paid CData Connect AI platform. Additionally, exposing a direct SQL interface to an LLM can be risky without strict semantic boundary controls.

3. Zapier (No-Code MCP)

Zapier provides a no-code MCP server that connects AI assistants to Zapier's existing catalog of NetSuite actions, including creating records, updating fields, and executing SuiteQL queries.

• Positioning: Prioritizes extreme ease of setup over deep, native ERP data modeling.
• Best for: Non-technical operators who need simple trigger-action workflows connected to a single NetSuite instance.
• The Catch: Cost and data modeling. One MCP tool call uses 2 tasks from your Zapier plan's quota. At scale, this gets expensive fast. Furthermore, Zapier abstracts away the complexity of NetSuite, but hides the relational depth that AI agents need. There is no unified data model—you work with NetSuite's native internal schema, which means the AI needs to understand NetSuite's proprietary field names.

4. Truto (Managed Unified API with Dynamic MCP)

As we've covered in our guide to managed MCP for Claude, Truto provides a managed unified API platform that dynamically exposes NetSuite (and hundreds of other SaaS platforms) as fully scoped MCP servers.

• Positioning: Built specifically for B2B SaaS companies shipping integrations to their end users. Truto connects across all three API layers (REST, SOAP, RESTlets) and normalizes the underlying complexity while providing secure, self-contained MCP server URLs.
• Best for: Engineering teams building agentic AI products that require multi-tenant, managed auth, and normalized data across all their customers' ERPs without maintaining integration infrastructure.
• The Catch: Requires adopting a unified API architecture for your integration layer, which represents a structural shift in how your application handles third-party data.

How Truto Solves the NetSuite MCP Challenge

If you are building a B2B SaaS product, Truto's approach to integrating the NetSuite API without SOAP complexity provides the most scalable foundation for AI agents. Truto does not just pass JSON back and forth. The platform actively mitigates NetSuite's architectural flaws through several key design decisions.

SuiteQL-First Data Strategy

Nearly all read operations in Truto's NetSuite integration use SuiteQL rather than the standard REST record API. This enables multi-table JOINs, complex filtering, and significantly better performance for list operations.

More importantly, Truto uses feature-adaptive queries. The platform automatically detects the customer's NetSuite edition at connection time. If the account is OneWorld (multi-subsidiary), queries dynamically include subsidiary JOINs. If the account supports multi-currency, currency table JOINs are included. This prevents query failures across different customer environments.

SOAP Fallbacks and SuiteScript for What REST Cannot Do

While SuiteQL handles the bulk of the work, it has blind spots. Sales tax item details require the legacy SOAP getList operation because SuiteQL does not expose the full tax rate configuration. Purchase Order PDF generation requires a deployed Suitelet via SuiteScript.

Truto handles this protocol switching invisibly. The AI agent simply calls the list_tax_rates tool, and Truto executes the necessary XML payload or Suitelet invocation in the background.

Polymorphic Resource Routing

NetSuite splits concepts that modern CRMs unify. For example, NetSuite has separate internal endpoints for customer and vendor. Truto exposes a single unified contacts resource. When an AI agent calls the list_contacts MCP tool, Truto dynamically routes the request to the correct NetSuite resource based on the query parameters, simplifying the LLM's reasoning process.

Dynamic MCP Tool Generation

Truto does not hand-code MCP tools per endpoint. Instead, tools are generated dynamically from the integration's resource definitions and documentation records. A tool only appears in the MCP server if it has a corresponding documentation entry detailing the query schema and body schema.

This acts as a strict quality gate ensuring only well-described, tested endpoints are exposed to the LLM. When the agent invokes a tool, Truto maps the flat JSON-RPC input namespace into the correct query parameters and body payloads, delegating the execution to the proxy API handlers.

sequenceDiagram
    participant Agent as AI Agent<br>(Claude/ChatGPT)
    participant MCP as Truto MCP Server
    participant Router as API Router
    participant NS as NetSuite

    Agent->>MCP: tools/list (JSON-RPC)
    MCP-->>Agent: Available tools<br>(list_invoices, create_contact, etc.)
    Agent->>MCP: tools/call<br>list_all_netsuite_invoices
    MCP->>Router: Route to SuiteQL
    Router->>NS: SuiteQL query<br>(with edition-aware JOINs)
    NS-->>Router: Result set
    Router-->>MCP: Normalized response
    MCP-->>Agent: MCP result<br>(JSON with pagination cursors)

Why Proxy APIs and Unified APIs Are the Right Architecture for AI Agents

Before diving into NetSuite-specific tool definitions, it helps to understand the two abstraction layers that sit between an AI agent and a raw ERP API.

Proxy APIs wrap a provider's native API endpoints into a consistent REST-like interface. The proxy handles authentication, pagination, rate limit tracking, and response normalization for each API call. When an AI agent calls a Proxy API tool, it works with the provider's native schema - NetSuite field names, NetSuite record types, NetSuite status codes. The LLM sees the raw data shape but does not need to deal with OAuth signature math or pagination tokens.

Unified APIs add a second layer on top of Proxy APIs. They normalize data across providers into a common schema. An invoice from NetSuite, QuickBooks, and Xero all share the same field names and status values. This matters when your AI agent needs to reason consistently across multiple customers running different ERPs.

For most agentic workflows, Proxy APIs are sufficient. The LLM handles field-name differences naturally because it has broad knowledge of common ERP schemas. But when you are building a multi-ERP product where the agent's prompts and logic must be provider-agnostic - for example, a reconciliation agent that processes invoices identically regardless of whether the customer uses NetSuite or Xero - Unified APIs eliminate an entire class of prompt-engineering problems.

Truto exposes both layers as MCP tools. By default, MCP tools operate through the Proxy API, giving the agent direct access to the integration's native resources. For cross-ERP consistency, you can point the agent at Unified API endpoints instead. The choice depends on whether your agent needs provider-specific depth or cross-provider uniformity.

flowchart LR
    A[AI Agent] -->|MCP JSON-RPC| B[Truto MCP Server]
    B --> C{API Layer}
    C -->|Provider-native schema| D[Proxy API]
    C -->|Normalized schema| E[Unified API]
    D --> F[NetSuite<br>SuiteQL / REST / SOAP]
    E --> F
    E --> G[QuickBooks / Xero / SAP]

What the AI Agent Actually Sees: MCP Tool Definitions

When Claude, ChatGPT, or a custom LangChain agent connects to a Truto MCP server, it receives a list of tools generated dynamically from the integration's resource definitions. Here is what a typical NetSuite invoice tool looks like:

{
  "name": "list_all_netsuite_invoices",
  "description": "List all invoices from Oracle NetSuite. Supports filtering by invoice_type (bill for vendor bills, invoice for customer invoices), issue_date, and sorting by issue_date, due_date, or created_at.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "invoice_type": {
        "type": "string",
        "enum": ["bill", "invoice"],
        "description": "Filter by type: 'bill' for AP vendor bills, 'invoice' for AR customer invoices"
      },
      "issue_date": {
        "type": "string",
        "description": "Filter invoices by issue date (ISO 8601)"
      },
      "sort_by": {
        "type": "string",
        "enum": ["issue_date", "due_date", "created_at"],
        "description": "Sort results by the specified field"
      },
      "limit": {
        "type": "string",
        "description": "The number of records to fetch"
      },
      "next_cursor": {
        "type": "string",
        "description": "Cursor for the next page. Always send back the exact cursor value from the previous response without modifying it."
      }
    }
  }
}

A few things to notice about tool generation:

• Tool names are descriptive. list_all_netsuite_invoices, get_single_netsuite_contact_by_id, create_a_netsuite_purchase_order. The naming convention helps the LLM select the right tool without ambiguity.
• Pagination is built in. Every list tool automatically includes limit and next_cursor parameters. The cursor description explicitly instructs the LLM to pass cursor values back unchanged - this prevents a common failure mode where models try to decode or parse opaque pagination tokens.
• Only documented endpoints appear. A resource method must have a documentation record to become an MCP tool. This is a deliberate quality gate - undocumented or experimental endpoints never leak into the agent's toolset.
• Tags control scope. Tools can be tagged by functional area (e.g., accounting, hris). When you create an MCP server with tags: ["accounting"], only accounting-related tools appear, keeping the agent's context window focused.

Using Truto MCP Tools with LangChain

Here is a working example using LangGraph's create_react_agent with Truto's MCP server as the tool source:

from langchain_mcp_adapters.client import MultiServerMCPClient
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic
 
model = ChatAnthropic(model="claude-sonnet-4-20250514")
 
async with MultiServerMCPClient(
    {
        "netsuite": {
            "url": "https://api.truto.one/mcp/a1b2c3d4e5f6...",
            "transport": "streamable_http",
        }
    }
) as client:
    tools = client.get_tools()
    agent = create_react_agent(model, tools)
 
    result = await agent.ainvoke({
        "messages": [
            {
                "role": "user",
                "content": "Show me all overdue vendor bills over $5,000"
            }
        ]
    })

The MCP server URL is the only configuration the agent needs. The client discovers available tools automatically via the tools/list JSON-RPC method and invokes them via tools/call. The agent above would call list_all_netsuite_invoices with invoice_type=bill, then filter the results by due date and amount in its reasoning loop.

SuiteQL for Reads, REST for Writes: The Optimal Query Pattern

The single most important performance decision for a NetSuite AI integration is using SuiteQL for all read operations and the REST record API for writes. This is the pattern Truto follows internally, and it is the pattern your agents should rely on.

Why SuiteQL Wins for Reads

NetSuite's REST record API returns one record at a time with limited filtering. SuiteQL lets you run SQL-like queries with multi-table JOINs, WHERE clauses, and computed columns - all in a single request. For an AI agent listing invoices or searching contacts, the difference between one SuiteQL query and N+1 REST calls is the difference between staying within concurrency limits and getting throttled.

Here is a typical SuiteQL query that an agent would trigger when asking for open vendor bills:

SELECT
  t.id,
  t.tranid AS invoice_number,
  t.trandate AS issue_date,
  t.duedate AS due_date,
  BUILTIN.DF(t.entity) AS vendor_name,
  t.foreigntotal AS amount,
  BUILTIN.DF(t.currency) AS currency_code,
  BUILTIN.DF(t.status) AS status
FROM transaction t
WHERE t.type = 'VendBill'
  AND t.status = 'A'
ORDER BY t.duedate ASC

The BUILTIN.DF() function is a detail that matters for LLM readability. It returns display values (human-readable names) instead of internal IDs. Without it, the agent would see entity: 1234 instead of entity: Acme Corp, forcing an additional lookup or leaving the LLM unable to answer a natural language question.

For OneWorld (multi-subsidiary) accounts, the same query dynamically adds subsidiary JOINs. For multi-currency accounts, currency table JOINs are included. Truto detects these features at connection time and adjusts every query accordingly - the agent never needs to know which NetSuite edition the customer runs.

REST for Creates and Updates

SuiteQL is read-only. Any write operation - creating a purchase order, updating a vendor, deleting a journal entry - must go through the REST record API:

POST /services/rest/record/v1/purchaseOrder
 
{
  "entity": {"id": "1234"},
  "trandate": "2026-04-18",
  "item": {
    "items": [
      {
        "item": {"id": "567"},
        "quantity": 100,
        "rate": 25.00
      }
    ]
  }
}

As of the 2026.1 release, NetSuite now supports batch operations - you can add, update, delete, or upsert multiple records of the same type in a single asynchronous REST request. This is a significant improvement for write-heavy agent workflows that previously hit concurrency limits with sequential single-record calls.

Handling NetSuite Rate Limits with AI Agents

This is the most critical architectural boundary you must understand when connecting AI agents to NetSuite: handling rate limits. Most guides hand-wave this with phrases like "the platform handles rate limits for you." Let's be precise about what actually happens.

NetSuite caps objects at 1,000 per request and enforces frequency limits over 60-second and 24-hour windows. Exceeding these triggers 429 "Too Many Requests" errors for REST APIs or 403 "Access Denied" for SOAP.

And here is the really painful part: NetSuite provides no guaranteed Retry-After header. Error messages are generic—a 429 does not tell you whether you hit concurrency or frequency limits. If an AI agent attempts to execute a massive batch of parallel tool calls to reconcile hundreds of invoices, NetSuite will aggressively reject the requests.

Truto does NOT automatically retry, throttle, or apply backoff on rate limit errors.

Masking rate limits behind infinite auto-retries is a dangerous anti-pattern that leads to cascading timeouts and zombie processes in agentic workflows. When NetSuite returns a 429 error, Truto passes that error directly back to the caller.

Instead, Truto normalizes the chaotic rate limit information from NetSuite into standardized IETF HTTP response headers:

• ratelimit-limit: The maximum number of requests permitted in the current window.
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The number of seconds until the rate limit window resets.

It is the absolute responsibility of the AI agent (or the orchestration framework like LangGraph) to read these standardized rate limit headers and implement its own exponential backoff logic.

sequenceDiagram
    participant Agent as AI Agent
    participant Truto as Truto Platform
    participant NetSuite as Oracle NetSuite

    Agent->>Truto: MCP Tool Call: list_invoices<br>(Batch 1 of 50)
    Truto->>NetSuite: SuiteQL Query (OAuth 1.0 TBA)
    NetSuite-->>Truto: HTTP 429 Too Many Requests<br>(Concurrency Limit Exceeded)
    Truto-->>Agent: HTTP 429 Too Many Requests<br>ratelimit-reset: 15
    
    Note over Agent: Agent detects 429.<br>Reads ratelimit-reset.<br>Pauses execution for 15s.
    
    Agent->>Truto: Retry MCP Tool Call: list_invoices
    Truto->>NetSuite: SuiteQL Query (OAuth 1.0 TBA)
    NetSuite-->>Truto: HTTP 200 OK<br>Results
    Truto-->>Agent: MCP Result: { invoices: [...] }

Here is what that backoff logic looks like in practice using Python:

import time
import httpx
 
def call_mcp_tool(client, url, payload, max_retries=3):
    for attempt in range(max_retries):
        response = client.post(url, json=payload)
 
        if response.status_code == 429:
            reset_seconds = int(
                response.headers.get("ratelimit-reset", 5)
            )
            wait = min(reset_seconds, 2 ** attempt * 2)
            print(f"Rate limited. Waiting {wait}s (reset in {reset_seconds}s)")
            time.sleep(wait)
            continue
 
        return response.json()
 
    raise Exception("Max retries exceeded for rate limit")

The ratelimit-remaining header is especially useful for proactive throttling. If your agent sees remaining requests dropping toward zero, it can slow down before hitting a 429, which is far better than slamming into the limit and waiting for the reset window.

Auth Best Practices: TBA vs OAuth 2.0 for Unattended Agents

NetSuite's authentication landscape is in transition, and if you are building AI agent integrations today, you need to understand both the current reality and the migration timeline.

Token-Based Authentication (TBA) - The Current Workhorse

TBA is NetSuite's OAuth 1.0-style mechanism. It uses four static credentials (consumer key, consumer secret, token ID, token secret) to compute an HMAC-SHA256 signature for every HTTP request. No user interaction is required after initial setup, making it the default choice for unattended server-to-server integrations and AI agents that run without human intervention.

The signature computation is the hard part. Each request requires concatenating the HTTP method, URL, timestamp, nonce, and credentials into a specific base string format, then computing an HMAC digest. A single character mismatch produces an opaque authentication failure with no useful error message.

Truto handles this signature computation for every request. When your customer connects their NetSuite account, Truto stores the four TBA credentials and generates the correct signature for each API call transparently.

OAuth 2.0 - The Future

Oracle is actively pushing all NetSuite integrations toward OAuth 2.0. The migration timeline is firm:

• 2026.1 (now): Starting with the 2026.1 NetSuite release, all newly built integrations should use REST web services with OAuth 2.0.
• 2027.1: NetSuite has confirmed that creating new integrations using TBA with SOAP, REST, or RESTlets will no longer be possible.
• 2028.2: All SOAP endpoints will be disabled, and SOAP-based integrations will stop working.

OAuth 2.0 supports two grant types in NetSuite: Authorization Code Grant (with PKCE, requires user interaction) and Client Credentials Grant (machine-to-machine, uses certificate-based JWT). For unattended AI agents, the Client Credentials grant is the relevant path - it issues bearer tokens without user login, similar to how TBA works but with token refresh and scoped permissions.

What This Means for B2B SaaS Teams

1. New integrations: Use OAuth 2.0 Client Credentials where possible.
2. Existing TBA integrations: Continue using them, but begin auditing and planning migration before 2027.1.
3. SOAP dependencies: If your integration uses SOAP (for example, tax rate lookups), migrate those specific calls to REST alternatives before 2028.2.
4. Managed platforms: Using a platform like Truto insulates you from the auth migration. When the underlying auth mechanism changes, the platform handles the transition without requiring changes to your application code.

Setting Up Your NetSuite MCP Server in Minutes

Deploying a NetSuite MCP server via Truto requires zero infrastructure management. The process relies on secure, self-contained URLs.

First, your customer authenticates their NetSuite instance through Truto's managed OAuth 1.0 TBA flow. Once the account is linked and credentials are automatically managed, creating an MCP server is a single API call:

curl -X POST https://api.truto.one/integrated-account/{id}/mcp \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "NetSuite Accounting - Read Only",
    "config": {
      "methods": ["read"],
      "tags": ["accounting"]
    }
  }'

When creating the server, you apply strict configuration filters. You can restrict the server to specific HTTP methods (methods: ["read"]) to prevent the LLM from accidentally deleting records, or filter by tags (tags: ["accounting"]) to hide HRIS resources.

Truto validates that the integration has tools available, generates a secure, cryptographically hashed token, and returns a ready-to-use URL:

{
  "id": "mcp-789",
  "name": "NetSuite Accounting - Read Only",
  "config": { 
    "methods": ["read"], 
    "tags": ["accounting"] 
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

This URL is fully self-contained. You simply plug it into your AI client:

• Claude: Settings > Connectors > Add custom connector > paste URL
• ChatGPT: Settings > Apps > Advanced settings > enable Developer mode > add MCP server
• Custom LangChain Agents: Point your MCP client at the URL. It speaks JSON-RPC 2.0 natively.

If you require higher security for sensitive environments, you can enforce an additional layer of authentication by enabling require_api_token_auth, which requires the client to pass a valid API token alongside the MCP URL, ensuring that leaked URLs cannot be abused.

Runtime Feature Detection Checklist

NetSuite instances are not uniform. A query that works on one customer's account will fail on another if you do not detect their edition and feature set first. Before your AI agent executes its first tool call against a new NetSuite account, the following checks must pass.

Truto runs these checks automatically as a post-install action when a customer connects their NetSuite account. The results are stored as context variables (multi_currency, multi_subsidiary) that every subsequent query references. If you are building your own integration, implement these checks before any data access and cache the results per account.

Troubleshooting Common Detection Failures

• "Record not found" on currency or subsidiary queries is the expected signal for single-currency or standard (non-OneWorld) accounts. This is not an error - it is how you differentiate editions.
• Suitelet URL parsing failures usually mean the customer has not deployed the required SuiteScript bundle. PDF generation and field metadata tools will not appear in the MCP server until this is resolved.
• Validation test failures during account connection typically indicate permission issues. Truto validates by testing three requests: listing accounts (SuiteQL access), fetching company info (subsidiary access), and listing vendor contacts (record access). If any fail, the account is flagged for credential review.

Beyond NetSuite: Connecting AI Agents to SAP S/4HANA

If your customers run SAP alongside or instead of NetSuite, the connectivity challenge shares the same structural patterns but with different technical details.

SAP's API Surface

A full SAP S/4HANA implementation comes with over 4,000 OData services that can be enabled and consumed out of the box. These are split across OData v2 (most existing services) and OData v4 (newer services with better JSON support and reduced payload sizes). Beyond OData, legacy access paths include BAPIs (Business Application Programming Interfaces), RFCs (Remote Function Calls), and IDocs (Intermediate Documents for batch data exchange).

For AI agents requiring real-time data access, SAP Gateway and OData services expose SAP functionality through RESTful APIs. The OData standard provides a consistent query language ($filter, $select, $expand) across different SAP modules, which simplifies agent development compared to NetSuite's multi-protocol fragmentation. However, SAP's data model is rigid, making it difficult to integrate with modern AI/ML tools without an intermediary that understands the schema.

SAP's MCP Strategy

SAP is investing heavily in MCP. SAP itself is fully committed to MCP and is trying to support it as broadly as possible - SAP HANA Cloud received full MCP support from Q1 2026, giving Joule agents direct access to the database engine. SAP also announced a Storefront MCP server for SAP Commerce Cloud, planned for Q2 2026, which allows AI agents to discover products and execute transactions autonomously.

The open-source community has built dozens of SAP MCP servers for developer tooling - ABAP development, Fiori app generation, BTP services, and CDS modeling. However, most of these are oriented toward developers working inside the SAP ecosystem, not toward B2B SaaS companies connecting external AI agents to customers' SAP data. The multi-tenant orchestration problem - managing auth, respecting per-customer configurations, normalizing data across different SAP deployments - is largely unsolved by SAP's first-party tooling.

The Multi-ERP Reality

Many enterprise customers run both NetSuite (often for financial management in mid-market subsidiaries) and SAP S/4HANA (for manufacturing, supply chain, or global operations). If your AI product needs to work across both, the architectural requirements converge:

• Managed authentication across different auth models (NetSuite TBA/OAuth 2.0, SAP OAuth 2.0/certificate-based auth)
• Feature-adaptive queries that adjust to each customer's configuration
• Normalized rate limit handling across providers with different throttling behaviors
• A consistent tool interface so your agent's prompts and logic do not need provider-specific branches

This is where a unified API approach pays off. Instead of building and maintaining separate integrations for each ERP, a managed platform handles the per-provider complexity while your agent works with a consistent interface - whether the data comes from NetSuite, SAP, QuickBooks, or Xero.

What Approach Should You Choose?

The right MCP server for NetSuite depends entirely on your use case.

If you are a NetSuite customer connecting your own instance, start with the NetSuite AI Connector Service. It is first-party, governed by NetSuite's role-based permissions, and Oracle is investing heavily in expanding it.

If you are a B2B SaaS company building a product that connects to customers' ERPs, this is where Truto fits. You get managed auth across NetSuite's OAuth 1.0 TBA, a SuiteQL-first data strategy that adapts to each customer's edition, normalized rate limit headers your agents can act on, and dynamic MCP tool generation—alongside 250+ other integrations through the same architecture. The alternative is building and maintaining all of that yourself, across every ERP your customers use.

If SAP S/4HANA is also in your customer base, the same principles apply. SAP's first-party Joule agents and MCP servers are optimized for internal use within the SAP ecosystem. For external, multi-tenant connectivity, you need the same managed integration layer that handles OData services, authentication, and per-customer configuration differences.

The ERP-to-AI bridge is being built right now. Gartner predicts that finance organizations using cloud ERP applications with embedded AI assistants will see a 30% faster financial close by 2028. Whether you use it for automated invoice reconciliation, natural language financial reporting, or intelligent expense parsing, the infrastructure decision you make today determines how fast your agents can access the data they need.

Stop fighting NetSuite's API quirks and start shipping agentic workflows.