The ERPNext MCP Server is a Model Context Protocol server that provides comprehensive API access to ERPNext, enabling AI assistants to interact with all aspects of an ERPNext instance.
Document Management (CRUD): Create, read, update, delete, and list documents across any ERPNext DocType with advanced filtering, sorting, pagination, field selection, and OR conditions. Get document counts and summary views with total counts in a single call.
Workflow Operations: Submit and cancel submittable documents like invoices, sales orders, and purchase orders.
Schema & Metadata: List all available DocTypes with optional module filtering, retrieve complete field definitions and metadata for any DocType, and search link field values with autocomplete support.
Inventory Management: Query real-time stock balances from warehouse bins, view stock ledger entries (inventory transaction history), and retrieve item prices from price lists.
Trading & Sales Operations: Convert documents through the sales/purchase cycle (e.g., Quotation → Sales Order → Delivery Note → Invoice) and check outstanding balances for customers and suppliers.
Customer & Supplier Details: Retrieve comprehensive party information including addresses, phone numbers, and contacts with alias search support.
File Management: Upload files from local paths or URLs, list files attached to documents, download files, and get file download URLs.
Reporting & Custom Methods: Execute ERPNext query reports with optional filters and call any whitelisted server-side method with custom arguments using GET or POST requests.
Flexible Integration: Works with any ERPNext instance via API keys and can be configured for MCP clients like Claude Desktop.
Provides tools to interact with an ERPNext instance via its REST API, allowing for document management (CRUD), workflow actions like submitting and cancelling documents, running query reports, inspecting schemas, and accessing specialized inventory and trading functions like stock balances and party balances.
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 MCP Server Show me the current stock balance for item 'iPhone 15' in the Main Warehouse"
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.
MCP (Model Context Protocol) server for ERPNext REST API, built with FastMCP and Python.
CRUD — List, get, create, update, delete documents
Workflow — Submit and cancel submittable documents
Reports — Run ERPNext query reports
Schema — Inspect DocType field definitions, list all DocTypes
Inventory — Stock balance, stock ledger, item prices
Trading — Document conversion (e.g. Quotation → Sales Order), party balance
Supplier/Customer — Get complete details with address, phone, contacts; supports alias search
Files — Upload, list, download files
Helpers — Link search (autocomplete), document count, generic method calls
Related MCP server: ERPNext MCP Server
Python >= 3.11
uv (recommended) or pip
ERPNext instance with API key/secret
# Clone the repo
git clone <repo-url> && cd erpnext-mcp
# Create .env file
cat > .env << 'EOF'
ERPNEXT_URL=https://your-erpnext-instance.com
ERPNEXT_API_KEY=your_api_key
ERPNEXT_API_SECRET=your_api_secret
EOF
# Install dependencies
uv syncset -a && source .env && set +a && uv run erpnext-mcpTool | Description |
| List documents with filters, sorting, pagination |
| Get a single document by name |
| Create a new document |
| Update an existing document |
| Delete a document |
| Submit a submittable document |
| Cancel a submitted document |
| Execute an ERPNext report |
| Get document count with optional filters |
| List documents with total count |
| Call any whitelisted server-side method |
| Link field autocomplete search |
| List all available DocType names |
| Get field definitions for a DocType |
| Real-time stock balance from Bin (exact item_code) |
| Stock ledger entries (exact item_code) |
| Item prices from price lists (exact item_code) |
| Fuzzy-search Item across name / item_name / item_code |
| Item master + stock + price in one call (supports keyword) |
| Document conversion (e.g. SO → DN) |
| Outstanding balance for Customer/Supplier |
| Get supplier with address, phone, contacts (supports alias search) |
| Get customer with address, phone, contacts (supports alias search) |
| Upload a local file to ERPNext (by file path) |
| Upload a file from URL |
| List files attached to a document |
| Download a file by URL |
| Get download URL for a file |
Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"erpnext": {
"command": "uv",
"args": ["--directory", "/path/to/erpnext-mcp", "run", "erpnext-mcp"],
"env": {
"ERPNEXT_URL": "https://your-erpnext-instance.com",
"ERPNEXT_API_KEY": "your_api_key",
"ERPNEXT_API_SECRET": "your_api_secret"
}
}
}
}src/erpnext_mcp/
├── server.py # MCP tool definitions (FastMCP)
├── client.py # ERPNext REST API client (httpx async)
└── types.py # Pydantic modelsMIT
Cancel a submitted document.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Document name/ID | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states 'cancel', which implies a state change, but omits details on reversibility, side effects, or permissions needed. This is insufficient for an agent to understand the full 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?
The description is a single, concise sentence with no superfluous words. It is front-loaded and efficient, earning its place by being minimal yet clear.
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 need not explain return values, but it lacks completeness in behavioral context (reversibility, preconditions). It barely meets the minimum for a tool that performs a significant state change.
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 coverage is 100%, so the schema already documents both parameters (name and doctype). The description adds no additional meaning beyond what the schema provides, hence baseline score of 3.
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 'Cancel a submitted document' clearly states the action (cancel) and the resource (document), with the qualifier 'submitted' distinguishing it from delete or update operations. It effectively differentiates from sibling tools like delete_document or submit_document.
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?
No usage guidance is provided. The description does not specify when to use this tool, such as requiring the document to be in a 'submitted' state, nor does it mention alternatives or conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new document.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | JSON string of field values, e.g. '{"customer_name": "Test", "customer_type": "Individual"}' | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'create a new document', omitting side effects, permissions, idempotency, error handling, or success criteria. This is insufficient for a mutation tool.
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, efficient sentence with no wasted words. However, it could provide more context without becoming overly verbose.
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 (2 params, no annotations, output schema available), the description lacks context about the system (ERPNext), the meaning of 'document', and the creation process. It does not enable an agent to fully understand the tool's role.
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 coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline score of 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 'Create a new document' clearly states the action and resource, but it lacks differentiation from sibling tools like update_document. It is not a tautology since it adds 'new', but it's minimal and doesn't specify the system 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?
No guidance is provided on when to use this tool versus alternatives like update_document or submit_document. The description does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a document.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Document name/ID | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description only says 'Delete a document' with no disclosure of destructive behavior, permissions, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks context; could be improved without being verbose.
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 no mention of return values or usage context, description is insufficient for an agent to understand the tool's full behavior.
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 coverage is 100% with descriptions for both parameters; description adds no additional meaning beyond schema.
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 states 'Delete a document' which is clear verb+resource, but does not differentiate from sibling 'cancel_document'.
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?
No guidance on when to use this tool vs alternatives like cancel_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file's content from ERPNext.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | The File document name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'download a file's content' without disclosing how content is returned (e.g., binary, base64), authentication needs, or read-only nature.
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?
Single sentence, no wasted words. Could be slightly more informative without harming conciseness.
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?
Simple tool with output schema, but description omits mention of file format or permissions. Sufficient but not thorough.
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 coverage is 100%, baseline 3. The description adds no additional meaning beyond the schema's parameter description 'The File document name'.
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 precisely states the action (download) and the resource (file's content from ERPNext), distinguishing it from siblings like 'get_file_url' which returns a URL.
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?
No guidance on when to use this tool versus alternatives like 'get_file_url' for obtaining a file URL without downloading content. Lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-search Item across name / item_name / item_code (OR like %keyword%).
用途：把使用者口語化的關鍵字（原廠型號、品名片段、部分代碼）解析成系統實際的
item_code。ERPNext 的 Item code 常加公司前綴（例如 CTOS-KV-N40DT），
用原廠型號 KV-N40DT 直接查 get_stock_balance 會找不到——此工具負責橋接。
建議用法：先 find_items 確認 item_code，再 get_stock_balance / get_item_price /
get_stock_ledger。或者直接用 get_item_details(keyword=...) 一次取完。
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | 可選的品牌過濾 | |
| limit | No | 最多回傳幾筆（預設 20） | |
| keyword | Yes | 搜尋關鍵字（會做 `like %keyword%` 比對 name / item_name / item_code） | |
| item_group | No | 可選的 item_group 過濾 | |
| include_disabled | No | 是否包含已停用品項（預設 False） |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only search but does not explicitly state behavioral traits like idempotency, side effects, or auth requirements. The focus is on use case rather than operational details.
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?
Front-loaded with concise English summary, followed by Chinese elaboration. Clear structure but the Chinese part is somewhat redundant for English agents. Overall efficient.
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 role in a workflow, the description provides complete context: purpose, when to use, relationship to siblings, and output schema exists. No gaps for an AI agent to select and invoke correctly.
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 coverage is 100% so baseline is 3. The description adds context about fuzzy matching and the reason for searching, but the parameter descriptions in schema already cover behavior like LIKE and defaults. Limited additional value.
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 performs fuzzy-search across name/item_name/item_code using LIKE. It explains the bridging purpose between user keywords and actual item_code, and distinguishes from other tools like get_stock_balance.
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: first use find_items to confirm item_code, then use get_stock_balance etc., or use get_item_details directly. Also explains the reason for this workflow due to ERPNext code prefixes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get document count for a DocType with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType name | |
| filters | No | Optional JSON string of filters |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions 'optional filters' without details on filter logic, pagination, or permissions. Minimal behavioral disclosure for a simple aggregate tool.
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?
Single, front-loaded sentence with no unnecessary words. Perfectly concise.
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 simplicity and presence of an output schema (not shown), the description covers the core purpose. Could mention that count is an integer or affected by permissions, but adequate for a straightforward operation.
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 coverage is 100% with descriptions for both 'doctype' and 'filters'. Description adds no additional meaning beyond the schema, meeting baseline.
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 'Get document count for a DocType with optional filters', specifying verb, resource, and scope. Distinguishes from siblings like list_documents (returns documents) and get_document (single document).
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?
Implicitly indicates use when a count is needed, but no explicit guidance on when not to use or alternatives among many sibling tools like list_doctypes or search_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete customer details including address, phone, and contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Exact customer name (e.g. "CM0001 - 正達工程股份有限公司") | |
| keyword | No | Search keyword to find customer (e.g. "正達") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions output content, not behavioral traits like read-only, authentication, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, effectively communicates core purpose.
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?
Tool is simple, output schema present, but description lacks usage context (e.g., parameter priority, mutual exclusivity). Adequate for basic use.
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 covers 100% of parameters with descriptions; description adds no extra meaning beyond summarizing output. 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?
Description clearly states verb 'Get' and resource 'customer details', lists included fields (address, phone, contacts). Distinct from siblings like get_supplier_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?
No guidance on when to use this tool versus alternatives (e.g., search_link, find_items). Does not specify scope or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get field definitions for a DocType.
| Name | Required | Description | Default |
|---|---|---|---|
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic purpose. It does not disclose read-only behavior, permissions, or any side effects, leaving the agent uninformed about operational context.
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, efficient sentence with no wasted words. It is slightly terse but adequately sized for a simple tool.
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 is complete enough for a simple tool with one parameter and an output schema. It tells the agent exactly what the tool returns (field definitions), though it could briefly note the output structure.
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 coverage is 100%, so the description adds no additional meaning beyond the parameter name and description already in 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 'Get' and the resource 'field definitions for a DocType', distinguishing it from siblings like list_doctypes (list names) and get_document (get data).
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 implies usage for retrieving metadata, but no explicit when-to-use or alternatives among siblings are mentioned. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single document by DocType and name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Document name/ID | |
| fields | No | Optional list of fields to return | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation with no side effects. However, it does not specify behavior on missing documents, error handling, or any additional behavioral traits beyond the basic retrieval.
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?
A single sentence that conveys the essential information without any superfluous words. The description is front-loaded with the verb and object.
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 low complexity and the existence of an output schema, the description is largely complete. It could briefly mention behavior when a document is not found, but overall it adequately covers the usage scope.
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 coverage is 100%, so all parameters are already described. The description adds no additional meaning beyond referencing 'DocType and name'. It reaffirms the key parameters but does not enhance understanding beyond the schema.
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 action ('Get'), resource ('a single document'), and the key identifying parameters ('by DocType and name'). It effectively distinguishes the tool from siblings like list_documents or create_document.
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?
No explicit guidance is provided on when to use this tool versus alternatives (e.g., list_documents, get_count). The purpose is inferred but not explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full download URL for a file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | The File document name (e.g. "abc123.pdf" or the hash-based name) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic function without disclosing authentication needs, whether the URL is temporary, or any side effects. The output schema exists but the description does not elaborate on behavior.
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 sentence with no unnecessary words. It is front-loaded and efficiently conveys the core purpose.
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 an output schema, the description is minimal. It lacks context about output format, expiration, or relation to sibling tools like `download_file`. Adequate but has 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 100%, so baseline is 3. The tool description itself adds no parameter information beyond what the schema provides (which includes an example). No extra semantic value is contributed.
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 'Get the full download URL for a file' clearly states the action and resource. It uses a specific verb and object, but does not explicitly distinguish from sibling tools like `download_file`, which may also involve URLs. Hence a slight deduction.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., `download_file`, `upload_file_from_url`). There is no mention of prerequisites, contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full item info (master + stock balance + prices) by exact name or fuzzy keyword.
一次回完整資料，避免 AI 為了查一個品項要連打 3~4 支工具。 解析順序：
若提供 name → 直接 get
若提供 keyword → 先試精確 name；找不到 fallback find_items 取第 1 筆候選
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 精確 Item name/item_code（例如 "CTOS-KV-N40DT"） | |
| keyword | No | 模糊關鍵字（例如 "KV-N40DT"）；name 沒命中時用 | |
| warehouse | No | 可選的倉庫過濾（套用在 stock balance） | |
| price_list | No | 可選的價單過濾（套用在 prices） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the resolution logic and that it combines multiple data sources. However, it does not disclose potential side effects, authentication requirements, rate limits, or behavior when no parameters are provided or when lookup fails.
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: two sentences plus a bullet list. Information is front-loaded with the core purpose. The bullet list for resolution order is well-structured. A minor inefficiency is the use of Chinese alongside English, but overall it 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?
Given the high schema coverage and existence of an output schema (so return values are documented), the description adequately covers the composite logic and usage context. However, it lacks guidance on error handling or what happens when both name and keyword are absent.
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 coverage is 100%, baseline 3. The description adds significant value by explaining the resolution order for name and keyword, the fallback mechanism, and providing examples in parameter descriptions (e.g., 'CTOS-KV-N40DT'). This goes beyond what the schema alone provides.
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 that the tool gets full item info (master, stock balance, prices) by exact name or fuzzy keyword. It distinguishes from siblings like find_items and get_stock_balance, which are more specialized. The verb 'Get' and resource 'item details' are specific.
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 resolution order: if name given, direct get; if keyword given, try exact name then fallback to find_items. It implies when to use each parameter. However, it does not explicitly state when not to use this tool or name alternative tools for partial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get item prices from Item Price records (exact match on item_code).
⚠️ 對 item_code 做精確比對；空結果可能是 item_code 不存在或無價單。
不確定品項代碼時，先用 find_items(keyword=...) 找正確的 item_code。
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | Yes | Item code to look up (exact match) | |
| price_list | No | Optional price list name to filter (e.g. "Standard Selling") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read behavior and exact match semantics, plus a caveat about empty results. Lacks details on permissions or response format, but output schema covers return values. Good transparency for a simple read tool.
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?
Extremely concise: two sentences plus a warning. Front-loaded with purpose and immediate usage context. No redundant words, every sentence adds value.
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 and high schema coverage, the description is nearly complete for a simple item price lookup. Includes a useful caveat about empty results. Minor omission: no explicit mention that it only returns a single record or multiple, but schema and name imply list. Overall sufficient.
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 100%, so schema already documents both parameters adequately. Description adds no extra semantic value beyond the schema, as the exact match and optional price list are already defined. Baseline score of 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?
Description clearly states 'Get item prices from Item Price records' with specific resource and verb. Emphasizes exact match on item_code, distinguishing it from fuzzy search tools like find_items. Leaves no ambiguity about what the tool does.
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 warns that exact match may return empty results and suggests using find_items if item_code is uncertain. This provides clear when-to-use and when-not-to-use guidance, directly aiding agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of documents along with total count.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Fields to return | |
| doctype | Yes | ERPNext DocType name | |
| filters | No | Optional JSON string of filters | |
| order_by | No | Sort expression | |
| limit_page_length | No | Number of records |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the main action, omitting details like pagination behavior, required permissions, or that the tool is read-only. A simple 'Get a list' does not convey whether it mutates data or has rate 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?
A single sentence front-loads the core purpose ('Get a list of documents along with total count') with no unnecessary words. Every word contributes value.
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, the description does not need to detail return values. However, it could mention that the limit_page_length parameter controls pagination. For a simple list tool, it is mostly complete.
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?
All 5 parameters have descriptions in the input schema (100% coverage). The description adds no additional meaning beyond what the schema provides, so baseline of 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 'Get a list of documents along with total count' clearly states the verb (get), the resource (list of documents), and the unique feature (total count). This distinguishes it from sibling tools like list_documents (likely returns list without count) and get_count (returns only count).
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?
No explicit guidance on when to use this tool versus alternatives such as list_documents or get_count. The description implies usage when both list and count are needed, but lacks when-not-to-use or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get outstanding balance for a Customer or Supplier.
| Name | Required | Description | Default |
|---|---|---|---|
| party | Yes | Party name/ID | |
| party_type | Yes | "Customer" or "Supplier" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states what the tool does, but discloses no behavioral traits such as authentication needs, return 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded. No unnecessary words, though it is very brief.
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 output schema and minimal annotations, the description lacks detail on return value, error scenarios, or format of party parameter. Incomplete for an AI agent to reliably invoke correctly.
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 coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond the schema (e.g., restates party_type values). Baseline score of 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?
Description clearly states the verb 'Get' and resource 'outstanding balance' for a Customer or Supplier. It distinguishes from sibling tools like get_customer_details and get_supplier_details by focusing specifically on balance.
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?
No guidance on when to use this tool versus alternatives. Does not mention scenarios where it's appropriate or not, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time stock balance from Bin (exact match on item_code).
⚠️ 此工具對 item_code 做精確比對。回傳空陣列代表「找不到對應 Bin 紀錄」，
可能是真的零庫存，也可能是 item_code 拼錯或缺少公司前綴（例如系統實際是
CTOS-KV-N40DT 而你只查了 KV-N40DT）。若回傳空陣列，請改用
find_items(keyword=...) 或 get_item_details(keyword=...) 模糊確認。
| Name | Required | Description | Default |
|---|---|---|---|
| item_code | No | Optional exact item code to filter | |
| warehouse | No | Optional warehouse to filter |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses exact match behavior, empty array return meaning, and common pitfalls (typo, missing prefix). Could mention if read-only, but otherwise strong.
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?
Front-loaded with purpose, second paragraph adds valuable warnings. Could be slightly more concise, but every sentence is informative.
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 output schema exists and tool is simple, description covers what to expect, how to interpret empty results, and error scenarios. Complete for its purpose.
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 coverage is 100%, baseline 3. Description adds value by clarifying that item_code is exact match, which goes beyond schema description. Warehouse is straightforward.
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 'Get real-time stock balance from Bin (exact match on item_code)'. Specific verb and resource, distinguishing it from siblings like find_items or get_stock_ledger.
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 explains when to use (exact match) and provides alternatives for empty results: use find_items or get_item_details for fuzzy search. Good guidance on handling misinterpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock ledger entries (inventory transaction history; exact match on item_code).
⚠️ 對 item_code 做精確比對；查不到時改用 find_items(keyword=...) 找正確代碼。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max records to return (default 50) | |
| item_code | No | Optional exact item code filter | |
| warehouse | No | Optional warehouse filter |
| Name | Required | Description |
|---|---|---|
| result | 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 discloses exact match behavior and a fallback suggestion, but does not mention whether it is read-only, any ordering, or other side effects. With output schema present, basic behavior is covered but could be more explicit.
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 short and front-loaded with the key purpose in English, followed by a critical usage hint in Chinese. It is concise without being terse, though the multilanguage structure could be more organized.
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 (context indicates 'has output schema: true'), the description need not detail return values. It covers core purpose, exact match requirement, and a fallback tool. Minor omissions like pagination order or safety are forgivable 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 coverage is 100% with descriptions for each parameter (e.g., limit default 50, item_code optional exact filter). The description adds beyond schema by emphasizing exact match on item_code and advising use of find_items if no match, adding practical semantics.
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 'Get' and resource 'stock ledger entries' with explicit context 'inventory transaction history' and 'exact match on item_code'. It distinguishes from siblings like find_items and get_stock_balance by emphasizing exact matching and the fallback advice.
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 clear guidance: use exact match on item_code, and if not found, switch to find_items. However, it does not explicitly differentiate from other siblings like get_stock_balance, though the transaction history scope is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete supplier details including address, phone, and contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Exact supplier name (e.g. "SF0009-2 - 永心企業社") | |
| keyword | No | Search keyword to find supplier (e.g. "永心", "健保局") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not disclose authentication needs, error behavior, or limitations. The description does not clarify if the tool supports partial matches or what happens when multiple suppliers are found.
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?
A single sentence front-loaded with the verb and object. Every word is necessary and no redundant information. Excellent conciseness.
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 simple nature (2 optional params, output schema exists), the description is minimally complete. It hints at return fields but does not explain search behavior or edge cases. Without output schema content, the description could benefit from clarifying that the tool can search by name or keyword.
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 covers 100% of parameters with descriptions and examples. The description adds context about returned fields but does not clarify parameter interaction (e.g., exclusivity or precedence). Baseline 3 is appropriate as the description adds minimal value beyond the schema.
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 'Get complete supplier details' with specific fields (address, phone, contacts). The verb+resource is clear, and the name differentiates it from sibling tools like get_customer_details. However, it does not explicitly distinguish from other get_*_details tools.
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?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it provide context for choosing between name and keyword parameters. The description is generic and lacks usage protocol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available DocType names.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 100) | |
| module | No | Optional module filter (e.g. "Selling", "Stock", "Accounts") | |
| is_submittable | No | Optional filter for submittable doctypes only |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits beyond listing (e.g., performance, side effects, authentication needs). The read-only nature is not confirmed, leaving uncertainty.
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 sentence that immediately conveys the purpose with no extraneous words. It is optimally front-loaded and concise.
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 simplicity and the presence of an output schema, the description is minimally complete. It does not mention filtering capabilities or output structure, but the schema and context signals compensate partially.
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 coverage is 100% with each parameter having a description. The tool description adds no additional meaning beyond the schema, meeting the baseline for high 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 uses a specific verb 'List' and clearly identifies the resource as 'DocType names'. It distinctly separates this tool from sibling tools like 'list_documents' which list documents, not doctypes.
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 states what the tool does but provides no guidance on when to use it versus alternatives, such as filtered listing via 'list_documents' or other operations. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents of a given DocType with optional filtering, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | List of field names to return. Defaults to ["name"]. | |
| doctype | Yes | ERPNext DocType name (e.g. "Sales Order", "Customer") | |
| filters | No | JSON string of filters, e.g. '{"status": "Open"}' or '[["status","=","Open"]]' | |
| order_by | No | Sort expression, e.g. "creation desc" | |
| or_filters | No | JSON string of OR filters | |
| limit_start | No | Pagination offset | |
| limit_page_length | No | Number of records to return (max 100) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or authorization needs. The description carries the full burden but only states the basic operation without behavioral context.
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 sentence of 12 words, concise and front-loaded. However, it could include a bit more context without sacrificing conciseness.
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 moderate complexity (7 parameters, 1 required) and the existence of an output schema, the description is adequate but minimal. It does not explain that this is a base listing tool or how pagination works beyond the schema.
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 input schema has 100% coverage with descriptions for each parameter, so the baseline is 3. The description adds high-level mention of 'filtering, sorting and pagination' but does not add deeper meaning beyond the schema's parameter descriptions.
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 explicitly states 'List documents of a given DocType' with optional filtering, sorting, and pagination. It clearly identifies the verb (list) and resource (documents by DocType), distinguishing it from sibling tools like create_document or delete_document.
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 no guidance on when to use this tool versus siblings like get_list_with_summary or get_document. It does not mention any prerequisites, limitations, or preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in ERPNext, optionally filtered by attachment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of files to return (default 20) | |
| is_private | No | Filter by privacy (True=private, False=public, None=all) | |
| attached_to_name | No | Filter by document name (e.g. "PROJ-0001") | |
| attached_to_doctype | No | Filter by DocType (e.g. "Project", "Item") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or pagination. It only states it lists files with optional filters, missing safety or performance details.
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?
Single sentence, efficient and front-loaded. No wasted words, though it could benefit from separating main action and filters 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?
Despite having an output schema, the description is too minimal. It omits mention of pagination via limit, return format, or how filtering by attachment works, leaving room for ambiguity.
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?
All parameters have descriptions in the schema (100% coverage). The description adds no extra meaning beyond what the schema already provides, so baseline score of 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 action (list) and resource (files), and mentions optional filtering. It distinguishes from sibling tools like list_documents which lists documents, not files.
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?
No guidance on when to use this tool versus alternatives such as download_file or list_documents. The description only specifies what it does, not the context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new document mapped from an existing one (document conversion).
Common methods:
erpnext.selling.doctype.quotation.quotation.make_sales_order (Quotation → Sales Order)
erpnext.selling.doctype.sales_order.sales_order.make_delivery_note (Sales Order → Delivery Note)
erpnext.selling.doctype.sales_order.sales_order.make_sales_invoice (Sales Order → Sales Invoice)
erpnext.stock.doctype.delivery_note.delivery_note.make_sales_invoice (Delivery Note → Sales Invoice)
erpnext.buying.doctype.purchase_order.purchase_order.make_purchase_receipt (PO → Purchase Receipt)
erpnext.buying.doctype.purchase_order.purchase_order.make_purchase_invoice (PO → Purchase Invoice)
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Dotted path of the mapping method | |
| source_name | Yes | Name/ID of the source document |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the operation is destructive, requires specific permissions, or has side effects. The output schema exists but is not described, leaving the agent without information on what the tool returns.
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 and front-loaded with a clear statement of purpose followed by examples. However, the list of methods could be considered verbose for an agent; a reference to ERPNext documentation might suffice.
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 there is an output schema, the description does not need to explain return values, but it lacks information about error handling, required permissions, or prerequisites. The list of methods provides context but not completeness.
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 input schema has 100% coverage with descriptions for both parameters ('method' and 'source_name'). The description does not add extra meaning beyond the schema, so it meets the baseline of 3.
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 that the tool creates a new document mapped from an existing one (document conversion), using a specific verb and resource. However, it does not differentiate itself from the sibling tool 'create_document', which also creates documents, leading to potential ambiguity.
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?
No explicit guidance is provided on when to use this tool versus alternatives like 'create_document' or 'run_method'. The description lists common mapping methods but does not explain prerequisites, error conditions, or when each method is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call a server-side method (whitelisted API).
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Optional JSON string of keyword arguments | |
| method | Yes | Dotted method path, e.g. "frappe.client.get_list" or "erpnext.selling.doctype.sales_order.sales_order.make_delivery_note" | |
| http_method | No | GET or POST (default POST) | POST |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Call a server-side method' without disclosing side effects, permissions, error behavior, or destructive potential. For a method invocation tool, this is a significant gap.
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?
Single sentence of 8 words is concise and front-loaded. Could be more informative without sacrificing brevity.
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?
Tool can invoke arbitrary methods with no output schema or error handling description. Given complexity, description is insufficient for safe and correct usage.
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 covers all three parameters with descriptions (100% coverage). Description adds 'whitelisted API' context but no additional parameter details. Schema already explains method format and defaults.
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 states 'Call a server-side method (whitelisted API)', clearly indicating the action and resource. It distinguishes from sibling CRUD tools by focusing on arbitrary method invocation, though 'whitelisted API' is vague.
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?
No guidance on when to use this tool vs alternatives like run_report or document-specific tools. Agent must infer from context that this is for non-CRUD methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an ERPNext report.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Optional JSON string of report filters | |
| report_name | Yes | Name of the report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Execute an ERPNext report.' It does not indicate whether the tool is read-only or destructive, what it returns, or any permissions or side effects. This is insufficient for an agent to understand the tool's behavior.
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 short sentence, which is concise but lacks structure. It does not front-load key information or provide any additional details beyond the minimal meaning.
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 has two parameters, no output schema, and no annotations, the description is critically incomplete. It fails to explain what executing a report produces, any output format, or side effects, leaving the agent with insufficient context to use the tool effectively.
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 100%, with both parameters already documented in the input schema (e.g., 'Name of the report' and 'Optional JSON string of report filters'). The description adds no additional semantics beyond the schema, meeting the baseline for high 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 uses a specific verb-resource pair: 'Execute an ERPNext report.' The tool's name and description clearly indicate it runs a report, distinguishing it from siblings that create, delete, or list documents. However, it does not differentiate from 'run_method,' which might also execute actions.
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?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives like 'get_list_with_summary' or 'run_method,' nor does it mention prerequisites or context for execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for link field values (autocomplete).
| Name | Required | Description | Default |
|---|---|---|---|
| txt | Yes | Search text | |
| doctype | Yes | DocType to search in | |
| filters | No | Optional JSON string of filters | |
| page_length | No | Max results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'search' and 'autocomplete', which gives minimal behavioral insight. It does not disclose what the tool returns (e.g., list of values, documents), any limitations, or side effects. No annotations are present to supplement.
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 short sentence, which is concise but too brief to convey necessary detail. It is not verbose, but could be restructured to include more context without being wordy.
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 has four parameters and an output schema, and there are many sibling tools (27), the description is insufficient. It does not explain the tool's purpose relative to others or what the output looks like, leaving agents underinformed.
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?
All four parameters are fully described in the input schema with clear descriptions, so the description adds little extra value. The baseline of 3 is appropriate given high schema 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 clearly states it searches for link field values and mentions autocomplete, which identifies its specialized role. However, it does not distinguish itself from sibling tools like 'find_items' that may also perform searches.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a submittable document (e.g. Sales Invoice).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Document name/ID | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic action. It fails to mention side effects like workflow triggers or permission requirements. Since no annotations are provided, the description carries the full burden but is insufficient.
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 extremely concise: one sentence front-loading the core action. No redundant or 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?
Given the output schema exists, return values are covered. However, the description lacks usage context and behavioral detail, making it minimally complete for such a simple tool. It could benefit from including when to submit versus other document actions.
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?
Input schema covers both parameters with descriptions. The description adds 'submittable' context but does not elaborate on parameter values or formats. Schema coverage is 100%, so baseline is 3.
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 'Submit' and the resource 'submittable document' with an example (Sales Invoice). It distinguishes itself from sibling tools like create, update, or cancel, which have different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain whether this tool should be used after create or before cancel, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing document.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | JSON string of fields to update | |
| name | Yes | Document name/ID | |
| doctype | Yes | ERPNext DocType name |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states it updates a document, without disclosing behavioral traits like required permissions, reversibility, or error handling.
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 very concise with one sentence, but it lacks sufficient detail and context to be optimally useful.
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?
Despite having an output schema and full parameter coverage, the description does not mention that the document must exist, the format of the data parameter, or any operational constraints, making it incomplete for a tool with many siblings.
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 descriptions cover all parameters (100% coverage), so the description adds no additional meaning beyond the schema.
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 'Update' and resource 'document', distinguishing it from create, delete, and other sibling tools.
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?
No explicit guidance on when to use vs. alternatives like cancel or submit. The description implies updating, but lacks context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file to ERPNext.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Optional name for the uploaded file (defaults to original filename) | |
| file_path | Yes | Local file path to upload (e.g. "/mnt/nas/files/report.pdf") | |
| is_private | No | Whether file should be private (default True) | |
| attached_to_name | No | Optional document name to attach file to (e.g. "PROJ-0001") | |
| attached_to_doctype | No | Optional DocType to attach file to (e.g. "Project", "Item") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must entirely convey behavioral traits. It only states the action without disclosing file size limits, authorization needs, overwrite behavior, success/failure outcomes, or any side effects. This is a critical gap.
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 extremely concise with a single sentence, but it lacks necessary depth. Important information is omitted, making it under-specified rather than efficiently compact.
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 5 parameters, no annotations, and an output schema, the description is severely incomplete. It fails to explain return values, error handling, or how parameters interact, leaving the agent with insufficient 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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, failing to clarify parameter relationships or usage tips.
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 'Upload a local file to ERPNext', specifying the verb and resource. It distinguishes from the sibling tool 'upload_file_from_url' by emphasizing 'local file', but lacks specifics about the outcome or constraints.
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?
No guidance is provided on when to use this tool versus alternatives like 'upload_file_from_url'. The description does not mention prerequisites, typical use cases, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to ERPNext from a URL.
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | Source URL to fetch the file from | |
| filename | No | Optional name for the file (will be inferred from URL if not provided) | |
| is_private | No | Whether file should be private (default True) | |
| attached_to_name | No | Optional document name to attach file to | |
| attached_to_doctype | No | Optional DocType to attach file to |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose any behavioral traits such as overwriting behavior, authentication needs, rate limits, or error handling, leaving significant gaps.
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?
Single sentence, no wasted words, efficiently communicates the core action. Appropriate length for a simple tool.
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 and good parameter descriptions, the description is adequate. However, it lacks context on error handling, URL accessibility requirements, and file size limits.
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 coverage is 100% and each parameter has a description. The description adds no extra meaning beyond what the schema already provides, keeping it at baseline.
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 the action ('Upload a file') and the source ('from a URL'), and distinguishes from sibling tools like upload_file (likely local) and download_file.
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?
No explicit when-to-use or alternatives are mentioned. Context is implied by the name and description, but no exclusions or comparisons to siblings are provided.
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.5.0cancel_document3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / name / descriptionAdded value: +"Document name/ID"create_document3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / data / descriptionAdded value: +"JSON string of field values, e.g. '{\"customer_name\": \"Test\", \"customer_type\": \"Individual\"}'"Input schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"delete_document3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / name / descriptionAdded value: +"Document name/ID"download_filefind_itemsget_count3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / filters / descriptionAdded value: +"Optional JSON string of filters"get_customer_detailsget_doctype_meta2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"get_document4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / fields / descriptionAdded value: +"Optional list of fields to return"Input schema / properties / name / descriptionAdded value: +"Document name/ID"get_file_urlget_item_detailsget_item_price3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / item_code / descriptionAdded value: +"Item code to look up (exact match)"Input schema / properties / price_list / descriptionAdded value: +"Optional price list name to filter (e.g. \"Standard Selling\")"get_list_with_summary6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / fields / descriptionAdded value: +"Fields to return"Input schema / properties / filters / descriptionAdded value: +"Optional JSON string of filters"Input schema / properties / limit_page_length / descriptionAdded value: +"Number of records"Input schema / properties / order_by / descriptionAdded value: +"Sort expression"get_party_balance3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / party / descriptionAdded value: +"Party name/ID"Input schema / properties / party_type / descriptionAdded value: +"\"Customer\" or \"Supplier\""get_stock_balance3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / item_code / descriptionAdded value: +"Optional exact item code to filter"Input schema / properties / warehouse / descriptionAdded value: +"Optional warehouse to filter"get_stock_ledger4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / item_code / descriptionAdded value: +"Optional exact item code filter"Input schema / properties / limit / descriptionAdded value: +"Max records to return (default 50)"Input schema / properties / warehouse / descriptionAdded value: +"Optional warehouse filter"get_supplier_detailslist_doctypes4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / is_submittable / descriptionAdded value: +"Optional filter for submittable doctypes only"Input schema / properties / limit / descriptionAdded value: +"Max results (default 100)"Input schema / properties / module / descriptionAdded value: +"Optional module filter (e.g. \"Selling\", \"Stock\", \"Accounts\")"list_documents8 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name (e.g. \"Sales Order\", \"Customer\")"Input schema / properties / fields / descriptionAdded value: +"List of field names to return. Defaults to [\"name\"]."Input schema / properties / filters / descriptionAdded value: +"JSON string of filters, e.g. '{\"status\": \"Open\"}' or '[[\"status\",\"=\",\"Open\"]]'"Input schema / properties / limit_page_length / descriptionAdded value: +"Number of records to return (max 100)"Input schema / properties / limit_start / descriptionAdded value: +"Pagination offset"Input schema / properties / or_filters / descriptionAdded value: +"JSON string of OR filters"Input schema / properties / order_by / descriptionAdded value: +"Sort expression, e.g. \"creation desc\""list_filesmake_mapped_doc3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / method / descriptionAdded value: +"Dotted path of the mapping method"Input schema / properties / source_name / descriptionAdded value: +"Name/ID of the source document"run_method4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / args / descriptionAdded value: +"Optional JSON string of keyword arguments"Input schema / properties / http_method / descriptionAdded value: +"GET or POST (default POST)"Input schema / properties / method / descriptionAdded value: +"Dotted method path, e.g. \"frappe.client.get_list\" or \"erpnext.selling.doctype.sales_order.sales_order.make_delivery_note\""run_report3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / filters / descriptionAdded value: +"Optional JSON string of report filters"Input schema / properties / report_name / descriptionAdded value: +"Name of the report"search_link5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"DocType to search in"Input schema / properties / filters / descriptionAdded value: +"Optional JSON string of filters"Input schema / properties / page_length / descriptionAdded value: +"Max results"Input schema / properties / txt / descriptionAdded value: +"Search text"submit_document3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / name / descriptionAdded value: +"Document name/ID"update_document4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / data / descriptionAdded value: +"JSON string of fields to update"Input schema / properties / doctype / descriptionAdded value: +"ERPNext DocType name"Input schema / properties / name / descriptionAdded value: +"Document name/ID"upload_fileupload_file_from_urlv0.1.0cancel_documentcreate_documentdelete_documentget_countget_doctype_metaget_documentget_item_priceget_list_with_summaryget_party_balanceget_stock_balanceget_stock_ledgerlist_doctypeslist_documentsmake_mapped_docrun_methodrun_reportsearch_linksubmit_documentupdate_documentMost tools have distinct purposes, but there is slight overlap among item-related tools (find_items, get_item_details, get_stock_balance, get_stock_ledger). Descriptions are detailed, so agents can differentiate with careful reading.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_document, get_stock_balance, list_documents). No mixing of conventions.
28 tools is slightly above the typical range but justified by the breadth of ERP functionality covered. Each tool addresses a specific need, so the count is appropriate for the domain.
The tool surface comprehensively covers document CRUD, submission, cancellation, listing, search, reporting, file handling, and key ERP objects (items, customers, suppliers, stock, pricing, document conversion). No obvious gaps for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
Malaysian SME accounting, e-Invoice and payroll for your AI. 63 tools; writes are approved drafts.
Odoo ERP for AI agents: hosted OAuth endpoint, gated writes, one endpoint for every instance.
Official Akeda ERP connector for tasks, CRM, chats, documents, finance and operations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yazelin/erpnext-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
