ERP Chatbot is MCP server show data and documents according to database of site
Server has 10 tools with basic schemas and descriptions, but significant gaps prevent production use. Tool names follow verb_noun convention (good), but descriptions are generic and lack actionable context. Most parameters lack type constraints (enums, ranges). Output schemas are undocumented, LLMs cannot predict response structure. Error handling is minimal (generic try/catch). Destructive tools (delete_document) lack confirmation patterns. No security annotations or permission gates visible. Average description length ~120 chars (below 194 baseline); many parameters have no descriptions at all.
Create a new document in ERPNext.
Delete a document from ERPNext.
Get list of available companies to ensure correct context.
Get dashboard KPI data for a specific module.
Get a list of available DocTypes in relevant modules (Accounts, Stock, Selling, Buying, HR) to understand the schema.
Fetch a single document by name.
Fetch a list of documents for a DocType with filtering and field selection. Use this for raw data tables like 'Sales Invoice', 'Customer', 'Employee'.
Output schemas completely undocumented. All tools return TextContent with JSON string; LLMs cannot predict field structure, forcing them to parse unstructured text. Violates pattern:response-shaper.
Destructive tool (delete_document) lacks confirmation or dry-run pattern. No description warning of irreversibility. Agents can delete data without safeguards.
Parameter 'filters' in get_report_data and get_list_data accepts free-form objects with no schema or validation. LLMs cannot know valid filter keys or syntax. Should document Frappe filter format or provide enum examples.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Execute a standard ERPNext report (e.g., 'Balance Sheet', 'Profit and Loss Statement', 'Stock Balance'). Returns columns and data.
Get sales analytics data with trends.
Update an existing document in ERPNext.
Error handling is generic (catch-all try/except returning 'Error executing tool'). No recovery guidance, no categorization of retryable vs fatal errors. Violates pattern:recovery-guide.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot determine which tools are safe to retry or which modify state. Violates current MCP spec (2026-07-28).