Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@netsuite-saved-search-mcp detect anomalies in sample_gl_export.xls"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
NetSuite saved search exports look like Excel files but are actually XML SpreadsheetML with a .xls extension — Excel opens them, pandas trips on them, and most teams writing Claude integrations against NetSuite end up rebuilding the same parser by hand. This MCP server exposes those exports as a structured query interface for Claude: discover files, inspect columns, filter and aggregate rows, categorize by memo keywords, surface anomalies. Seven tools wrap a parser that handles the format's real quirks — entity-encoded text, empty cells flagged with ss:Index, drifting column layouts between saved searches, DateTime cells that won't parse. The parser runs in lxml's recovery mode and reports broken cells as structured warnings rather than crashing on them.
A condensed exchange reproduced from the claude-eval-harness
NetSuite suite's anomaly_zero_activity_june case (runs/baseline-sonnet-4-6.json).
The agent's tool calls are auditable, the parser's total_supporting_count
is citable, and the model never has to fabricate numbers it can't point at.
user What stands out in this GL? Run detect_anomalies on
sample_gl_export.xls (account_column=Account,
amount_column=Amount, period_column=Period).
agent → detect_anomalies(file_path="sample_gl_export.xls",
account_column="Account",
amount_column="Amount",
period_column="Period")
← {findings: [
{severity:"HIGH", category:"zero_activity_period",
description:"No rows recorded for Jun 2024",
total_supporting_count:0},
{severity:"MEDIUM", category:"ratio_anomaly",
description:"Account 1200 in Sep 2024 totals 319,219.74
— 3.1x the 1200 median of 103,259.01",
supporting_rows:[...10 rows...],
total_supporting_count:17}]}
agent HIGH: no rows posted to June 2024 inside an otherwise continuous
range — likely an extraction gap or skipped close. MEDIUM:
Account 1200 spiked to 3.1× its own median in September across
17 cited rows. supporting_rows trims to 10; total_supporting_count
carries the full count so it's verifiable.The full anomaly response also lives in examples/walkthrough.md.
Related MCP server: TabulaRAG
uvx netsuite-saved-search-mcp # or: pip install netsuite-saved-search-mcp
export NSMCP_ROOT=/path/to/your/exportsAdd to Claude Desktop's config (full version in examples/claude_desktop_config.json):
{
"mcpServers": {
"netsuite-saved-search": {
"command": "uvx",
"args": ["netsuite-saved-search-mcp"],
"env": {"NSMCP_ROOT": "/path/to/your/exports"}
}
}
}Then any tool call lands directly:
{
"tool": "query_export",
"arguments": {
"file_path": "Q3_GL.xls",
"filters": [{"op": "eq", "column": "Account", "value": "4000"}]
}
}The parser is usable directly without the MCP transport — useful for notebooks, batch scripts, or pytest fixtures that don't want stdio in the loop:
from netsuite_saved_search_mcp.parser import NetSuiteExport
export = NetSuiteExport("tests/fixtures/sample_gl_export.xls")
print(export.headers) # ['Order Type', 'Date', 'Period', ...]
print(len(export.rows)) # 212
print(export.rows[0]["Account"]) # '4000'NetSuiteExport(path) parses the file end-to-end on construction. .rows is a list of dicts keyed by header name; cell values are typed (str, int, float, datetime.date, bool, or None). .parse_warnings exposes any recoverable issues lxml hit on the way through.
For audit and accounting use, the server enforces a tight blast radius on what it can touch. (Reporting channel for vulnerabilities is in SECURITY.md.)
All reads constrained under NSMCP_ROOT. Every tool resolves its file-path argument relative to this env var (or os.getcwd() if unset). Paths that resolve outside the root raise PathTraversalError before any I/O.
Symlink-escape blocked via realpath comparison. _resolve_under_root calls Path.resolve() on the candidate then checks relative_to(root). resolve() collapses .. segments and follows symlinks to their real target, so a symlink inside the root that points outside it fails the check.
No writes. The parser opens .xls files for reading only. No tool writes to the filesystem.
No network calls. Runtime dependencies are mcp, lxml, python-dateutil, pydantic — none of them dial out during a tool call.
Stderr logs are scoped. Startup logs the NSMCP_ROOT path. Tool calls log nothing by default; row data, column values, and financial figures never reach the log handler.
NetSuite saved search exports use XML SpreadsheetML, not Excel binary, despite the .xls extension. Column layouts drift between saved searches, so code that hardcodes column letters breaks on the next export. Empty cells are silently omitted from each row with ss:Index attributes marking where they were, which trips naive sequential parsers. Every finance team using Claude with NetSuite ends up rebuilding the same parser. This server solves it once.
Tool | Description | Key parameters |
| Scan a directory for .xls files; return one summary per file with row counts, header counts, warning counts, and detected date range. |
|
| Return column headers, their spreadsheet column letters, and the 0-indexed header row. |
|
| Filter rows by a list of predicates (AND-combined), optionally project to a subset of columns, cap results. |
|
| Group rows by one or more columns; compute sum/count/avg/min/max per group. |
|
| Tag every row with a |
|
| Three checks: zero-activity periods (HIGH), ratio anomalies (MEDIUM), document-count variance (MEDIUM). |
|
| Return parse warnings (phantom_column, bad_datetime, encoding_recovery, empty_row_skipped) captured during parsing of the specified file. |
|
Predicates are a discriminated union keyed on op. Example query with two predicates:
{
"file_path": "deferred_commissions_2024.xls",
"filters": [
{"op": "eq", "column": "Account", "value": "1321"},
{"op": "date_range", "column": "Date", "start": "2024-01-01", "end": "2024-12-31"}
],
"columns": ["Date", "Document Number", "Amount", "Memo (line)"],
"limit": 100
}Measures for aggregate_export:
[{"column": "Amount", "op": "sum", "alias": "total"}, {"column": "Document Number", "op": "count"}]See examples/walkthrough.md for an end-to-end example using the included sanitized fixtures.
Only handles saved search exports, not raw transaction-level XML from SuiteScript or RESTlets.
All-string exports with no typed columns may misidentify the header row; an explicit header_row override is planned.
Memo categorization uses case-insensitive substring matching against US-English keywords. No stemming, no fuzzy matching.
detect_anomalies only recognises period labels in three formats — Jan 2024, January 2024, 2024-01. Quarter labels (Q1 2024) and fiscal-period labels are silently skipped. The ratio and document-count checks also need ≥3 distinct periods to produce a finding.
Not optimized for exports larger than 100k rows. The cache holds parsed NetSuiteExport instances in memory keyed by (path, mtime) and is unbounded — a long-running session against a large directory will keep every parsed export resident.
Coverage tested against three synthesized fixtures that exercise typed cells, lxml recovery, and 14-row-metadata header detection. Real-world saved searches with column layouts beyond those shapes may surface gaps.
v0.1. The MCP tool schemas and the parser's Predicate/Measure models may change before v1.0.
Issues and PRs welcome. Run uv run pytest, uv run mypy src, and uv run ruff check src tests before submitting; all three should be clean. Commits follow Conventional Commits. New tools require a Pydantic response model, a happy-path test against the included GL fixture, a failure-path test (missing file or unknown column), and an entry in the table above.
MIT. See LICENSE.
Group rows from a NetSuite export by one or more columns and compute aggregations per group. Each Measure carries column, op (sum/count/avg/min/max), and optional alias for the output key (defaults to {op}_{column}). Groups are returned in first-seen order. Use this instead of query_export when you want summary statistics rather than raw rows.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| group_by | Yes | ||
| measures | Yes |
| Name | Required | Description |
|---|---|---|
| groups | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses return order and output naming convention. However, it omits potential side effects, performance implications, or constraints (e.g., file size limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with core action, no redundant text. Essential details packed without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (aggregation with grouping and measures) and presence of output schema, description covers key aspects: measure definition, ordering, and use-case differentiation. No critical gaps apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial detail: measures structure (column, op, optional alias) and default output key pattern. Does not explain file_path format or group_by semantics, but compensates well for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it groups rows and computes aggregations per group, listing supported operations (sum, count, avg, min, max) and alias behavior. It explicitly distinguishes from sibling tool query_export, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool instead of query_export when summary statistics are needed. Provides context on return order (first-seen) and output key defaults, enabling correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tag every row with a derived _category based on case-insensitive substring matches across one or more memo columns. NetSuite GL exports usually carry both 'Memo (main)' and 'Memo (line)'; pass both so the keyword sweep covers all the prose. rules maps category name to a list of keywords; the first rule whose keyword appears in any memo wins; rows matching nothing fall into 'Uncategorized'. Returns the tagged rows plus a per-category count breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| memo_columns | Yes | ||
| rules | Yes |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| breakdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the matching logic and fallback to 'Uncategorized', and that it returns tagged rows with counts. However, it does not explicitly state that the tool is read-only or if it modifies the original file. It also doesn't mention error handling or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a purpose: the first states the core function, the second gives domain context, and the third explains the rules and output. No wasted words, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (as per context), the description is complete enough. It covers the input parameters, matching behavior, and output shape (tagged rows + per-category breakdown). It assumes reasonable domain knowledge about exports and rows but provides sufficient detail for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining the roles of all three parameters: file_path (via export context), memo_columns (pass both main and line), and rules (maps category to keyword list with first-match wins). This adds significant meaning beyond the bare schema, though it lacks examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: tagging rows with a category based on case-insensitive substring matches across memo columns. It specifies the verb (tag), resource (rows from a NetSuite GL export), and method (keyword matching). The purpose is distinct from sibling tools like aggregate_export or detect_anomalies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool, e.g., for NetSuite GL exports with memo columns. It implies usage for categorization tasks but does not explicitly compare to siblings or state when not to use it. The guidance is clear enough for an AI agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run three anomaly checks against a NetSuite GL-style export and return Findings: (1) zero_activity_period — month gaps inside the observed period range (HIGH); (2) ratio_anomaly — (account, period) total greater than 2x the account's median total across periods (MEDIUM); (3) document_count_variance — period row count more than 2 stdev from the mean across periods (MEDIUM). Each Finding includes severity, description, up to 10 supporting_rows, and total_supporting_count for the true un-truncated count. The period column should contain labels like 'Jan 2024', 'January 2024', or '2024-01'.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| account_column | Yes | ||
| amount_column | Yes | ||
| period_column | Yes |
| Name | Required | Description |
|---|---|---|
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the three anomaly checks, severity levels, and output structure (Findings with supporting_rows and total_supporting_count). It also specifies acceptable period column formats. This provides good transparency, though it doesn't mention whether the tool is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently front-loads the core purpose and lists the three checks. It is concise without superfluous text, though it could benefit from bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and low schema coverage, the description covers the tool's functionality and output structure well. However, it omits parameter descriptions for three of four parameters, making it incomplete for an agent to correctly select and invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain each parameter. It only addresses the period_column format in the last sentence, providing no guidance on file_path, account_column, or amount_column. This leaves most parameters inadequately explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs three specific anomaly checks on NetSuite GL-style exports and returns Findings. It lists each check with severity and description, making the purpose very clear and distinguishing it from sibling tools like aggregate_export or query_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives like categorize_by_memo or get_headers. It implies the tool is for anomaly detection in financial data, but lacks direct guidance on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the column headers of a NetSuite saved-search export plus their spreadsheet column letters (A, B, ..., AA, AB) and the 0-indexed header_row. Call this before query_export or aggregate_export when you don't already know the column names — every other tool takes column names verbatim and errors on typos with a difflib suggestion.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| headers | Yes | |
| column_letters | Yes | |
| header_row | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values and warns about other tools' error behavior. No annotations provided, but description covers key behavioral aspects. Could mention read-only nature explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with functionality and usage advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool simplicity (one param, likely simple output), description covers purpose, usage context, and return values adequately. Output schema existence reduces burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'file_path' not described beyond name; schema coverage is 0%. Though context implies it's a file path to an export, explicit description would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it returns column headers with spreadsheet letters and header_row. Clearly distinguishes from siblings by advising to call it before query_export or aggregate_export when column names are unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use when you don't know column names, as other tools error on typos. Describes the purpose in context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the parse warnings for the export at file_path, parsing it on demand if it isn't already cached. Warning kinds: phantom_column (cell at a column index beyond the header count), bad_datetime (DateTime cell that wouldn't parse — raw string is preserved in the row), encoding_recovery (lxml had to recover from invalid XML), empty_row_skipped. Call this after any other tool reports a non-zero warning_count to see exactly which rows are affected.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses on-demand parsing behavior and lists warning kinds. With no annotations, this is good coverage, though it could mention error cases or performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a concise list of warning kinds. Every sentence adds value with no waste. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description fully covers what the tool does, when to use it, and what the returned warnings represent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0% and a single trivial parameter (file_path), the description merely restates the parameter without adding meaning. For a simple parameter, this is adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns parse warnings for an export at a given file_path, with on-demand parsing. Distinguishes itself from sibling tools like aggregate_export or query_export by focusing on warning details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool after another tool reports a non-zero warning_count, providing clear when-to-use context and implied alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every NetSuite saved-search export (.xls) in a directory under NSMCP_ROOT. Returns one ExportSummary per file with row count, header count, 0-indexed header_row, warning count, and detected date range. Files that can't be parsed even with lxml recovery come back with parse_error populated and the other fields None. Call this first when you don't already know which exports are available.
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses error behavior (unparseable files return parse_error). It mentions return fields but does not address authorization or read-only nature. The disclosure is useful but could be more comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste: first sentence covers purpose and output, second sentence covers error handling and usage recommendation. Every sentence adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality, error case, and usage hint. An output schema exists, so return value details are not needed. For a simple list operation with one parameter, it is nearly complete, though additional context about directory path might help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'directory' lacks any description in the schema (0% schema description coverage). The description mentions 'under NSMCP_ROOT' but does not clarify if it is relative or absolute, format, or valid values, leaving the agent with insufficient semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NetSuite saved-search exports under NSMCP_ROOT, specifies the return type (ExportSummary with fields), and distinguishes itself by recommending it as the first call when exports are unknown. This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Call this first when you don't already know which exports are available,' providing clear usage context. However, it does not explicitly state when not to use this tool or mention alternative sibling tools (e.g., query_export), but the guidance is still effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter rows from a NetSuite export by a list of predicates (AND-combined; empty list returns everything). Predicate ops: eq/ne, gt/gte/lt/lte, contains/not_contains (case-insensitive by default), regex, date_range (ISO 8601 start/end, inclusive by default). Optionally project to a subset of columns via the columns argument. Implicit limit=1000; pass limit=0 to get total_matched without fetching any rows. Returns rows, total_matched, and a truncated flag.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| filters | No | ||
| columns | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| rows | Yes | |
| total_matched | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: predicates are AND-combined, operators are listed with defaults (case-insensitive, inclusive date ranges), limit behavior (implicit 1000, limit=0 for total count), and return structure (rows, total_matched, truncated flag). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently cover purpose, operators, projections, and limit/return details. Every sentence adds value without redundancy. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of predicates and limit options, the description covers all essential behavior. The output schema is noted but not needed to explain returns since the description already lists rows, total_matched, and truncated flag. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds critical semantics: how filters combine, operator behaviors, default case-insensitivity, limit=0 behavior, and column projection. This goes well beyond what the raw schema provides, earning a top score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as filtering rows from a NetSuite export using a list of AND-combined predicates. It specifies the resource (rows from export), the action (filter), and key details like operators and result. This distinguishes it from sibling tools like aggregate_export or get_headers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to filter rows) and provides context on predicates and projections. However, it does not explicitly state when not to use it or mention alternatives among siblings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.3aggregate_exportcategorize_by_memodetect_anomaliesget_headersget_parse_warningslist_exportsquery_exportEach tool has a clearly distinct purpose: informational (get_headers, list_exports, get_parse_warnings), data retrieval (query_export, aggregate_export), and analysis (categorize_by_memo, detect_anomalies). No overlap in functionality.
All tool names follow a consistent verb_noun pattern (e.g., get_headers, list_exports, query_export). No mixing of conventions or obscure abbreviations.
Seven tools is well-scoped for a saved-search MCP, covering listing, header inspection, querying, aggregation, categorization, anomaly detection, and parse warnings. No tools feel extraneous or missing.
The tool set provides a complete workflow for analyzing NetSuite saved-search exports: discover exports (list_exports), inspect headers (get_headers), fetch raw rows (query_export), compute summaries (aggregate_export), enrich with categories (categorize_by_memo), detect anomalies (detect_anomalies), and diagnose parsing issues (get_parse_warnings). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Query and audit AppSheet apps in natural language via Knotrik's pre-scanned definitions.
BETA — Run SuiteQL, read/write NetSuite records, query SuiteAnalytics, and run saved bookmarks.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/maximizeGPT/netsuite-saved-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
