Skip to main content
Glama

nestegg-calculators

Biweekly Payoff

biweekly-payoff
Read-onlyIdempotent

Biweekly mortgage acceleration: paying half the monthly payment every two weeks. Returns the biweekly payment and the months and interest saved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesLoan amount.
ratePctYesAnnual rate in percent.
termMonthsYesOriginal term in months.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
monthsSavedNoMonths saved.
interestSavedNoInterest saved.
biweeklyPaymentNoBiweekly payment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint true. The description adds the calculation method ('paying half the monthly payment every two weeks') and the return values, which is transparent for a read-only calculator. No contradictions with annotations.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the core concept, and contains no redundant information. Every word earns its place.

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?

Given the tool's simplicity (3 required params, no nested objects, output schema present), the description adequately conveys the operation, return values, and basic context. It is complete enough for an agent to select and invoke correctly.

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?

The input schema covers all three parameters with descriptions (amount, ratePct, termMonths), providing 100% coverage. The description does not add further parameter nuance beyond the biweekly payment concept, so the baseline 3 is appropriate.

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 description clearly identifies a biweekly mortgage acceleration calculator and specifies its outputs: 'Returns the biweekly payment and the months and interest saved.' It distinguishes this from sibling tools like amortization or loan-payoff by focusing on the biweekly payment strategy.

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 description states the scenario ('Biweekly mortgage acceleration') but does not explicitly discuss when to use this tool versus alternatives or any exclusions. Usage is implied from the tool's specific purpose rather than clearly delineated.

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.