fixed-income

List a bond's remaining cash flows

cashflow_schedule_tool

Generate a bond's remaining payment schedule with dates, amounts, and discount factors from a yield, handling fractional settlement periods.

Instructions

Remaining payments, with discount factors when a yield is supplied.

The first flow sits a fraction of a period away rather than a whole one. That exponent is what makes an ACT/ACT ICMA yield differ from a naive one, so it is reported explicitly as periods_from_settlement.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ytm_pct`	No	Nominal annual yield as a percentage, e.g. 4.6867. Supply either this or clean_price_pct_of_face, never both.
`day_count`	No	Day-count convention used for accrual. ACT/ACT ICMA is the standard for most government and corporate bonds.	ACT/ACT ICMA
`face_value`	Yes	Redemption amount in currency units, e.g. 1000.
`issue_date`	Yes	Issue (dated) date in ISO format, e.g. 2024-03-15.
`maturity_date`	Yes	Redemption date in ISO format, e.g. 2029-03-15.
`coupon_rate_pct`	Yes	Annual coupon rate as a PERCENTAGE. Pass 4.0 for a 4% coupon, not 0.04. Zero for a zero-coupon bond.
`settlement_date`	Yes	Valuation date in ISO format. Must fall between issue and maturity, e.g. 2025-09-11.
`payments_per_year`	Yes	Coupon payments per year: 1 annual, 2 semi-annual, 4 quarterly, 12 monthly. Most government bonds pay semi-annually.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Sep 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description takes on the burden of behavioral disclosure. It explains the first-flow timing nuance and the periods_from_settlement field, which is valuable for understanding ACT/ACT ICMA calculations. It also notes that discount factors appear only when a yield is supplied, which is a useful conditional behavior.

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 short paragraphs with no filler. The core outcome is front-loaded, and the second paragraph earns its place by explaining a subtle but important calculation detail.

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?

The description is fairly complete given the rich schema and output schema. It adds the key nuance about cash-flow timing that isn't in the schema. It might mention the yield-or-price mutual exclusivity, but that's already in the parameter description, so the description doesn't need to repeat it.

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

Parameters4/5

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

The input schema provides full descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description adds meaning by explaining the exponent that distinguishes ACT/ACT ICMA from a naive yield, which relates to the day_count parameter and the periods_from_settlement output. This goes beyond the short parameter descriptions in the schema.

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

Purpose4/5

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

The title 'List a bond's remaining cash flows' provides a clear verb+resource, and the description adds that it includes discount factors when a yield is supplied. However, the description itself uses a noun phrase ('Remaining payments') rather than an explicit verb, and it doesn't explicitly differentiate from sibling tools.

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 does not explicitly state when to use this tool versus the sibling bond tools; it only describes the output. Usage is implied by the tool's name and title, but there is no explicit when/when-not guidance or mention of alternatives.

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

Deploy Server