New Script Type: Custom Tool Scripts for the NetSuite AI Connector Service (MCP)

What changed

NetSuite introduces a new SuiteScript 2.1 script type: Custom Tool. This script type is purpose-built for the NetSuite AI Connector Service, allowing external AI clients (including MCP-compatible apps) to invoke SuiteScript operations from natural-language prompts. In effect, your NetSuite account becomes a tool-calling backend for AI agents.

How it works

• Each custom tool is defined by a JSON tool schema specifying a name, description, and input parameters. The AI client reads this schema to determine when a tool is relevant and what arguments to pass.
• Tools are grouped into a toolset SDF custom object. The toolset also declares the permission prerequisites that control whether a given tool is visible to the AI client for a particular user.
• Visibility is gated by the toolset permissions, but runtime execution still respects the user's NetSuite role and permissions — the tool cannot escalate beyond what the invoking user can already do.
• Deployment is exclusively through SDF, either as a SuiteApp project or an Account Customization Project (ACP). There is no UI-based script-record creation path mentioned.

Module restrictions

The following SuiteScript modules are not supported inside custom tool scripts:

• N/http
• N/https
• N/llm
• N/sftp

This means custom tools cannot make outbound HTTP/SFTP calls or invoke NetSuite's own LLM module. All data access must go through record, search, query, or other permitted modules. The restriction on N/http/N/https is significant — if your tool needs to call an external API, you will need an alternative pattern (e.g., a Map/Reduce or Scheduled script triggered by the tool, or a pre-cached record).

MCP integration

The documentation explicitly references Building MCP Apps (Interactive UI) with Custom Tools, confirming that the AI Connector Service exposes these tools via the Model Context Protocol. Oracle also provides sample implementations in the MCP-Sample-Tools directory of the SuiteCloud Project Repository on Oracle Samples GitHub.

What is unclear

• The source does not specify which NetSuite release introduced this script type. The release version is not stated in the page title, URL, or body text.
• No governance-cost information is provided. It is unknown whether custom tool invocations consume governance units similarly to RESTlets or Suitelets, or whether a separate quota applies.
• The exact SDF object type name for the toolset (e.g., customtooltypeset or similar) is not specified in this overview page — consult the linked "Custom Tool Scripts as XML Definitions" page for the XML schema.
• No details on rate limits, maximum payload sizes, or concurrency caps for AI Connector tool invocations.

What to do

1. Review the linked sub-pages — especially "Custom Tool JSON Schema", "Custom Tool Script Requirements", and "Custom Tool Scripts as XML Definitions" — for the exact SDF object definitions, entry-point function signatures, and schema-validation rules.
2. Clone the sample tools. Pull the MCP-Sample-Tools directory from Oracle's SuiteCloud Project Repository on GitHub and deploy to a sandbox to understand the toolset/tool relationship and JSON schema structure.
3. Audit your module usage. If you plan to convert existing RESTlet or Suitelet logic into custom tools, verify that none of it depends on N/http, N/https, N/llm, or N/sftp. Refactor any outbound-call logic into a separate script type that the tool can trigger asynchronously.
4. Design permission models. Decide which roles should see which tools in the AI client. Map your existing role/permission matrix to toolset permission requirements before deploying.
5. Test governance impact. Since governance costs are undocumented in this page, instrument your tools with N/runtime.getCurrentScript().getRemainingUsage() to measure actual unit consumption during sandbox testing.
6. Plan for SDF deployment. Custom tools are SDF-only — ensure your CI/CD pipeline supports SDF project deployments if it does not already.