Skip to main content
Glama

Repartir dinero sin perder centavos

money-allocate
Read-onlyIdempotent

Divide un monto en partes (por proporciones o iguales) en unidades menores, sin perder centavos: la suma siempre cuadra. Cuándo: un cálculo de dinero, impuestos o matemática financiera tiene que ser exacto y reproducible (redondeo, centavos, tasas). No para: dividir una cuenta entre personas con propina opcional y redondeo de cada parte (bill-split). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Splits an amount into parts by ratios or equally, in integer minor units using the largest-remainder method so the parts always add up exactly to the total. When: a money, tax or financial-math result has to be exact and reproducible (rounding, cents, rates). Not for: splitting a bill among people with an optional tip % (bill-split). Side effects: none (read-only, no network access, no stored state). [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
partsNoEqual parts when no ratios (integer; optional; min 1; max 1000).
amountYesTotal amount (number; required; min 0; max 10000000000000).
ratiosNoRatios (e.g. [50, 30, 20]); omit with parts for equal split (array of number; optional; at least 1 items; up to 1000 items).
currencyNoISO 4217 currency code (string; optional; default "USD"; pattern ^[A-Za-z]{3}$).USD

Output Schema

NameRequiredDescriptionDefault
totalNo
allocationsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / amount / examples
      Added value: +[
      +  100
      +]
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Splits an amount into parts by ratios or equally, in integer minor units using the largest-remainder method so the parts always add up exactly to the total. When: a money, tax or financial-math result has to be exact and reproducible (rounding, cents, rates). Not for: splitting a bill among people with an optional tip % (bill-split). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld=false/idempotent/non-destructive, and the description corroborates rather than contradicts them while adding real context: no network, no stored state, deterministic same-input-same-output, and hard operational limits (64 KB input, 1 s per call, 1 MB result). The largest-remainder disclosure also tells the agent how rounding is resolved.

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 the core action and invariant, then cleanly labelled sections (Cuándo / No para / Efectos / Determinista / Límites), so an agent can stop early. It loses a point because the Spanish and English blocks restate the same content, roughly doubling length without adding new information.

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?

With an output schema present, annotations covering the safety profile, and full schema coverage, the description still supplies everything else an agent needs: purpose, exclusion routing, determinism, side-effect profile and resource limits. No meaningful gap remains for a 4-parameter read-only calculator.

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 all four parameters (amount, parts, ratios, currency) are already documented with types, bounds and defaults; baseline is 3. The description adds the 'integer minor units' framing and the ratios-vs-equal split behavior, but does not clarify edge semantics the schema leaves implicit, e.g. what happens if both parts and ratios are supplied.

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 verb+resource ('Divide un monto en partes'), the two modes (proporciones o iguales), the unit (unidades menores) and the algorithm (largest-remainder), plus the invariant that the sum always matches. It also explicitly names the sibling it is NOT (bill-split), so an agent can discriminate without opening either schema.

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?

Provides an explicit 'Cuándo' clause (exact, reproducible money/tax/financial-math results with rounding, cents, rates) and an explicit 'No para' clause routing to bill-split with the distinguishing condition (optional tip %, per-person rounding). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources