KiotViet MCP by usefulapi

Tools map cleanly to resource+operation pairs (list/get/create) with distinct resources: customers, products, orders, invoices, purchase orders, returns, suppliers, price books, cashflow, stock. The main friction is the parallel id-vs-code variants (get_order vs get_order_by_code, get_invoice vs get_invoice_by_code) and the cluster of transaction types (orders, invoices, purchase orders, supplier orders, returns), but descriptions clarify each clearly.

Every tool follows a single predictable pattern: kiotviet_ prefix + verb_noun in snake_case (list_products, get_product, get_product_by_code, create_customer). Even the _by_code variants extend the pattern consistently with no camelCase or verb-style mixing.

29 tools is at the heavy end, and the breadth is driven by many distinct entities (branches, categories, customers, products, price books, orders, invoices, stock, cashflow, purchase orders, supplier orders, suppliers, returns, users) which justifies much of it. However the read-heavy surface with repeated list/get/get_by_code triples per entity inflates the count somewhat.

Read coverage is broad, but only two write operations exist (create_customer, create_order), and create_order explicitly does not produce an invoice or record payment. There are no update/delete tools, no product or supplier creation, no invoice creation or payment recording, and no return/purchase-order creation, leaving significant lifecycle gaps for real workflows.