Zovo Tip Pool Calculator

Calculate tip pool

calculate_tip_pool

Read-onlyIdempotent

Use this when the user wants a tip pool calculator: split pooled tips among restaurant, bar, cafe or salon staff by hours worked (how to split tips by hours), by points x hours, by role percentage (e.g. 70% servers, 20% bussers, 10% bar, then by hours inside each role), or equally. Accepts cash and card tips with an optional card fee percent, a staff list as objects or pasted text/CSV, and an optional week view (shift_tips plus a shift on each staff row). Returns each person's share in cents with largest-remainder rounding so shares add up to the pool, the per-hour rate, an explanation, warnings (e.g. a manager in the pool), and a printable PDF tip sheet with signature lines plus a CSV. Does not give legal advice, decide who may be in a pool, compute wages or taxes, or connect to a POS. Do not use for splitting a restaurant bill among diners.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calculate_tip_pool"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional title for the tip sheet, e.g. "Friday dinner, Oct 23" or "Week of Oct 19".
`staff`	No	Everyone sharing the pool. Array of {name, role, hours, points, shift}, or one pasted block (one person per line, CSV with a header row is fine), e.g. [{"name":"Ana","role":"server","hours":6.5},{"name":"Ben","role":"busser","hours":5}] or "Ana server 6.5\nBen busser 5".
`method`	No	How to split: "hours" (by hours worked), "points" (points x hours), "role_percent" (fixed percent per role, e.g. 70/20/10, then by hours inside each role), or "equal". Default: chosen from the data (role_percentages -> role_percent, points -> points, hours -> hours, else equal).
`shifts`	No	Alternative week view: one item per shift with its own tips and staff, e.g. [{"label":"Fri","total_tips":600,"staff":"Ana 5, Ben 5"},{"label":"Sat","total_tips":900,"staff":"Ana 6, Cara 6"}].
`currency`	No	ISO currency code, default USD, e.g. EUR, GBP, CAD.
`round_to`	No	"cent" (default) or "dollar" to pay whole dollars in cash; any coins left over are reported, not assigned.
`card_tips`	No	Credit card tips, e.g. 820.50. Optional; the card fee applies to these.
`cash_tips`	No	Cash tips, e.g. 420. Optional.
`shift_tips`	No	Week view: tips per shift, with each staff row's shift set, e.g. {"Mon":420,"Tue":385.5} or "Mon 420, Tue 385.50". Each shift is split on its own, then totals are added per person.
`total_tips`	No	Total tips to split (cash plus card), e.g. 1240.50 or "$1,240.50". Leave out when cash_tips and card_tips are given, or when shift_tips is used.
`role_points`	No	Points per role for the points method when people have no points of their own, e.g. {"server":10,"bartender":8,"busser":5}.
`card_fee_percent`	No	Card processing fee percent to deduct from card tips before splitting, e.g. 2.9. Default none.
`role_percentages`	No	Percent of the pool per role for method role_percent, e.g. {"server":70,"busser":20,"bartender":10} or "servers 70%, bussers 20%, bar 10%".

Output Schema

Name	Required	Description	Default
`note`	Yes
`pool`	Yes
`label`	Yes
`roles`	Yes
`method`	Yes
`people`	Yes
`shifts`	Yes
`currency`	Yes
`warnings`	Yes
`downloads`	Yes
`assumptions`	Yes
`explanation`	Yes
`method_label`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare this read-only, idempotent and non-destructive, but the description goes much further: it discloses largest-remainder rounding that makes shares sum to the pool, a per-hour rate, an explanation string, warnings (e.g. manager in the pool), and generated artifacts (printable PDF tip sheet with signature lines plus CSV). It also sets boundaries on scope (no wages, taxes, or POS). This is behavior an agent could not infer from the annotations.

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?

Front-loaded with "Use this when...", followed by methods, inputs, return values, and exclusions in that order — a sensible priority. Every clause carries information, though the single dense paragraph (method list, input forms, return artifacts, exclusions) would read better segmented, and the return-value sentence is partially redundant with the output schema.

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?

For a 13-parameter tool with no required fields, the definition covers the input modes (single-period, cash/card split, week view via shift_tips), the split methods, rounding and fee behavior, and explicit scope exclusions. An agent has enough to decide to call it and to assemble the right argument combination.

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 coverage is 100%, so the schema already documents every parameter, which establishes a baseline of 3. The description adds some genuine cross-parameter meaning — staff accepted as objects or pasted text/CSV, and the week view combining shift_tips with a shift field on each staff row — but it does not explain the mutual exclusivity of total_tips vs cash_tips/card_tips beyond what the schema already says.

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

Purpose4/5

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

States a concrete verb+resource ("tip pool calculator") and enumerates the four supported split methods, so the agent knows exactly what computation is performed. It also rules out a common confusion ("Do not use for splitting a restaurant bill among diners"). It loses a point only because it never names or contrasts the sibling tool calculate_tip_out, so sibling routing still requires inference.

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

Usage Guidelines4/5

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

"Use this when the user wants a tip pool calculator" plus the explicit exclusion list (no legal advice, no deciding pool membership, no wages/taxes, no POS) gives clear when/when-not guidance. The only gap is that it never points to the alternative tool for the adjacent task (tip-out calculation), so the agent has no forward route.

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

All Zovo Tip Pool Calculator tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?