ERP MCP Server

Overview Schema Source Related Servers Discussions Admin

Customer balance

get_customer_balance

Read-onlyIdempotent

Retrieve a customer's accounts receivable balance, credit limit, open and overdue invoices, and open order counts to assess credit status or prepare payment reminders.

Instructions

Get a customer's account balance (accounts receivable).

Use for "What is Oakhurst's open balance?", "Is C-0034 over its credit limit?" or before drafting a payment reminder. Returns contact details, credit limit, invoiced, paid, open and overdue amounts, each overdue invoice with days overdue, and counts of open/overdue orders.

Input Schema

Name	Required	Description	Default
`customer`	Yes	Customer code (e.g. 'C-0007') or name, full or partial (e.g. 'Oakhurst').

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 28, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While annotations handle safety hints (readOnlyHint: true), the description significantly exceeds expectations by detailing the entire return payload, including contact details, credit limit, specific amount types (invoiced, paid, open, overdue), and detailed counts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately detailed, but every sentence contributes necessary information—purpose, examples, and return structure—making the overall structure highly effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The definition is highly complete. By listing every single data point returned (from contact details to overdue invoice details), it gives the agent maximum context regarding the operation's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema coverage is 100%, the baseline score of 3 is met. The description merely reinforces the accepted formats for the customer input (code or name) which are already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The purpose is stated immediately and clearly: 'Get a customer's account balance (accounts receivable).' This is specific and easy for an agent to identify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit, real-world examples of how and when to use the tool, such as checking 'What is Oakhurst's open balance?' or determining if a customer is over credit limits.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server