F
licenseB
qualityD
maintenanceA demonstration TypeScript MCP server that showcases basic MCP concepts with simple tools (greeting, calculator), text resources, and prompt templates for learning the Model Context Protocol.
2
erpnext-server
This server provides an MCP interface for AI assistants to integrate with an ERPNext/Frappe instance, enabling full management of ERP data and business operations.
Access Resources: Retrieve individual ERPNext documents via
erpnext://{doctype}/{name}URIs, returning structured JSON.List DocTypes: Retrieve all available DocTypes in your ERPNext instance (
get_doctypes).Get DocType Fields: Inspect the full field structure for any specific DocType, e.g., Customer or Item (
get_doctype_fields).List Documents: Fetch documents for a given DocType with optional filters, field selection, and result limits (
get_documents).Get Single Document: Retrieve a specific document by name, including child tables (
get_document).Create Document: Create new records by specifying a DocType and document data (
create_document).Update Document: Modify existing documents by providing the DocType, document name, and updated data (
update_document).Delete Document: Permanently delete a document (
delete_document).Submit Document: Submit a document, setting docstatus to 1 (
submit_document).Cancel Document: Cancel a submitted document, setting docstatus to 2 (
cancel_document).Call Method: Invoke any whitelisted ERPNext/Frappe server-side API method (
call_method).Run Report: Execute ERPNext reports by name with optional filters (
run_report).
Enables access to ERPNext documents and data, with tools for authentication, document management (listing, creating, updating), running reports, and retrieving DocType metadata.
Provides integration with the Frappe framework API, allowing interaction with the underlying platform that powers ERPNext for document and data management.
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., "@erpnext-servershow me the latest sales orders"
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.
ERPNext MCP Server
A Model Context Protocol server for ERPNext integration
This is a TypeScript-based MCP server that provides integration with ERPNext/Frappe API. It enables AI assistants to interact with ERPNext data and functionality through the Model Context Protocol.
Features
Resources
Access ERPNext documents via
erpnext://{doctype}/{name}URIsJSON format for structured data access
Tools
get_doctypes- Get a list of all available DocTypesget_doctype_fields- Get fields list for a specific DocTypeget_documents- Get a list of documents for a specific doctypeget_document- Get a single document by name, including all child tablescreate_document- Create a new document in ERPNextupdate_document- Update an existing document in ERPNextdelete_document- Permanently delete a documentsubmit_document- Submit a document (set docstatus to 1)cancel_document- Cancel a submitted document (set docstatus to 2)call_method- Call an ERPNext/Frappe whitelisted server-side API methodrun_report- Run an ERPNext report
Related MCP server: ERPNext MCP Server
Configuration
The server requires the following environment variables:
ERPNEXT_URL- The base URL of your ERPNext instanceERPNEXT_API_KEY(optional) - API key for authenticationERPNEXT_API_SECRET(optional) - API secret for authentication
Development
Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchInstallation
To use with Claude Desktop, add the server config:
On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"erpnext": {
"command": "node",
"args": ["/path/to/erpnext-server/build/index.js"],
"env": {
"ERPNEXT_URL": "http://your-erpnext-instance.com",
"ERPNEXT_API_KEY": "your-api-key",
"ERPNEXT_API_SECRET": "your-api-secret"
}
}
}
}To use with Claude in VSCode, add the server config to:
On MacOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
On Windows: %APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Debugging
Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:
npm run inspectorThe Inspector will provide a URL to access debugging tools in your browser.
Usage Examples
Get Customer List
<use_mcp_tool>
<server_name>erpnext</server_name>
<tool_name>get_documents</tool_name>
<arguments>
{
"doctype": "Customer"
}
</arguments>
</use_mcp_tool>Get Customer Details
<access_mcp_resource>
<server_name>erpnext</server_name>
<uri>erpnext://Customer/CUSTOMER001</uri>
</access_mcp_resource>Create New Item
<use_mcp_tool>
<server_name>erpnext</server_name>
<tool_name>create_document</tool_name>
<arguments>
{
"doctype": "Item",
"data": {
"item_code": "ITEM001",
"item_name": "Test Item",
"item_group": "Products",
"stock_uom": "Nos"
}
}
</arguments>
</use_mcp_tool>Get Item Fields
<use_mcp_tool>
<server_name>erpnext</server_name>
<tool_name>get_doctype_fields</tool_name>
<arguments>
{
"doctype": "Item"
}
</arguments>
</use_mcp_tool>Available Tools
6 toolscreate_documentC
Create a new document in ERPNext
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType (e.g., Customer, Item) | |
| data | Yes | Document data |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose idempotency, error behaviors, side effects, or ERPNext-specific constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While not bloated, the single sentence is insufficiently informative rather than appropriately concise for an ERP integration tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking an output schema, the description omits critical return value information and ERPNext-specific creation behaviors needed for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Meets baseline since schema has 100% description coverage, but description adds no additional context for the nested data object or doctype selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological restatement of the tool name ('Create a new document') that fails to distinguish from sibling update_document or clarify ERPNext-specific document semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus update_document or other siblings, nor preconditions for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doctype_fieldsC
Get fields list for a specific DocType
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType (e.g., Customer, Item) |
TDQS
C2.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fails to disclose what the fields list contains (metadata schema vs. values), output format, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief single fragment with no fluff, though arguably too minimal to be maximally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Barely adequate for a single-parameter tool; misses opportunity to clarify output structure or ERPNext-specific behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no parameter context, but schema has 100% coverage with examples, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action but lacks differentiation from sibling get_documents (data vs. metadata) and relies on schema for ERPNext context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus get_doctypes or get_documents, or what the fields list represents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doctypesB
Get a list of all available DocTypes
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose idempotency, side effects, or rate limits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 7 words with no filler, though overly minimal to provide usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic operation but lacks explanation of what a DocType represents or how results enable subsequent calls to get_doctype_fields/get_documents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters warrants baseline score; schema requires no additional semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (get list) and resource (DocTypes), with 'all available' distinguishing it from sibling tools that fetch specific fields or documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus siblings (e.g., when to list DocTypes vs get fields vs query documents).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentsC
Get a list of documents for a specific doctype
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType (e.g., Customer, Item) | |
| fields | No | Fields to include (optional) | |
| filters | No | Filters in the format {field: value} (optional) | |
| limit | No | Maximum number of documents to return (optional) |
TDQS
C2.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks annotations and description omits read-only nature, pagination behavior with limit parameter, or filter matching logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but undersized for tool complexity (4 parameters including nested filter objects); front-loading is moot given brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value structure given no output schema, and omits query behavior details (e.g., filter wildcard support) necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage meeting baseline; main description adds no parameter context but none is required given comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological restatement of tool name ('Get a list of documents') with minimal addition; fails to distinguish from siblings like get_doctypes or run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus alternatives like run_report for complex queries or get_doctype_fields for metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_reportC
Run an ERPNext report
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| report_name | Yes | Name of the report | |
| filters | No | Report filters (optional) |
TDQS
C2.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose return format, caching behavior, or computational 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief and front-loaded, but undersized for the complexity of nested filter objects and report execution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical operational context: output schema, filter structure guidance, valid report name patterns, and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear field descriptions; tool description adds no parameter semantics but meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Identifies the basic action and domain (ERPNext) but lacks specificity about execution behavior or report types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to prefer this over document query tools or how to select appropriate reports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_documentC
Update an existing document in ERPNext
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType (e.g., Customer, Item) | |
| name | Yes | Document name/ID | |
| data | Yes | Document data to update |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description fails to disclose critical behaviors: partial vs full update, validation rules, or error handling for missing documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (6 words) and front-loaded, though potentially too terse given the tool's complexity and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value description (no output schema) and lacks warnings about data mutation despite nested object complexity in 'data' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage; tool description adds no parameter context beyond schema, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Update) and resource (existing document in ERPNext), with 'existing' distinguishing it from create_document sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus create_document or get_documents, nor when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3.2/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: creating documents, retrieving document lists, updating documents, getting metadata about DocTypes and their fields, and running reports. The descriptions clearly differentiate between document operations, metadata queries, and report execution.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as create_document, get_documents, and update_document. This predictability makes it easy for agents to understand and select the appropriate tool based on naming conventions.
Tool Count5/5
With 6 tools, this server is well-scoped for ERPNext operations, covering core CRUD actions (create, get, update), metadata retrieval (doctypes and fields), and reporting. Each tool earns its place without being overwhelming or insufficient for the domain.
Completeness4/5
The tool set provides strong coverage for document lifecycle (create, get, update) and metadata, with a report execution tool. A minor gap exists in the lack of a delete_document tool, which agents might need to work around, but core workflows are well-supported.
Maintenance
ActivityInactive
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceThis MCP server connects ChatGPT to ERPNext, enabling AI-powered business analytics, report generation, and document management.MIT
- AlicenseNot gradedqualityAmaintenanceMCP server that enables LLMs to interact with ERPNext/Frappe sites for document CRUD, search, reports, workflows, and analytics, respecting user permissions and logging all actions.295AGPL 3.0
- AlicenseNot gradedqualityBmaintenanceModel Context Protocol (MCP) server for ERPNext - manage timesheets, leave applications, projects, and software releases via Claude, Gemini, or any MCP-compatible AI assistant.16MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rakeshgangwar/erpnext-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server