Loading ToolBench
MCP server for interacting with NetSuite ERP system via REST API and SuiteQL queries
NetSuite MCP Server has fundamental definition quality issues. While 6 tools are explicitly registered with schemas via zod, most parameter descriptions are missing or trivial (null descriptions), and tool descriptions lack operational guidance. The schemas present are basic type definitions without enums, constraints, or ranges. No output schema is documented, error handling is minimal, and security-sensitive operations (create_record, update_record) lack safeguards. The naming follows verb_noun convention, which is positive, but descriptions fall well short of the 194-char baseline for A-grade tools. Median tool score: 42/100.
Create a new NetSuite record
Get a NetSuite record by type and ID
Get NetSuite REST API metadata
Search NetSuite records via SuiteQL
Execute a SuiteQL query against NetSuite
Update a NetSuite record
Parameter descriptions are missing or null (recordType, data, condition, orderBy in search_records; recordType, data in create_record; recordType, id, data in update_record; recordType in list_metadata). LLMs cannot infer parameter meaning from names alone.
No output schema is documented for any tool. All tools return {content: [{type: 'text', text: JSON.stringify(...)}]} but the structure of the JSON is undocumented. LLMs cannot plan chaining without knowing what fields to extract.
create_record and update_record accept data as a free-form string (JSON.parse(data)), with no schema validation, no format guidance, and no examples. LLMs will hallucinate invalid JSON structures. No dry-run or confirmation step for destructive operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
search_records, create_record, update_record lack descriptions for the SuiteQL syntax, data format, and constraints. A user must already know NetSuite API structure; the tool provides no guidance.
No enum constraints on recordType parameters. LLMs can pass any string; the tool will fail at the API level with a cryptic error. Should define valid record types or document how to discover them via list_metadata.
Error handling is minimal. Errors from nsRequest() and executeSuiteQL() are thrown as raw messages without categorization, recovery guidance, or invalid-input hints. An LLM will see 'NetSuite API error 400: ...' with no direction on how to recover.
No pagination hints. search_records defaults to limit=50 but provides no documentation of the total result count, next_cursor, or how to paginate. Large result sets will silently truncate.
Tool descriptions are too short (30-50 chars) and lack operational context. E.g. 'Execute a SuiteQL query against NetSuite' does not explain when to use suiteql_query vs search_records, what syntax is required, or what to expect in the result.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The tools are registered, but not marked as read-only or write/destructive. Modern MCP clients use these hints for safety and UI presentation.
No parameter ranges or constraints. limit and offset accept any number with no min/max validation. An LLM could pass limit=1000000 or offset=-1, causing API errors or unexpected behavior.