Skip to main content
Glama
ppiotis

Xero Practice Aggregator MCP

by ppiotis

Client health score

client_health
Read-onlyIdempotent

Score each client's financial health from 0 to 100 using transparent rules like receivables, payroll coverage, and DSO to flag healthy, watch, or at-risk accounts.

Instructions

0-100 health score per client from transparent rules (each rule and its points is listed): 90+ day receivables share, payroll coverage, expense spike (z-score of latest month vs trailing months), growing director loan, DSO, unreconciled items, falling income. >=80 healthy, 60-79 watch, <60 at risk. Omit org for all clients.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orgNoClient org: tenant id or (part of) the organisation name, e.g. 'Northwind'.
as_ofNoReport date (YYYY-MM-DD). Defaults to today (demo mode: 2026-09-30).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this read-only, idempotent and non-destructive, so safety needs no restating. The description adds genuinely useful behavioral context beyond that: the score is built from transparent rules with per-rule points listed, and the omit-org behavior fans out to all clients. Not a 5 because no output shape or volume of returned clients is indicated.

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?

One dense but well-ordered paragraph: score definition first, then the rule inputs, then the band thresholds, then the omit-org behavior. Every clause carries information, though the rule list reads as a run-on.

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

Completeness4/5

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

A two-parameter read tool with 100% schema coverage and no output schema: the description is complete enough to call correctly, explaining the metric composition and all-client behavior. Minor gap is the absence of return-shape detail, which is more tolerable for a scoring tool with stated bands.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents org ('tenant id or part of organisation name') and as_of (YYYY-MM-DD, defaults today). The description's 'Omit org for all clients' is useful secondary context but largely overlaps the schema, so baseline 3 applies.

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?

States a specific artifact, a 0-100 health score per client, and enumerates the exact inputs driving it (receivables share, payroll coverage, expense spike z-score, director loan, DSO, unreconciled items, falling income). Distinct from siblings like payroll_risk or overdue_invoices, which cover only single signals.

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

Usage Guidelines3/5

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

The scoring bands (>=80 healthy, 60-79 watch, <60 at risk) imply interpretation, but there is no explicit when-to-use guidance and no routing to alternatives such as overdue_invoices or payroll_risk when only one signal is needed. Usage is inferable rather than stated.

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