EveryCalc
Server Details
Free finance calculators as MCP tools: mortgage, refinance, loans, compound interest, salary, tips. Every result links the web calculator.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP ยท MCP 2025-03-26
- URL
TDQS
Score is being calculated.
Available Tools
69 toolscalculate_401kInspect
Projected 401k balance with employee contributions capped at 24500 per year, plus an employer match, compounded annually. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive 401k calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Years to project. | |
| match_pct | Yes | Employer match percent of the matched contribution. | |
| annual_salary | Yes | Annual salary in USD. | |
| match_cap_pct | Yes | Percent of salary eligible for the employer match. | |
| current_balance | Yes | Current 401k balance in USD. | |
| contribution_pct | Yes | Employee contribution percent of salary. | |
| annual_return_pct | Yes | Annual return percent. |
calculate_act_scoreInspect
Composite, STEM, and ELA scores from the four ACT section scores, each clamped to 1 to 36 exactly as the page does. The composite is the rounded average of the four sections. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive ACT Score calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| math | Yes | Math section score, 1 to 36 (clamped and rounded as on the page). | |
| english | Yes | English section score, 1 to 36 (clamped and rounded as on the page). | |
| reading | Yes | Reading section score, 1 to 36 (clamped and rounded as on the page). | |
| science | Yes | Science section score, 1 to 36 (clamped and rounded as on the page). |
calculate_affordabilityAInspect
Maximum home price affordable from household income using the 28/36 rule. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive home affordability calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| term_years | No | Loan term in years; default 30. | |
| down_payment | No | Cash available for down payment in USD. | |
| annual_income | Yes | Gross yearly household income in USD. | |
| monthly_debts | No | Existing monthly debt payments in USD. | |
| back_ratio_pct | No | Back-end ratio percent; default 36. | |
| annual_rate_pct | Yes | Expected mortgage rate percent. | |
| front_ratio_pct | No | Front-end ratio percent; default 28. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers two useful behavioral facts: the calculation methodology and the fact that the result contains a calculator_url that must be surfaced as a clickable markdown link. It does not disclose what else the result contains or the assumptions behind the price (taxes, insurance, HOA), which is a meaningful gap for an affordability calculation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Purpose is front-loaded and the operative instruction about the calculator_url follows immediately, with the IMPORTANT flag making the mandated behavior unmissable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter calculator with full schema coverage and no output schema, the description covers purpose, method, and the key output element to surface. The remaining gap is the absence of stated assumptions (whether property tax, insurance, or HOA are included in the affordable price), which materially affects interpretation of the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description earns credit by naming the 28/36 rule, which explains the meaning of the front_ratio_pct and back_ratio_pct parameters and their defaults. It also grounds inputs in household income, framing the required annual_income field correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: the maximum home price affordable from household income, qualified by the 28/36 rule. This is clearly distinct from calculate_mortgage (payment sizing) and calculate_car_affordability, though the description does not explicitly name a sibling or state the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the opening purpose statement; there is no explicit when-to-use versus alternatives guidance (e.g., versus calculate_rent_vs_buy or calculate_mortgage). The bolded IMPORTANT instruction is about presenting results, not about selecting this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_aftInspect
Scores all five AFT events (deadlift, hand-release push-ups, sprint-drag-carry, plank, 2-mile run) from 0 to 100 each using the 17-21 anchor tables, for a 500-point total. Combat MOS scoring is sex-neutral and requires 350 total with every event at 60 or above; the general standard requires every event at 60 or above. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive AFT calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Sex for the scoring tables (ignored for combat, which is sex-neutral). | |
| push_ups | Yes | Hand-release push-up repetitions in 2 minutes. | |
| run_time | Yes | 2-mile run time as m:ss (or total seconds). | |
| standard | No | Scoring standard: general or combat MOS. | |
| plank_time | Yes | Plank hold time as m:ss (or total seconds). | |
| deadlift_lbs | Yes | 3-rep max deadlift weight in pounds. | |
| sprint_drag_carry_time | Yes | Sprint-drag-carry time as m:ss (or total seconds). |
calculate_ageInspect
Exact age from a birth date to a target date, broken into years, months, and days, plus total days lived, total hours lived, the weekday of birth, and days until the next birthday. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive age calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| birth_date | Yes | Date of birth in YYYY-MM-DD format. | |
| target_date | No | Date to calculate the age as of, in YYYY-MM-DD format. If omitted, today is used, matching the page. |
calculate_ap_exam_scoreInspect
Predicted AP score from 1 to 5 using the page bands on the weighted composite percent: multiple choice and free response contributions are weighted by the exam split, then banded at 70, 55, 40, and 25 percent. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive AP Exam Score calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| mc_total | Yes | Total multiple choice questions. | |
| frq_total | Yes | Total free response points possible. | |
| frq_earned | Yes | Free response points earned. | |
| mc_correct | Yes | Multiple choice questions answered correctly. | |
| mc_weight_pct | No | Multiple choice weight percent for the exam (the page presets are 50, 40, 45, and 60 depending on the exam); default 50. |
calculate_arm_vs_fixedInspect
Worst case adjustable rate mortgage simulation with rate caps, compared with a fixed rate loan on total interest, payments, and the breakeven year. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive arm vs fixed calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| term_years | No | Loan term in years; default 30. | |
| loan_amount | Yes | Loan amount in USD. | |
| fixed_rate_pct | Yes | Fixed rate annual percent. | |
| initial_cap_pct | Yes | First adjustment cap in percentage points. | |
| lifetime_cap_pct | Yes | Lifetime cap above the start rate in percentage points. | |
| periodic_cap_pct | Yes | Cap per later adjustment in percentage points. | |
| arm_start_rate_pct | Yes | ARM starting annual percent. | |
| fixed_period_years | Yes | Years before the ARM first adjusts. | |
| fully_indexed_rate_pct | Yes | Fully indexed annual percent the ARM can adjust toward. |
calculate_auto_loanInspect
Monthly payment, amount financed, total interest, and total cost of a car for an auto loan after down payment and trade-in value are subtracted from the vehicle price. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive auto loan calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Vehicle price in USD. | |
| trade_in | No | Trade-in value in USD. | |
| term_years | Yes | Loan term in years. | |
| down_payment | No | Down payment in USD. | |
| annual_rate_pct | Yes | Annual rate percent, e.g. 6.5. | |
| include_schedule | No | Set to true to include the yearly amortization schedule. |
calculate_bahInspect
Monthly Basic Allowance for Housing from the 2026 RC/Transient baseline rate table by pay grade, with or without dependents, plus the annualized amount. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive BAH calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| pay_grade | Yes | Pay grade, e.g. E-5 or O-3. O-7+ covers O-7 to O-10. | |
| dependents | No | Whether the rate is with or without dependents. |
calculate_biweekly_mortgageInspect
Interest and time saved by paying half the monthly mortgage payment every two weeks instead of monthly. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive biweekly mortgage calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | Yes | Current mortgage balance in USD. | |
| term_years | No | Remaining term in years; default 30. | |
| annual_rate_pct | Yes | Annual rate percent. | |
| current_monthly_payment | No | Current monthly principal and interest payment in USD; leave at 0 to compute it from balance, rate, and term. |
calculate_bmi_tdeeInspect
Body mass index and category, Mifflin-St Jeor basal metabolic rate, total daily energy expenditure, and cut and bulk calorie targets. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive bmi and tdee calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | No | Sex used by the BMR formula: m or f. | |
| age_years | Yes | Age in years. | |
| height_cm | Yes | Height in centimeters. | |
| weight_kg | Yes | Weight in kilograms. | |
| activity_factor | No | Activity multiplier, for example 1.2 sedentary, 1.55 moderately active, 1.9 extremely active; default 1.55. |
calculate_brs_vs_high3Inspect
Pension-only comparison of the legacy High-3 system (2.5 percent per year of service) against the Blended Retirement System (2.0 percent per year) on the same high-3 average basic pay: monthly, annual, and 30-year lifetime differences. Excludes TSP matching, continuation pay, COLA, and taxes. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive BRS vs High-3 calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years_of_service | Yes | Years of service, clamped by the page to 20 to 40. | |
| high3_monthly_avg | Yes | High-3 average monthly basic pay in USD. |
calculate_capital_gains_taxInspect
Federal tax on ordinary income plus short term gains at ordinary rates, with long term gains stacked at the 0, 15, and 20 percent thresholds for the filing status. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive capital gains tax calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| filing_status | No | Filing status: single, mfj (married filing jointly), or hoh (head of household). | |
| long_term_gains | Yes | Long term capital gains in USD. | |
| ordinary_income | Yes | Ordinary taxable income in USD, before capital gains. | |
| short_term_gains | No | Short term capital gains in USD; default 0. |
calculate_car_affordabilityInspect
Monthly loan payment plus running costs (insurance, fuel, and maintenance, given as annual amounts), total interest, and the five year cost of a car. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive car affordability calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| fuel_annual | No | Fuel cost per year in USD; default 0. | |
| term_months | Yes | Loan term in months. | |
| down_payment | No | Down payment in USD; default 0. | |
| vehicle_price | Yes | Vehicle price in USD. | |
| annual_rate_pct | Yes | Loan annual rate percent. | |
| insurance_annual | No | Insurance cost per year in USD; default 0. | |
| maintenance_annual | No | Maintenance cost per year in USD; default 0. |
calculate_college_acceptanceInspect
Rough acceptance chance: a selectivity tier base rate (92, 80, 50, 20, or 5 percent) adjusted by GPA and test score bands, clamped to 1 to 99 percent and labeled Safety, Target, Reach, or High reach. SAT is used when provided, otherwise ACT. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive College Acceptance calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | ACT composite score, used only when no SAT is given, or 0 to leave out; default 0. | |
| gpa | Yes | Unweighted GPA on the 4.0 scale. | |
| sat | No | SAT total score, or 0 to leave out; default 0. | |
| tier_base_pct | No | Selectivity tier base rate percent from the page: 92 open admission, 80 less selective, 50 selective, 20 highly selective, 5 most selective; default 20. |
calculate_college_major_roiInspect
Payback years, lifetime earnings minus degree cost, and salary to cost ratio for a major, using the page table of approximate median early career salaries by major. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive College Major ROI calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| major | No | Major name from the page salary table; default Nursing. | |
| degree_cost | Yes | Total degree cost in USD. | |
| career_years | No | Projected career years; default 30. |
calculate_college_roiInspect
Earnings premium of a degree salary over a no degree baseline salary, both growing at the same annual raise rate, plus the net gain after degree cost, the break-even year, and the return multiple on cost. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive College ROI calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Working years to project; default 10. | |
| total_cost | Yes | Total degree cost in USD. | |
| baseline_salary | Yes | Starting yearly salary without the degree in USD. | |
| starting_salary | Yes | Starting yearly salary with the degree in USD. | |
| annual_raise_pct | No | Annual raise percent applied to both salaries; default 3. |
calculate_compound_interestBInspect
Future value of an investment with monthly contributions and monthly compounding. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive compound interest calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Projection horizon; default 30, max 100. | |
| principal | No | Starting balance in USD. | |
| annual_rate_pct | Yes | Annual return percent. | |
| include_schedule | No | Include the yearly growth schedule. | |
| monthly_contribution | No | Added at the end of each month in USD. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful behavioral fact: the result contains a calculator_url that should be rendered as a markdown link, which is non-obvious and actionable. However, it says nothing about the shape of the numeric result, the schedule behavior when include_schedule is set, or defaults/limits beyond what the schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the purpose leads, and the output-rendering requirement follows immediately. The IMPORTANT flag correctly draws attention to the one thing an agent could plausibly get wrong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only place return-value information can live, and it only covers the calculator_url. It omits what the numeric payload looks like and how include_schedule changes the response, which leaves an agent partially blind for a five-parameter financial calculator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (years, principal, annual_rate_pct, include_schedule, monthly_contribution) is already documented, establishing a baseline of 3. The description's mention of monthly contributions and monthly compounding loosely maps to parameters but adds no syntax, units, or defaults beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: future value of an investment with monthly contributions and monthly compounding. This distinguishes it from nearby siblings like calculate_roth_conversion or calculate_retirement_savings_planner, though it never explicitly names which sibling to prefer for overlapping retirement/investment questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no when-to-use or when-not-to-use guidance, and no alternatives are mentioned. The only instruction given is about post-processing the result (showing the URL), which is output handling rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_credit_card_payoffInspect
Months and interest to clear a credit card balance with a fixed monthly payment, compared with adding an extra monthly payment. A payment that never clears the balance returns null months and interest. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive credit card payoff calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | Yes | Card balance in USD. | |
| extra_payment | No | Extra payment added each month in USD; default 0. | |
| annual_rate_pct | Yes | Card APR percent. | |
| monthly_payment | Yes | Base monthly payment in USD. |
calculate_date_durationInspect
Inclusive number of days between two dates, plus business days after optionally excluding weekends and 2026 US federal holidays, calendar weeks, weekend days, and holidays in the range. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive date duration calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | End date in YYYY-MM-DD format. | |
| start_date | Yes | Start date in YYYY-MM-DD format. | |
| exclude_holidays | No | Exclude 2026 US federal holidays from the business day count. | |
| exclude_weekends | No | Exclude Saturdays and Sundays from the business day count. The page has this checked by default. |
calculate_debt_payoffInspect
Simulates paying off a list of debts month by month with minimum payments plus an extra monthly payment, comparing the avalanche method (highest APR first) with the snowball method (smallest balance first), and reports months to payoff, total interest, payoff order, and the interest and time the avalanche saves. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive debt payoff calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| debt_aprs | Yes | Comma-separated annual percentage rates, in the same order as the balances. | |
| debt_names | No | Comma-separated debt names, in the same order as the balances, APRs, and minimums. Blank names fall back to Debt 1, Debt 2, and so on. | |
| debt_balances | Yes | Comma-separated debt balances in USD, in the same order as the other debt lists. Debts with a balance of 0 are skipped. | |
| debt_minimums | Yes | Comma-separated minimum monthly payments in USD, in the same order as the balances. | |
| extra_payment | No | Extra payment each month on top of the minimums, in USD. |
calculate_dorm_vs_apartmentInspect
Compares the annual dorm cost with an apartment: monthly rent over the number of months, plus annual utilities, extra food cost, and commuting cost. Returns both annual totals, the difference, and which is cheaper. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Dorm vs Apartment calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| months | No | Months of rent per year; default 12. | |
| commute_annual | Yes | Annual commuting cost for the apartment in USD. | |
| dorm_annual_cost | Yes | Annual dorm cost in USD. | |
| utilities_annual | Yes | Annual utilities cost for the apartment in USD. | |
| food_extra_annual | Yes | Annual extra food cost versus the dorm meal plan in USD. | |
| apartment_monthly_rent | Yes | Monthly apartment rent in USD. |
calculate_emergency_fundInspect
Target emergency fund for a chosen number of months of essential expenses, the remaining gap, percent funded, and months to fill it at a monthly savings rate. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive emergency fund calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| current_savings | No | Already saved in USD; default 0. | |
| monthly_savings | No | Added per month in USD; default 0. | |
| monthly_expenses | Yes | Essential monthly expenses in USD. | |
| months_of_coverage | No | Months of expenses to cover, typically 3, 6, 9, or 12; default 6. |
calculate_fafsa_sai_estimatorInspect
Simplified Student Aid Index estimate using the page formula: parent income at 22 percent plus parent assets at 12 percent, student income above the 11770 income protection allowance at 50 percent plus student assets at 20 percent, plus an estimated Pell Grant of 7395 minus the SAI, floored at zero. Household size mirrors the page input; the simplified formula does not use it. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive FAFSA SAI Estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| parent_assets | Yes | Parent assets in USD. | |
| parent_income | Yes | Parent yearly income in USD. | |
| household_size | No | Household size, as on the page; the simplified page formula does not use it; default 4. | |
| student_assets | Yes | Student assets in USD. | |
| student_income | Yes | Student yearly income in USD. |
calculate_final_examInspect
Score needed on the final exam to reach a desired course grade, with the best and worst possible course grades. Inputs are clamped as on the page: grades to 0 to 100 and the final weight to 1 to 100. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Final Exam calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| final_weight_pct | Yes | Final exam weight percent of the course grade. | |
| current_grade_pct | Yes | Current course grade percent. | |
| desired_grade_pct | Yes | Desired final course grade percent. |
calculate_gi_billInspect
Months of the 36-month Post-9/11 GI Bill entitlement remaining, tuition coverage percent, maximum annual books stipend, and Monthly Housing Allowance treatment for the given benefit tier and enrollment level. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive GI Bill calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| tier_pct | No | Post-9/11 GI Bill benefit tier percent based on qualifying service. | |
| enrollment | No | Enrollment level: full-time, part-time (over half-time), or half-time or less. | |
| months_used | No | Months of entitlement already used, 0 to 36. |
calculate_gpaInspect
Credit weighted GPA on the 4.0 scale using the page grade points: A+ and A 4.0, A- 3.7, B+ 3.3, B 3.0, B- 2.7, C+ 2.3, C 2.0, C- 1.7, D+ 1.3, D 1.0, F 0.0. Grades and credits are matched by position. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive GPA calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| grades | Yes | Comma-separated letter grades, e.g. A,B+,A-,B. | |
| credits | Yes | Comma-separated credit hours matching grades. |
calculate_gpa_plannerInspect
Term GPA required over the planned credits to reach a target cumulative GPA, the maximum reachable cumulative GPA with straight As, and the grade mix the required GPA implies, using the page thresholds. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive GPA Planner calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| target_gpa | Yes | Target cumulative GPA. | |
| current_gpa | Yes | Current cumulative GPA. | |
| current_credits | Yes | Credit hours already completed. | |
| planned_credits | Yes | Credit hours planned this term. |
calculate_graduate_school_roiInspect
Annual salary premium after a graduate degree, break-even years on the total cost, and lifetime net over the career years, using the page formulas. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Graduate School ROI calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| total_cost | Yes | Total graduate degree cost in USD. | |
| career_years | No | Career years after graduation; default 20. | |
| current_salary | Yes | Current yearly salary in USD. | |
| post_degree_salary | Yes | Expected yearly salary after the degree in USD. |
calculate_gre_score_estimatorInspect
Estimated GRE verbal and quant scores on the 130 to 170 scale: 130 plus the fraction of questions correct times 40, per section, plus the total. The optional writing score is clamped to 0 to 6 as on the page. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive GRE Score Estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| quant_total | Yes | Total quant questions. | |
| verbal_total | Yes | Total verbal questions. | |
| quant_correct | Yes | Quant questions answered correctly. | |
| writing_score | No | Analytical writing score, 0 to 6; default 4. | |
| verbal_correct | Yes | Verbal questions answered correctly. |
calculate_high_school_course_plannerInspect
Credits still needed per subject against the page requirement table for the selected state (Texas, California, New York, Florida, or Illinois). Remaining per subject is required minus earned, floored at zero. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive High School Course Planner calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State code for the requirement table; default TX. | |
| math_credits | Yes | Math credits earned. | |
| social_credits | Yes | Social studies credits earned. | |
| english_credits | Yes | English credits earned. | |
| science_credits | Yes | Science credits earned. | |
| electives_credits | Yes | Elective credits earned. |
calculate_income_tax_estimatorInspect
Federal income tax after pretax deductions and the standard deduction for the filing status, with AGI, taxable income, marginal rate, and effective rate. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive income tax estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| gross_income | Yes | Gross annual income in USD. | |
| filing_status | No | Filing status: single, mfj (married filing jointly), or hoh (head of household). | |
| pretax_deductions | No | Pretax deductions in USD; default 0. |
calculate_inflationInspect
What an amount in today's dollars will buy after a number of years at a given annual inflation rate, what today's basket will cost then, the cumulative price increase percent, and the purchasing power lost. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive inflation calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | No | Years into the future. | |
| amount | Yes | Amount in today's dollars. | |
| annual_rate_pct | Yes | Annual inflation rate percent, e.g. 3. | |
| include_schedule | No | Set to true to include the purchasing power schedule in 5 year steps (or about 6 steps for longer horizons), matching the page table. |
calculate_lease_vs_buyInspect
Lease outlay over the lease term versus buy outlay net of equity in the car at the same point, with the winning option and the net cost difference. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive lease vs buy calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| msrp | Yes | Vehicle MSRP in USD. | |
| buy_rate_pct | Yes | Buy loan annual rate percent. | |
| lease_months | Yes | Lease term in months. | |
| money_factor | No | Lease money factor, for example 0.0025; default 0. | |
| residual_pct | Yes | Residual value as a percent of MSRP at lease end. | |
| buy_term_months | Yes | Buy loan term in months. | |
| buy_down_payment | No | Buy down payment in USD; default 0. | |
| lease_down_payment | No | Lease down payment in USD; default 0. | |
| lease_monthly_payment | Yes | Lease monthly payment in USD. |
calculate_les_decoderInspect
Net pay from a Leave and Earnings Statement: sums the entitlement lines (base pay, BAH, BAS, other) and deduction lines (federal tax, FICA, state tax, SGLI, TSP, other), and returns net pay plus deductions as a percent of entitlements. Negative line items count as zero, as on the page. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive LES decoder calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| bah | No | BAH entitlement in USD. | |
| bas | No | BAS entitlement in USD. | |
| tsp | No | TSP deduction in USD. | |
| fica | No | FICA deduction in USD. | |
| sgli | No | SGLI deduction in USD. | |
| base_pay | No | Base pay entitlement in USD. | |
| state_tax | No | State tax deduction in USD. | |
| federal_tax | No | Federal tax deduction in USD. | |
| other_deductions | No | Other deductions in USD. | |
| other_entitlements | No | Other entitlements in USD. |
calculate_loanBInspect
Monthly payment, total interest, and optional amortization schedule for an amortizing loan. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive loan calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| principal | Yes | Amount borrowed in USD. | |
| term_years | Yes | Term in years. | |
| annual_rate_pct | Yes | Annual rate percent. | |
| include_schedule | No | Include the yearly amortization schedule. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but a pure computation tool has little behavior to disclose. It does add one useful piece of context beyond the schema: the result contains a calculator_url, plus the fact that the schedule is optional and yearly. It does not state that the tool is side-effect-free, nor address rates/units assumptions beyond what the schema implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads what the tool returns, the second flags a required output-formatting behavior with an IMPORTANT marker. Both earn their place, though the second is an agent-behavior instruction rather than tool semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey return values, and it does list monthly payment, total interest, the optional schedule, and the calculator_url. It stops short of specifying units/precision or edge-case behavior, but for a 4-parameter pure calculator this is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 principal, term_years, annual_rate_pct, and include_schedule, establishing a baseline of 3. The description adds only a hint that the schedule is 'yearly' when requested, which is marginally more than the schema's 'Include the yearly amortization schedule'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete outputs (monthly payment, total interest, optional amortization schedule) for an amortizing loan, so an agent knows exactly what the tool computes. It does not, however, distinguish this generic amortizing calculator from close siblings such as calculate_mortgage, calculate_auto_loan, or calculate_sba_loan, which are also amortizing-loan calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to pick this tool over the many sibling loan calculators, nor any stated prerequisites or exclusions. The only instruction present concerns post-call output formatting (showing calculator_url), not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_lsat_score_estimatorInspect
Estimated LSAT scaled score on the 120 to 180 scale: 120 plus the overall fraction correct across the three sections times 60, with accuracy and the page score band. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive LSAT Score Estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| section1_total | Yes | Total section 1 questions. | |
| section2_total | Yes | Total section 2 questions. | |
| section3_total | Yes | Total section 3 questions. | |
| section1_correct | Yes | Section 1 questions answered correctly. | |
| section2_correct | Yes | Section 2 questions answered correctly. | |
| section3_correct | Yes | Section 3 questions answered correctly. |
calculate_mcat_score_estimatorInspect
Estimated MCAT section scores on the 118 to 132 scale: 118 plus the fraction correct times 14, per section, plus the total on the 472 to 528 scale. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive MCAT Score Estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| section1_total | Yes | Total section 1 questions. | |
| section2_total | Yes | Total section 2 questions. | |
| section3_total | Yes | Total section 3 questions. | |
| section4_total | Yes | Total section 4 questions. | |
| section1_correct | Yes | Section 1 questions answered correctly. | |
| section2_correct | Yes | Section 2 questions answered correctly. | |
| section3_correct | Yes | Section 3 questions answered correctly. | |
| section4_correct | Yes | Section 4 questions answered correctly. |
calculate_military_payInspect
Monthly basic pay from the 2026 pay table for a pay grade and years of service, plus the annualized amount. Grade E1B is the special E-1 rate for the first 4 months of service. Combinations the table does not authorize return authorized=false with null pay. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive military pay calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| pay_grade | Yes | Pay grade. E1B means E-1 with under 4 months of service. | |
| years_of_service | Yes | Years of service. |
calculate_military_retirement_pensionInspect
Monthly retired pay estimate: years of service times the system multiplier (2.0 percent per year for BRS, 2.5 percent per year for High-3) times the high-3 average monthly basic pay, before taxes, plus annual and 20-year lifetime amounts. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive military retirement pension calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| system | No | Retirement system: brs (2.0 percent per year) or high3 (2.5 percent per year). | |
| years_of_service | Yes | Years of service. | |
| high3_monthly_avg | Yes | High-3 average monthly basic pay in USD. |
calculate_mortgageAInspect
Monthly mortgage payment breakdown: principal and interest via the amortization formula, plus property tax, homeowner insurance, PMI, and HOA. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive mortgage calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| home_price | Yes | Purchase price in USD. | |
| term_years | No | Loan term in years; default 30. | |
| hoa_monthly | No | Monthly HOA dues in USD. | |
| pmi_rate_pct | No | Annual PMI rate percent; default 0.5. | |
| annual_rate_pct | Yes | Annual interest rate percent, e.g. 6.5. | |
| down_payment_pct | No | Down payment percent; default 20. | |
| down_payment_usd | No | Down payment in USD (wins over down_payment_pct). | |
| include_schedule | No | Include the yearly amortization schedule. | |
| property_tax_annual | No | Yearly property tax in USD. | |
| home_insurance_annual | No | Yearly homeowner insurance in USD. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose useful non-schema behavior: the amortization-based components included in the monthly breakdown and the requirement to surface calculator_url as a clickable markdown link. It does not explicitly state side-effect or permission behavior, but a mortgage calculator is implicitly non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences. The first front-loads what is calculated and the second gives an important presentation instruction with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter calculator with no output schema, the description covers the core computation and an important output field behavior. It could go further in describing the result shape or when to request the amortization schedule, but the schema handles parameter details well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 10 parameters, including defaults and the down_payment_usd override. The description adds useful context by listing the payment components, but it does not provide parameter-specific semantics beyond what the schema supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific calculation: monthly mortgage payment breakdown including principal, interest, property tax, insurance, PMI, and HOA. It is clear what the tool computes, but it does not distinguish itself from nearby siblings such as calculate_loan, calculate_affordability, or calculate_biweekly_mortgage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives among the many calculator siblings. Usage is only implied by the tool name and the mortgage-specific output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_net_worthInspect
Net worth, total assets, and total liabilities from comma separated asset and liability values, with optional matching names for the largest asset and liability. Only positive values count, as on the page. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive net worth calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_names | No | Asset names, comma separated, in the same order as asset_values. | |
| asset_values | Yes | Asset values in USD, comma separated, in the same order as asset_names. | |
| liability_names | No | Liability names, comma separated, in the same order as liability_values. | |
| liability_values | Yes | Liability values in USD, comma separated, in the same order as liability_names. |
calculate_paycheckInspect
Per paycheck net pay after federal income tax, FICA (Social Security capped at 184500 of wages, Medicare, and the additional Medicare tax), a flat state tax rate, and pretax deductions. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive paycheck calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| annual_salary | Yes | Annual salary in USD. | |
| filing_status | No | Filing status: single, mfj (married filing jointly), or hoh (head of household). | |
| pay_frequency | No | Paychecks per year: 52 weekly, 26 biweekly, 24 semimonthly, or 12 monthly; default 26. | |
| pretax_deductions | No | Annual pretax deductions in USD; default 0. | |
| state_tax_rate_pct | Yes | Flat state tax rate percent, applied to the full salary as on the page. |
calculate_pcs_moveInspect
Estimated PCS move money: Dislocation Allowance (DLA) plus Temporary Lodging Expense (TLE, days capped at 21) plus the gross Personally Procured Move (PPM) reimbursement, with the PPM profit after moving costs. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive PCS move calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| dla | No | Dislocation Allowance in USD. | |
| ppm_rate | No | PPM reimbursement rate per pound in USD. | |
| tle_days | No | Temporary Lodging Expense days, capped at 21. | |
| tle_rate | No | Daily TLE rate in USD. | |
| ppm_costs | No | Actual PPM moving costs in USD. | |
| ppm_weight | No | PPM shipment weight in pounds. |
calculate_percentageAInspect
Percentage calculations in three modes: percent_of (x percent of y), what_percent (x is what percent of y), percent_change (change from old to new). IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive percentage calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | For percent_of: the percent. For what_percent: the part. | |
| y | No | For percent_of: the whole. For what_percent: the whole. | |
| new | No | For percent_change: the ending value. | |
| old | No | For percent_change: the starting value. | |
| mode | Yes | Which percentage calculation to perform. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a non-obvious behavioral fact: the result contains a calculator_url that must be surfaced as a clickable markdown link. Since there is no output schema, this is information the agent could not otherwise obtain. It still omits edge-case behavior (e.g., division by zero when old=0), which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The mode definitions are compressed into a single front-loaded sentence, followed by the rendering directive. Every clause carries information, though the capitalized 'IMPORTANT: always show...' sentence is somewhat verbose for a single instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, single-required-field pure-computation tool with no annotations and no output schema, the description covers the mode semantics and the one notable return value (calculator_url). The main residual gap is edge-case/error behavior, which is minor for a deterministic calculator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: x, y, old, new and the mode enum are each documented in the schema itself, including their per-mode meaning. The description's mode formulas largely restate what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation (percentage calculation) and enumerates its three distinct modes with plain-language formulas (percent_of, what_percent, percent_change), which immediately separates it from the many domain-specific calculators in the sibling list such as calculate_tip or calculate_capital_gains_tax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains what each mode computes, which implicitly tells the agent which mode to pick for a given phrasing ("x percent of y" vs "x is what percent of y" vs "change from old to new"). However, it gives no guidance on when to prefer this generic tool over narrower siblings like calculate_tip, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_premed_course_plannerInspect
Progress across the 13 premed prerequisites on the page, in page order: General Chemistry I and II, Organic Chemistry I and II, Biology I and II, Physics I and II, Biochemistry, Psychology, Sociology, Statistics or Calculus, English (1 year). The first 11 are the MCAT core courses. Returns counts done, in progress, and planned, percent done, and whether all core courses are done. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Premed Course Planner calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| statuses | Yes | Comma-separated status for each of the 13 prerequisites in page order, each one of not, plan, prog, done, e.g. done,done,not,not,done,done,not,not,not,done,not,not,done. |
calculate_property_tax_estimatorInspect
Annual and monthly property tax from the home value minus any exemption, at the given tax rate, with assessed value and effective rate. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive property tax estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| home_value | Yes | Home value in USD. | |
| tax_rate_pct | Yes | Property tax rate percent. | |
| exemption_amount | No | Exemption amount in USD; default 0. |
calculate_psat_scoreInspect
Estimated PSAT section scores: 160 plus the fraction correct times 600, using the page fixed totals of 48 questions per section, plus the total and the page percentile band. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive PSAT Score calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| math_correct | Yes | Math questions answered correctly, out of 48. | |
| reading_writing_correct | Yes | Reading and writing questions answered correctly, out of 48. |
calculate_raise_vs_inflationInspect
Whether a raise beats inflation: nominal new salary, inflation adjusted real salary, the real percent change, and a real raise, real pay cut, or flat verdict. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive raise vs inflation calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| raise_pct | Yes | Raise percent. | |
| inflation_pct | Yes | Inflation percent over the same period. | |
| current_salary | Yes | Current salary in USD. |
calculate_refinanceBInspect
Refinance break-even month and lifetime savings of refinancing a loan. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive refinance calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| balance | Yes | Current loan balance in USD. | |
| years_left | Yes | Years remaining on the current loan. | |
| new_rate_pct | Yes | Offered annual rate percent. | |
| closing_costs | No | Closing costs in USD. | |
| new_term_years | No | New loan term in years; default 30. | |
| current_rate_pct | Yes | Current annual rate percent. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that a calculator_url is returned and implies return fields (break-even month, lifetime savings), which is real added value over the schema. However, it says nothing about modeling assumptions or defaults (e.g., how closing_costs is treated if omitted, or that new_term_years defaults to 30) and does not enumerate the rest of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly written, with the core function front-loaded before the output-handling instruction. The 'IMPORTANT' block is somewhat directive in tone but does carry actionable content, so it earns its place rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description is the only place return values can be explained, and it covers only two named outputs plus calculator_url. For a six-parameter calculator with optional inputs, the description leaves the full result shape and default behaviors unstated. It is minimally adequate but has visible gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the input schema and the baseline is 3. The description adds no format, unit, or default information beyond what the schema states, so it neither compensates nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb-plus-resource pair and enumerates the actual outputs: the refinance break-even month and lifetime savings. That is enough to separate it from siblings like calculate_loan or calculate_mortgage. It stops short of explicitly contrasting itself with close alternatives such as calculate_arm_vs_fixed or calculate_loan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to reach for this tool versus the many adjacent loan/mortgage calculators in the sibling list. The only directive is about post-processing the result (rendering calculator_url as a markdown link), which is an output-handling rule, not usage guidance. An agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_rent_vs_buyInspect
Compares the net cost of buying a home (down payment, mortgage payments, tax, insurance, and maintenance, minus principal repaid and appreciation gain) with the total rent paid over the years you plan to stay, and gives a verdict plus the equity built. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive rent vs buy calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Home price in USD. | |
| stay_years | No | Years planning to stay in the home. | |
| term_years | No | Loan term in years. | |
| monthly_rent | Yes | Current monthly rent in USD. | |
| annual_rate_pct | Yes | Mortgage annual rate percent, e.g. 6.5. | |
| maintenance_pct | No | Maintenance per year as a percent of the home value. | |
| appreciation_pct | No | Annual home appreciation percent. | |
| down_payment_pct | No | Down payment percent of the home price. | |
| rent_increase_pct | No | Annual rent increase percent. | |
| property_tax_annual | No | Property tax per year in USD. | |
| home_insurance_annual | No | Homeowner insurance per year in USD. |
calculate_retirement_savings_plannerInspect
Projected retirement balance from current savings plus monthly contributions with monthly compounding, total contributions, growth, and a 4 percent rule withdrawal figure. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive retirement savings planner calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | Yes | Current age in years. | |
| retirement_age | Yes | Retirement age in years. | |
| current_savings | No | Current retirement savings in USD; default 0. | |
| annual_return_pct | Yes | Annual return percent. | |
| monthly_contribution | No | Monthly contribution in USD; default 0. |
calculate_roth_conversionInspect
Value of converting to a Roth now, with the tax paid out of the converted amount, versus leaving the money in a traditional account taxed at the retirement rate, after growth. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive roth conversion calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Years of growth after conversion. | |
| annual_return_pct | Yes | Annual return percent. | |
| conversion_amount | Yes | Amount considered for conversion in USD. | |
| current_tax_rate_pct | Yes | Tax rate percent if converting now. | |
| retirement_tax_rate_pct | Yes | Expected tax rate percent in retirement. |
calculate_roth_vs_traditionalInspect
Compares a Roth and a traditional retirement account at the same pre-tax annual contribution: the Roth invests what is left after tax today and is tax free at withdrawal, the traditional invests the full amount and is taxed at the retirement rate. Reports the winner, both after-tax values, and the tax each side pays. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Roth vs traditional calculator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Current age in years. | |
| retirement_age | No | Retirement age in years. | |
| annual_return_pct | No | Expected annual return percent. | |
| annual_contribution | Yes | Annual contribution before tax, in USD. | |
| current_tax_rate_pct | No | Current marginal tax rate percent. | |
| retirement_tax_rate_pct | No | Expected tax rate in retirement percent. |
calculate_salaryBInspect
Convert between hourly, daily, weekly, biweekly, monthly, and annual pay. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive salary calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Whether the input is an hourly rate or an annual salary; default hourly. | |
| annual | No | Annual salary in USD (annual mode). | |
| hourly | No | Hourly rate in USD (hourly mode). | |
| hours_per_week | No | Hours worked per week; default 40. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it does disclose one genuinely useful behavioral fact: the result contains a calculator_url that should be surfaced to the user โ important since there is no output schema. It still omits whether figures are gross or net, rounding, and any assumptions about hours_per_week beyond the schema default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the capability statement before the imperative instruction. The all-caps IMPORTANT sentence is slightly heavy but earns its place by specifying a required output behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description should compensate more than it does; it hints at calculator_url but never describes the other returned values (the converted amounts). Adequate but with a real gap for an unannotated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including the mode enum default and hours_per_week default, so the schema already documents all four parameters. The description adds no additional parameter meaning; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource ('Convert between ... pay') and enumerates the pay periods involved, which distinguishes it from neighbors like calculate_paycheck or calculate_military_pay. However, it claims conversion across six frequencies while the schema only supports hourly<->annual, a mild overstatement that keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no routing away from similar siblings (calculate_paycheck, calculate_military_pay, calculate_biweekly_mortgage). The agent must infer that this is a generic pay-period converter rather than a take-home-pay estimator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_sat_scoreInspect
Estimated SAT section scores: 200 plus the fraction correct times 600, using the page fixed totals of 54 reading and writing questions and 44 math questions, plus the total and the page competitiveness band. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive SAT Score calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| math_correct | Yes | Math questions answered correctly, out of 44. | |
| reading_writing_correct | Yes | Reading and writing questions answered correctly, out of 54. |
calculate_sba_loanInspect
Monthly payment for an SBA loan with the guarantee fee percent financed into the loan, plus the amount financed, total interest, and total cost. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive sba loan calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| term_years | Yes | Term in years. | |
| loan_amount | Yes | Loan amount in USD. | |
| annual_rate_pct | Yes | Annual rate percent. | |
| guarantee_fee_pct | No | Guarantee fee percent of the loan amount, financed into the loan; default 0. |
calculate_scholarship_roi_trackerInspect
Expected value of a scholarship application (award times win probability, clamped to 0 to 100 percent) and its expected value per hour of work, with the page verdict comparing that rate with an hourly wage. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Scholarship ROI Tracker calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | Hours the application takes. | |
| hourly_wage | Yes | Hourly wage of the job the time could go to instead, in USD. | |
| award_amount | Yes | Scholarship award amount in USD. | |
| win_probability_pct | Yes | Estimated win probability percent. |
calculate_sgli_vs_private_insuranceInspect
Cost comparison of SGLI (0.06 USD per 1,000 USD of coverage per month plus a 1 USD monthly fee) against a private term premium over the given number of years: monthly and total SGLI cost, total private cost, and which is cheaper. The page's age field is not used by its calculation and is not a parameter here. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive SGLI vs private insurance calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Comparison horizon in years (minimum 1, as on the page). | |
| coverage | Yes | Life insurance coverage amount in USD. | |
| private_monthly | Yes | Private term insurance monthly premium in USD. |
calculate_social_security_estimatorInspect
Primary insurance amount from the bend point formula (1286 and 7749) applied to average indexed monthly earnings, with monthly benefits at ages 62, 67, and 70. Annual earnings, when given above 0, override AIME as annual divided by 12. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive social security estimator calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| aime_monthly | Yes | Average indexed monthly earnings in USD. | |
| annual_earnings | No | Annual earnings in USD; when above 0 it overrides aime_monthly. Default 0. |
calculate_student_budgetInspect
Monthly budget from job, parent, and aid income against rent, food, books, transport, and fun spending. Returns total income, total expenses, the balance, and the largest category with its share of expenses. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Student Budget calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| fun | Yes | Monthly fun and entertainment spending in USD. | |
| food | Yes | Monthly food spending in USD. | |
| rent | Yes | Monthly rent in USD. | |
| books | Yes | Monthly books and supplies spending in USD. | |
| transport | Yes | Monthly transport spending in USD. | |
| aid_income | Yes | Monthly financial aid income in USD. | |
| job_income | Yes | Monthly job income in USD. | |
| parent_contribution | Yes | Monthly contribution from parents in USD. |
calculate_student_loan_payoffInspect
Months to pay off a student loan and the total interest, computed month by month exactly as the page does. With an extra monthly payment, also returns the interest and months saved. Returns null fields and never_payoff true when the payment does not cover monthly interest. Payoff dates are not returned because the page derives them from the current date. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Student Loan Payoff calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| apr_pct | Yes | Annual percentage rate percent. | |
| balance | Yes | Loan balance in USD. | |
| extra_payment | No | Extra monthly payment in USD; default 100, the page default. | |
| monthly_payment | Yes | Monthly payment in USD. |
calculate_textbook_costInspect
Net cost of buying new, buying used, renting, and digital for a textbook. Purchase options are reduced by the resale value (floored at zero), and the cheapest option is returned. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Textbook Cost calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| rent_price | Yes | Rental price in USD. | |
| resale_value | Yes | Expected resale value after the term in USD. | |
| buy_new_price | Yes | Price to buy the book new in USD. | |
| digital_price | Yes | Digital edition price in USD. | |
| buy_used_price | Yes | Price to buy the book used in USD. |
calculate_tipAInspect
Tip amount, bill total, and per-person split. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive tip calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| bill | Yes | Bill amount in USD. | |
| people | No | Number of people; default 1. | |
| tip_pct | No | Tip percent; default 20. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden and does disclose a genuinely non-obvious trait: the result includes a calculator_url that must be rendered as a clickable markdown link. It also implies the shape of the return (tip, total, per-person split), though it says nothing about rounding, negative/zero inputs, or currency conversion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with what is computed and followed by the critical presentation instruction. No filler, though the opening is a noun fragment rather than a fully formed statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter calculator with no output schema and no annotations, the description covers the essentials: what is computed, the fields returned, and the required display behavior for the returned URL. Edge-case behavior (rounding, zero people) is the only meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema documents all three parameters including defaults (people=1, tip_pct=20, bill in USD). The description adds nothing about parameter semantics beyond echoing the outputs, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the concrete outputs (tip amount, bill total, per-person split), and the tool name supplies the verb 'calculate'. It is specific enough that an agent knows exactly what it gets back, and no sibling tool covers tip splitting, so differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance; the only directive concerns how to present the result, not when to invoke the tool. Usage is fairly self-evident from the name, which keeps this from being a 1, but nothing is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_transfer_credit_plannerInspect
Credits remaining, terms remaining at the credits taken per term, years remaining at the terms per year, and credits per year. The graduation date label is not returned because the page derives it from the current date. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive Transfer Credit Planner calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| terms_per_year | No | Terms per year; default 2. | |
| credits_per_term | Yes | Credits taken per term. | |
| required_credits | Yes | Total credits required for the degree. | |
| completed_credits | Yes | Credits already completed or transferred. |
calculate_tspInspect
Projected TSP balance with annual employee contributions (capped at the 24,500 USD elective deferral limit used by the page) plus, when matching is on, the BRS agency contribution: 1 percent automatic plus a match of 100 percent of the first 3 percent of pay and 50 percent of the next 2 percent. Contributions are treated as annual amounts compounded with the starting balance, as on the page. The page's Roth percent field is not used by its calculation and is not a parameter here. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive TSP calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | Projection horizon in years. | |
| salary | Yes | Annual salary (basic pay basis) in USD. | |
| balance | No | Current TSP balance in USD. | |
| match_on | No | Whether BRS agency automatic and matching contributions apply. | |
| return_pct | Yes | Annual return percent. | |
| contrib_pct | Yes | Employee contribution percent of salary. |
calculate_unit_converterInspect
Converts a value between units in one category: length, weight, temperature, volume, or speed. Returns the converted result in the page's display precision, the value in base units, and the conversion rate (null for temperature, which uses an offset scale). Unit codes must belong to the chosen category. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive unit converter calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value to convert. | |
| to_unit | No | Unit code to convert to. Must be a unit of the chosen category, using the same code lists as from_unit. | |
| category | No | Unit category to convert within. | |
| from_unit | No | Unit code to convert from. Must be a unit of the chosen category: length m, km, cm, mi, ft, in; weight kg, g, lb, oz; temperature C, F, K; volume L, mL, gal, floz; speed ms, kmh, mph. |
calculate_va_disabilityInspect
Monthly VA disability compensation from the 2026 rates (2.8 percent COLA, effective Dec 1, 2025) for a combined rating from 10 to 100 percent and a dependent status, plus the annualized amount. Dependency add-ons begin at 30 percent. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive VA disability calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | VA combined disability rating percent. | |
| dependents | No | Dependent status: alone, spouse, spouseChild, spouse2Children, or vetChild. |
calculate_word_counterInspect
Counts words, characters, characters excluding whitespace, sentences, and paragraphs in a block of text, plus estimated reading time at 200 words per minute and speaking time at 130 words per minute. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive word counter calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to count. |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
69 tool updates
- First observed
calculate_401k - First observed
calculate_act_score - First observed
calculate_affordability - First observed
calculate_aft - First observed
calculate_age - First observed
calculate_ap_exam_score - First observed
calculate_arm_vs_fixed - First observed
calculate_auto_loan - First observed
calculate_bah - First observed
calculate_biweekly_mortgage - First observed
calculate_bmi_tdee - First observed
calculate_brs_vs_high3 - First observed
calculate_capital_gains_tax - First observed
calculate_car_affordability - First observed
calculate_college_acceptance - First observed
calculate_college_major_roi - First observed
calculate_college_roi - First observed
calculate_compound_interest - First observed
calculate_credit_card_payoff - First observed
calculate_date_duration - First observed
calculate_debt_payoff - First observed
calculate_dorm_vs_apartment - First observed
calculate_emergency_fund - First observed
calculate_fafsa_sai_estimator - First observed
calculate_final_exam - First observed
calculate_gi_bill - First observed
calculate_gpa - First observed
calculate_gpa_planner - First observed
calculate_graduate_school_roi - First observed
calculate_gre_score_estimator - First observed
calculate_high_school_course_planner - First observed
calculate_income_tax_estimator - First observed
calculate_inflation - First observed
calculate_lease_vs_buy - First observed
calculate_les_decoder - First observed
calculate_loan - First observed
calculate_lsat_score_estimator - First observed
calculate_mcat_score_estimator - First observed
calculate_military_pay - First observed
calculate_military_retirement_pension - First observed
calculate_mortgage - First observed
calculate_net_worth - First observed
calculate_paycheck - First observed
calculate_pcs_move - First observed
calculate_percentage - First observed
calculate_premed_course_planner - First observed
calculate_property_tax_estimator - First observed
calculate_psat_score - First observed
calculate_raise_vs_inflation - First observed
calculate_refinance - First observed
calculate_rent_vs_buy - First observed
calculate_retirement_savings_planner - First observed
calculate_roth_conversion - First observed
calculate_roth_vs_traditional - First observed
calculate_salary - First observed
calculate_sat_score - First observed
calculate_sba_loan - First observed
calculate_scholarship_roi_tracker - First observed
calculate_sgli_vs_private_insurance - First observed
calculate_social_security_estimator - First observed
calculate_student_budget - First observed
calculate_student_loan_payoff - First observed
calculate_textbook_cost - First observed
calculate_tip - First observed
calculate_transfer_credit_planner - First observed
calculate_tsp - First observed
calculate_unit_converter - First observed
calculate_va_disability - First observed
calculate_word_counter
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.1611 npm1MIT
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs117 npm54 PyPIMIT
- AlicenseAqualityCmaintenanceRevnuvo Company Intelligence tells AI agents what changed at a company, with evidence. It observes company websites, technologies, and DNS over time and returns timestamped, confidence-aware changes, signals, and monitoring.9MIT

industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent โ real, source-backed data.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.