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., "@vanam-erp-mcp Look up stock for item 'ABC-123'."
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.
사내 AI 챗봇용 재고 조회 MCP 서버입니다.
데이터 흐름:
사내 포털 → OpenClaw → (이 MCP 서버) → 재고앱 내부 API → DB이 서버는 조회 전용입니다. 쓰기(입고/출고/수정) 도구는 제공하지 않습니다.
도구 | 설명 | 입력 |
| 재고 품목을 이름이나 코드로 검색. 품목의 |
|
| 특정 품목의 현재 재고 수량 조회. |
|
재고 수량을 알려면 먼저
search_items로 품목id를 찾은 뒤, 그id로get_stock을 호출합니다.
Related MCP server: erp-billing
Node.js 24 이상
의존성: @modelcontextprotocol/sdk (별도 빌드 단계 없음, 순수 JS)
npm install.env.example를 참고하세요.
변수 | 설명 |
| 재고앱 내부 API 인증용 머신 토큰. 재고앱 |
| 재고앱 내부 API 베이스 URL. 기본값 |
MCP_API_TOKEN은 절대 git에 커밋하지 마세요. (.gitignore에.env포함)
node server.js이 서버는 stdio 기반 MCP 서버이므로, 직접 실행하면 표준 입력을 기다리며 멈춰 있는 것이 정상입니다. 보통은 OpenClaw 같은 MCP 클라이언트가 자식 프로세스로 실행합니다.
MCP 서버 설정에 다음과 같이 추가합니다 (예시):
{
"mcpServers": {
"vanam-erp": {
"command": "node",
"args": ["/절대경로/vanam-erp-mcp/server.js"],
"env": {
"MCP_API_TOKEN": "<재고앱과 동일한 머신 토큰>",
"INVENTORY_API_BASE": "http://192.168.0.210:3000"
}
}
}
}모든 호출은 Authorization: Bearer <MCP_API_TOKEN> 헤더로 재고앱 내부 API에 요청합니다.
호출 타임아웃은 15초입니다.
API 오류·네트워크 오류가 발생해도 예외를 던지지 않고, 에이전트가 이해할 수 있도록 오류 설명 텍스트를 응답에 담아 반환합니다.
도구 | 내부 API |
|
|
|
|
특정 품목의 현재 재고 수량을 조회한다. 품목 id가 필요하다(search_items로 먼저 찾을 것). itemCode, itemName, currentQty를 반환한다.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | 품목 id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the return fields (itemCode, itemName, currentQty) and implies a read-only operation, but does not detail error handling or edge cases; still adds value beyond missing annotations.
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, well-structured sentences that deliver key information immediately without redundancy.
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?
Covers purpose, required input, relationship with sibling tool, and return fields; no output schema exists, so description compensates adequately for a simple query tool.
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 already covers the one parameter with a description; overall description reinforces its purpose and how to obtain it via search_items, adding useful context.
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 specifies the action (queries current stock quantity) and the resource (specific item), and distinguishes itself from sibling 'search_items' by indicating a prerequisite workflow.
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 to first use search_items to find the item ID, setting clear context for use but does not explicitly mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
재고 품목을 이름이나 코드로 검색한다. 예: 'VO2', '타겟'. 품목의 id, code, name, category를 반환한다. 재고 수량을 알려면 이 도구로 먼저 품목 id를 찾은 뒤 get_stock을 호출하라.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색어 (품목 이름이나 코드의 일부) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that the tool returns id, code, name, category, and implies read-only behavior. Missing details like pagination or case sensitivity, but these are minor for a simple search.
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 three sentences, each adding value: purpose, example, return fields and workflow. No extraneous information, 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?
For a simple tool with one parameter and no output schema, the description covers purpose, return format, and workflow. Slightly lacking details on edge cases (e.g., no results), but overall complete enough.
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 already covers the parameter meaning ('search term, part of item name or code'). The description adds examples and return fields but does not significantly enhance parameter semantics beyond the schema. Baseline 3 is appropriate.
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 verb ('search') and resource ('inventory items by name or code'), with examples. It distinguishes from the sibling tool 'get_stock' by specifying that this tool returns basic info and the other for stock quantity.
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 instructs when to use this tool (to find item id) and when to use the sibling 'get_stock' (after obtaining id). This provides clear workflow guidance.
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_stocksearch_itemsEach tool has a distinct purpose: search_items finds item IDs based on name/code, while get_stock retrieves stock quantity for a specific item. There is no functional overlap.
Both tools use a consistent verb_noun pattern (search_items, get_stock) with snake_case, making the naming predictable and clear.
With only 2 tools, the server feels undersized for an ERP system. While they form a minimal query workflow, a typical inventory toolset would include more operations.
The tools only cover searching items and querying stock levels. Missing CRUD operations for items and stock adjustments leave significant gaps for an inventory management server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LeeJunHeon/vanam-erp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server