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., "@mcp-netsuite-practice How much stock do we have for SKU ASAFE-BARRIER-01?"
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.
Python MCP server that exposes read-only NetSuite tools for agents such as Claude Desktop or Claude Code. It lets an LLM query warehouse stock and order status without putting API keys in the client.
Tool | Arguments | Description |
|
| Available units for a SKU in warehouse |
|
| Current status of an order |
| (none) | Admin-only mock catalog reload (RBAC demo) |
NetSuite access goes through a stable client interface. Local development uses a mock with sample inventory data; the same interface can later target a real sandbox via environment variables.
Product specification: project.md.
Agent quality harness: AGENTS.md (also CLAUDE.md).
Python 3.12+
Official mcp SDK (stdio and HTTP/SSE)
FastAPI + Uvicorn for remote transport
OAuth2 authorization-code + PKCE (demo IdP) and JWT bearer auth
Pydantic / pydantic-settings for schemas and config
Docker, Kubernetes manifests, Terraform module for cluster deploy
Related MCP server: MCP API Tool Demo
flowchart TD
Agent[Agent: Claude Desktop / Claude Code]
OAuth[OAuth2 PKCE demo IdP]
MCP[MCP Server FastAPI SSE]
RBAC[RBAC by role]
Tools[Tools: stock / order / admin]
Schemas[Pydantic schemas]
Client[NetSuite client interface]
Mock[Mock data]
Sandbox[NetSuite sandbox]
Agent -->|stdio local| MCP
Agent -->|HTTP SSE + Bearer JWT| MCP
Agent --> OAuth
OAuth -->|access token| Agent
MCP --> RBAC
RBAC --> Tools
MCP --> Schemas
Tools --> Client
Client --> Mock
Client -.-> SandboxThe MCP server exposes typed tools to the agent. Remote mode validates a JWT from the PKCE flow and enforces least privilege (for example sales cannot call admin_reload_catalog). Tools call a NetSuite client interface so the protocol layer stays decoupled from the ERP.
Requirements: Python 3.12+, uv.
uv sync
uv run python -m mcp_netsuite_practice{
"mcpServers": {
"netsuite-practice": {
"command": "uv",
"args": [
"--directory",
"C:/Users/antonio/Desktop/MCP-netsuite-practice",
"run",
"python",
"-m",
"mcp_netsuite_practice"
]
}
}
}Example prompts:
“How much stock do we have for SKU BARRIER-01?”
“What is the status of order SO-10042?”
cp .env.example .env
uv run python -m mcp_netsuite_practice --transport sseEndpoints:
Path | Purpose |
| Liveness/readiness |
| PKCE authorize (demo login via query params) |
| Exchange code + |
| MCP SSE transport |
| MCP SSE message endpoint |
Obtain a token (PKCE), then call MCP with Authorization: Bearer <token>.
Roles: sales, ops, admin. Sales may use stock/order tools only.
docker compose up --buildManifests: deploy/k8s/
Terraform module: deploy/terraform/ (see its README)
Variable | Purpose |
|
|
| Issuer / resource base URL for OAuth metadata |
| HS256 signing secret |
| Public PKCE client id |
| Enable bearer auth on SSE ( |
|
|
uv run pytestReturn the current status of a global sales order.
Use when the user asks about an order, shipment progress, or fulfillment state for an order id (for example SO-10042).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
| Name | Required | Description |
|---|---|---|
| sku | Yes | |
| status | Yes | |
| order_id | Yes | |
| quantity | Yes | |
| customer_name | Yes | |
| ship_to_country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read-only status lookup, but does not explain the response format, potential error cases, or whether the data is live or cached. For a simple read operation, this is adequate but minimal.
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 redundant information. The first sentence states the primary purpose, and the second provides usage guidance. It is front-loaded and every sentence earns its place.
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?
For a simple one-parameter tool with an output schema, the description is complete enough. It covers the core purpose, usage scenarios, and provides a parameter format example. It does not discuss edge cases like not-found errors, but the output schema likely covers return values, so this is not a major gap.
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 only shows a single string parameter 'order_id' with no description. The description adds value by mentioning 'for an order id' and giving an example format 'SO-10042', which clarifies the expected input format. This compensates for the 0% schema description coverage.
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 starts with 'Return the current status of a global sales order', which is a specific verb+resource statement. This clearly distinguishes it from the sibling tool get_stock_level, which is about inventory levels. The example 'SO-10042' further reinforces the order context.
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 explicitly states when to use this tool: 'when the user asks about an order, shipment progress, or fulfillment state for an order id'. This gives clear context, though it does not explicitly mention when not to use it or name alternatives. The sibling tool is about stock, so the usage boundary is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return available warehouse units for an A-SAFE product SKU.
Use when the user asks about inventory, stock on hand, or availability for a specific SKU (for example ASAFE-BARRIER-01).
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
| Name | Required | Description |
|---|---|---|
| sku | Yes | |
| unit | No | |
| warehouse | Yes | |
| description | Yes | |
| quantity_available | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation by saying 'Return', but does not explicitly state safety, error handling, or side effects. It adds minimal behavioral context beyond the basic return.
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: a single sentence stating the purpose and one sentence for usage guidance. It is front-loaded with the action and contains no unnecessary words.
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 tool is simple with one parameter and an output schema, so the description adequately covers what the tool does and when to use it. It could be more complete by explicitly contrasting with the sibling tool, but overall it is sufficient for the tool's complexity.
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 for the sku parameter, but the description compensates by providing a concrete example ('ASAFE-BARRIER-01'), which adds meaning beyond the bare string type. This helps the agent understand the expected format.
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 returns available warehouse units for a specific A-SAFE product SKU, using a specific verb and resource. It also distinguishes from the sibling tool by explicitly mentioning inventory/stock/availability use cases.
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 explicit guidance on when to use the tool ('Use when the user asks about inventory, stock on hand, or availability'). However, it does not explicitly state when not to use it or name alternative tools, leaving sibling differentiation implied rather than direct.
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.0get_order_statusget_stock_levelThe two tools target completely distinct domains: inventory (stock levels by SKU) and order fulfillment (order status by ID). There is no overlap in purpose or arguments, so an agent can easily select the correct tool.
Both tools follow a consistent get_noun_noun pattern (get_stock_level, get_order_status), using snake_case and a clear verb prefix. The naming is predictable and uniform.
With only two tools, the server feels minimal. For a practice server this may be intentional, but it borders on too sparse to represent a meaningful integration, though each tool covers a distinct, useful query.
The tool surface only provides single-record lookups (by SKU and order ID) with no list, create, update, or delete operations. This is a significant gap for an ERP domain like NetSuite, where typical workflows require broader coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/awnt9/mcp-netsuite-practice'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
