Tesouro em Foco is a free remote MCP server that brings Brazilian government bond (Tesouro Direto) pricing into AI assistants such as Claude, Cursor, and any MCP-compatible client.
The engine implements the Brazilian National Treasury's official pricing methodology — validated against 269,000+ real trades — and covers all retail bond types: fixed-rate (LTN, NTN-F), inflation-linked (NTN-B Principal, NTN-B), and retirement/education bonds (Renda+ and Educa+, NTN-B1).
Scored across 8 tools
Each tool has a clearly distinct purpose: catalog discovery, macro indicator history, live quotes, historical point lookups, time-series/aggregates, cross-bond ranking, bond simulation, and redemption simulation. Even the two historical price tools are cleanly separated by use case (specific dates vs. series/stats). The descriptions strongly support correct tool selection.
Naming is readable and lowercase-snake throughout, but there is a clear split: data-retrieval tools use object-first names (price_history_series, live_quotes_lookup) while simulation tools use verb-first names (simulate_bond, simulate_redemption). catalog_list and indicator_history fit neither pattern, creating inconsistency despite the logical clusters.
Eight tools is a well-scoped size for this domain. Each tool covers a distinct workflow—catalog discovery, macro context, live quotes, historical lookups, series/stats, ranking, bond pricing simulation, and redemption simulation—without redundancy. The count feels appropriate and not overwhelming.
The tool surface covers the full user journey for Tesouro Direto analysis: discovering bonds, checking live and historical rates, comparing across the catalog, getting macro context, simulating hypothetical operations, and estimating net redemption proceeds. Each tool has fallbacks and cross-references, leaving no obvious dead ends for common bond questions.
USE THIS BEFORE calling simulate_bond to discover available bonds, or to disambiguate a user's reference (e.g. 'IPCA+ 2050' → which exact maturityDate?). Lists every Tesouro Direto bond currently in the official catalog, grouped by family.
Each product includes launchDate and maturityDate; Renda+/Educa+ also include conversionDate and installments (240 monthly payments for Renda+, 60 for Educa+). The year field meaning depends on family:
prefixado / IPCA+: catalog maturity-year key (e.g. 2031 → maturity in 2031).
Renda+ / Educa+: the conversion year shown on the label (e.g. Renda+ 2065 → conversion on 15 Jan 2065, NOT redemption year). Final redemption is ~20 years later for Renda+ and ~5 years later for Educa+.
Note: simulate_bond accepts bonds outside this catalog too (older maturities for historical simulation) — those calls succeed with a SYNTHESIZED_BOND warning in meta.warnings[] indicating the product was synthesized.
Returns: array of { type, label, products: [{ year, maturityDate, launchDate, conversionDate?, installments? }] }.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations. It explains the meaning of the 'year' field varies by bond family, discloses that Renda+/Educa+ have conversion dates distinct from redemption, and warns that simulate_bond may synthesize bonds outside the catalog with a warning in meta.warnings[]. These details are not inferable from the annotations and provide critical operational knowledge.
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 well-structured with clear sections: usage, list scope, product fields, and family-specific year semantics. It is front-loaded with the most actionable instruction ('USE THIS BEFORE...'), and every sentence contributes necessary information without redundancy. Though lengthy, the complexity of the domain justifies the detail.
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?
The description is fully self-contained for a zero-parameter read-only tool. It covers the output shape, field semantics, special cases for Renda+/Educa+, and the relationship with simulate_bond. Given the output schema exists and the tool has no inputs, this is complete and leaves no critical ambiguity.
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?
With zero parameters, the input schema is empty, so the description does not need to clarify parameter meaning. The baseline for 0 params is 4, and the description focuses instead on the output structure and semantics, which is appropriate. No parameter-related gaps exist.
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 clearly states the tool 'Lists every Tesouro Direto bond currently in the official catalog, grouped by family.' This is a specific verb+resource with scope, and it distinguishes itself from sibling tools like simulate_bond and price_history_lookup by focusing on catalog discovery. The use-case examples ('IPCA+ 2050' → maturityDate) further clarify its purpose.
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?
Explicit guidance is provided: 'USE THIS BEFORE calling simulate_bond to discover available bonds, or to disambiguate a user's reference.' It also notes that simulate_bond accepts bonds outside the catalog, which helps agents decide when not to use this tool. This clearly differentiates when to use catalog_list versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full published history of a Brazilian reference series, so you can put macro context next to a bond's own rate history without leaving this server. Every rate is a decimal-fraction string, the same convention as every other tool here.
Available indicator values:
selic-target — the meta Selic set by the Copom, from the official Banco Central rate history. Annual (unit: 'annual-decimal-fraction', '0.1425' = 14.25% a.a.), so it compares with price_history_series directly.
ipca-monthly — the IPCA measured and published by the IBGE (read from Banco Central SGS series 433), every month since January 1980. Monthly (unit: 'monthly-decimal-fraction', '0.0007' = 0.07% a.m.).
ALWAYS read unit before comparing series or charting them together: an IPCA month is not an annual rate, and treating '0.0044' as 0.44% a.a. instead of 0.44% a.m. is off by more than a factor of ten. To annualize a month, compound it; to get a 12-month accumulated IPCA, compound the twelve monthly readings — do not add them.
For selic-target this is EVERY decision since the regime began in March 1999, including the meetings that held the rate (outcome: 'hold', changeBps: 0). Read outcome to tell them apart: up, down, hold, or start for the single opening entry. Count only up/down when the user asks how many times the rate actually moved.
Two selic-target fields are easy to misread. meetingNumber is NOT unique: until 2003 a meeting could set a bias ('alta'/'baixa') authorizing the Banco Central president to move the target before the next meeting, alone, and those decisions carry monocratic: true under the authorizing meeting's number — effectiveDate is the key. And effectiveRate is the Selic actually realized over the period, a different quantity from the target in rate; it is null while a period is still in force.
For ipca-monthly, referenceMonth is the month the index MEASURES, not the month it was released — the IPCA of a month comes out around the 10th of the next one, so the most recent entry is normally the previous month — or the one before it, in the first days of a month, while the release is still pending. These are realized readings only; this server holds no IPCA forecast, and the projections that go into pricing an IPCA+ bond are a different thing, not exposed here. Readings before July 1994 are from the hyperinflation era and are genuinely that large (82.39% in March 1990).
Neither series by itself sets the rate or price of any Treasury bond, and a move in the same window is not evidence that one caused the other. These are factual series, not a forecast, a market interpretation, or a recommendation.
Returns { series, unit, source: { id, publisher }, items }. For selic-target, items is [{ decisionDate, effectiveDate, rate, previousRate, changeBps, outcome, meetingNumber, extraordinary, monocratic, bias, effectiveRate }] ascending by effectiveDate. For ipca-monthly, items is [{ referenceMonth, rate }] ascending by referenceMonth, one entry per month with no gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | Which reference series to return. `selic-target` is the Selic target rate set by the Copom (Banco Central), annual. `ipca-monthly` is the IPCA published by the IBGE, monthly — the realized index, not the projection used in pricing. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, but the description goes far beyond them. It explains decimal-fraction string conventions, unit differences, outcome semantics, monocratic decisions, effective versus target rates, referenceMonth timing, hyperinflation-era magnitudes, and the limitation that these are realized facts, not forecasts or recommendations. This is rich behavioral disclosure.
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?
This is a longer description, but every sentence earns its place. It uses bullets and bolded emphasis to structure key distinctions, returns format warnings upfront, and explained without fluff. Despite its length, it remains readable because the unit caveat, outcome semantics, and output shape are all clearly organized.
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?
The description is complete for a single parameter read-only tool: it defines the available inputs, output structure, return values, unit semantics, common misinterpretations, and historical caveats given the limited input schema and high complexity of the data. An agent can confidently choose the correct indicator and interpret the numeric response without further context.
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?
Although the schema already documents the indicator parameter with an enum, the description adds substantial meaning beyond it: annual versus monthly semantics, exact sources, date ranges, comparison safety, caveats about compounding, and interpretation guidance. It fully covers the two possible values in a useful way and even explains how to handle edge cases.
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 action and resource: returning the full published history of a Brazilian reference series. It explicitly distinguishes this from bond price tools by explaining it supplies macro context alongside a bond's rate history. The mention of comparing with price_history_series directly further separates it from siblings.
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 clearly frames when this context is relevant and warns against using the series as forecasts or causal evidence. It does not explicitly enumerate sibling alternatives or state 'use X for bond pricing instead,' but the context and exclusions are strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up live quotes for Tesouro Direto bonds (sourced from the TD website, not STN CSV). Use for current indications only.
Each query requires productId plus exactly one year field — maturityYear is required for all products except renda-mais/educa-mais; for renda-mais/educa-mais use maturityYear (calendar maturity year) OR conversionYear (label year on the bond name, e.g. 2027 for 'Educa+ 2027') — never both. Omitting the year field will error.
Each result has optional investorBuy and investorSell objects with { rate, price } — the two sides are independent, so one may be present without the other. When found is true there is also an optional fetchedAt — ISO-8601 UTC from the last site scrape.
Field semantics:
investorBuy — investor PURCHASE side: rate and price at which the investor buys from the Treasury.
investorSell — investor SELL-BACK side: rate and price at which the investor sells back to the Treasury. Normally investorSell.rate > investorBuy.rate.
Always consult catalog_list to check if the bond is currently available for purchase or sale by Tesouro Direto.
found: true means at least one of investorBuy / investorSell is present — each side may be absent independently, so always check which one came back (if you need a single rate and investorBuy is missing, use investorSell). found: false means neither side is present. Possible causes: outside BRT market hours (nights/weekends/holidays), the bond is not currently offered by Tesouro Direto, the year identifier does not match an active offering, or the stored quotes are invalid. When found is false fall back to price_history_lookup / price_history_series for the latest official STN rate.
Rates are decimal fraction strings (e.g. '0.0753' = 7.53% a.a.) — same convention as price_history_* and simulate_bond.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds rich behavioral details: the independence of investorBuy/investorSell, the meaning of found true/false with potential causes, and the decimal fraction string convention. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, the description is well-structured into paragraphs and field semantics, with bold emphasis on key constraints. Every sentence provides operational guidance; no filler.
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 tool with nested query objects, optional result fields, and multiple failure modes, the description covers parameters, output semantics, error causes, and fallbacks. The presence of an output schema relieves the need to document return structure in detail, but the description still adds essential context for agents.
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?
The schema only shows a queries array with minimal sub-field descriptions; the description explains the critical rule of exactly one year field, the maturityYear vs conversionYear distinction, and the requirement of productId. It also clarifies rate/price format, adding semantics 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?
The description opens with a specific verb and resource: 'Looks up live quotes for Tesouro Direto bonds', explicitly contrasting with STN CSV sources used by sibling tools like price_history_lookup. This clearly distinguishes live_quotes_lookup from its siblings.
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 states when to use: 'Use for current indications only' and instructs to always consult catalog_list to verify availability, plus explicit fallback to price_history_lookup / price_history_series when found is false. This provides clear context and names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up historical published rates and prices for Tesouro Direto bonds on specific dates.
Accepts a bulk array of queries (up to 50). Each query: productId + referenceDate + exactly one paper identifier (maturityDate, maturityYear, or conversionYear for Renda+/Educa+). Returns official STN data for that date, or found=false.
Use when the user asks for the official published rate or unit price on a specific past date (e.g. "what was the IPCA+ 2035 rate in March 2024?").
Each result has optional investorBuy and investorSell objects with { rate, price }:
investorBuy — investor PURCHASE side (STN's Taxa de Compra / PU de Compra). This is the standard quoted rate.
investorSell — investor SELL-BACK side (STN's Taxa de Venda / PU de Venda). Normally investorSell.rate > investorBuy.rate.
found: false with unavailableReason: 'awaiting-confirmed-precision' (Selic only) does NOT mean the date has no data: STN published that session in the 2-decimal CSV but not yet in the 4-decimal file this tool requires for Selic. Do not report it to the user as missing — say the confirmed rate is not published yet, and use price_history_series for the same date at CSV precision. A found: false with no unavailableReason means no row matched the requested paper and date — the lookup is keyed by paper, so it cannot tell a market holiday from a paper STN did not offer that day.
Rates are decimal fraction strings (e.g. '0.0737' = 7.37% a.a.) — same convention as simulate_bond and live_quotes_lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of point queries (1 to 50). Each query returns one result row or found=false. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral nuance beyond those: the bulk limit of 50, the meaning of found:false, the Selic 'awaiting-confirmed-precision' caveat, the inability to distinguish holidays from unoffered papers, and the decimal-string rate convention. No contradiction with annotations exists.
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 long but tightly organized into logical paragraphs: purpose, query structure, usage trigger, result semantics, edge-case handling, and rate format. Every sentence carries necessary behavioral or routing information, and the most important scoping information is front-loaded.
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?
Given the tool's complexity, the description is remarkably complete: it covers input composition, result shape at a high level, an important Selic-specific caveat, the meaning of found:false, and cross-tool conventions shared with simulate_bond and live_quotes_lookup. An agent has enough to invoke it correctly and interpret unusual results.
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 the baseline of 3 applies. The description restates the 'exactly one of maturityDate/maturityYear/conversionYear' rule and adds the rate-format convention, but most parameter meaning already lives in the schema; the added value is useful but not transformative.
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 opens with a specific verb-resource pair: 'Looks up historical published rates and prices for Tesouro Direto bonds on specific dates.' It clearly distinguishes itself from the sibling price_history_series by emphasizing point-in-time lookups vs. series data, and later explicitly directs the Selic-precision edge case to that sibling.
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 provides an explicit 'Use when...' statement with a concrete user query example. It also names an alternative tool (price_history_series) and the exact condition under which to switch, which fully supports tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks every bond in the active Tesouro Direto catalog by where its latest published rate sits within its own history — in ONE call. Prefer this for questions like "which bonds have rates near their historical highs?", "how does today's rate compare with the past, across the catalog?", or any cross-bond comparison of rate levels. Do NOT loop price_history_series per paper for that.
For each catalog paper and each requested window it returns rate stats for one side: min/max, nearest-rank percentiles p10/p25/p50/p75/p90 (always actually published rates), last (most recent published rate on or before to) and lastPercentile (0-100: share of the window strictly below last — 92 means the current rate is above 92% of the period, i.e. near the top of its historical range).
Inputs (all optional):
windows: 1-3 of '30d' | '90d' | '1y' | '5y' | 'max', default ['1y']. Ranking is ordered by the FIRST window's lastPercentile (desc); extra windows add context (e.g. ['1y','max']).
side: 'investorBuy' (default — investor PURCHASE rate, STN's Taxa de Compra; the standard quoted rate) or 'investorSell' (sell-back). Only papers currently available for that side are ranked.
productId: filter to one family. Only the seven catalog families are rankable — 'igpm-mais-com-juros-semestrais' has history but no active catalog entries; for it use price_history_series. On 'selic' the percentiles are coarse: the published rate is a spread over the Selic, near zero and rounded to two decimals of a percent, so a window holds few distinct values.
to: anchor date YYYY-MM-DD (default today UTC) — set a past date for "how did the ranking look then?".
Output: ranking[] with productId, maturityDate, year (label year — CONVERSION year for renda-mais/educa-mais) and per-window stats; meta.missing lists catalog papers with no data in any window (e.g. just launched).
Caveats: this is a statistical description of published rates, NOT investment advice, a return forecast, or a recommendation — never present the ranking as "best bonds to buy". lastPercentile compares each paper against ITS OWN history only; a high percentile means the rate is high relative to that paper's past, nothing more. Comparing entries across families is meaningful only in that relative sense (a prefixado percentile reflects nominal rates; an ipca-mais percentile reflects real rates).
Rates are decimal fraction strings (same as price_history_series, simulate_bond, live_quotes_lookup).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Anchor date YYYY-MM-DD for all windows (inclusive end). Default: today (UTC). Set a past date to ask 'how did the ranking look on that day?'. | |
| side | No | Which rate to rank: 'investorBuy' (default — the rate at which the investor buys from the Treasury, the standard quoted rate) or 'investorSell' (sell-back rate). | |
| windows | No | Lookback windows ending at `to` (1-3, default ['1y']): '30d' | '90d' | '1y' | '5y' | 'max' (full history). The ranking is ordered by the FIRST window; extra windows add context (e.g. ['1y','max']). | |
| productId | No | Optional filter to a single product family. Omit to rank the whole active catalog. Only catalog families are rankable (no 'igpm-mais-com-juros-semestrais' — it has history but no active catalog entries). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only/idempotent, and the description adds meaningful behavioral detail well beyond that: percentiles are always actually published rates, lastPercentile is the share strictly below last, ranking is ordered by the first window, papers unavailable for the selected side are excluded, and the selic granularity caveat is disclosed. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative with no filler. It is front-loaded with purpose and usage, then parameter semantics, then caveats and output format notes, making it easy to scan. Every sentence contributes to correct selection or invocation.
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 complex ranking tool, it covers all relevant aspects: defaults, ordering, side availability, missing data via meta.missing, decimal string format, and important caveats about not presenting ranking as advice. The output schema exists, so return-value explanation is unnecessary, and the description still summarizes key output semantics.
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%, yet the description adds significant meaning: windows ordering semantics, investorBuy meaning 'STN's Taxa de Compra', productId restricting to rankable families only, and `to` as an inclusive anchor for historical looks. Each parameter's behavior is fully elaborated beyond the raw 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?
Description opens with a specific verb-resource pair: 'Ranks every bond in the active Tesouro Direto catalog by where its latest published rate sits within its own history — in ONE call.' It also explicitly contrasts with price_history_series, so the agent can distinguish this tool without opening other definitions.
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?
Provides explicit when-to-use scenarios with example questions and a direct exclusion: 'Do NOT loop price_history_series per paper for that.' Also routes igpm-mais-com-juros-semestrais users to price_history_series, leaving no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a time series or aggregate statistics for a single Tesouro Direto bond over a date range.
Required paper selector: this tool queries ONE bond, not a whole product family. Always provide exactly one of maturityDate, maturityYear, or conversionYear. Use conversionYear only for renda-mais / educa-mais; for Prefixado/IPCA+/Selic/IGPM use maturityDate or maturityYear. If the user did not specify a maturity, call catalog_list first or ask for the maturity.
Two modes via aggregate:
'none' (default): raw daily points, each with investorBuy: { rate, price } and investorSell: { rate, price }. Sub-sample with step: 'daily' / 'weekly' / 'monthly'. Max 10000 points; truncated=true if exceeded. Optional pagination: limit (1-200) + offset + order ('asc'|'desc') — response then carries meta.page { total, offset, limit } and the 10000-point cap does not apply.
'stats': per side (investorBuy / investorSell) over the window: min/max/avg/count for rate and price, plus rate-only percentiles p25/p50/p75 (nearest-rank — actually published values), last (most recent rate) and lastPercentile (0-100: share of the window strictly below last). Compact single-object response — prefer this for "is today's rate high?" questions.
Field semantics:
investorBuy — investor PURCHASE side (STN's Taxa de Compra / PU de Compra). This is the standard quoted rate.
investorSell — investor SELL-BACK side (STN's Taxa de Venda / PU de Venda). Normally investorSell.rate > investorBuy.rate.
Use when the user asks for a time series or aggregate stats (e.g. rate evolution over 12 months, min/max rate in a year).
Rates are decimal fraction strings (same as price_history_lookup, simulate_bond, live_quotes_lookup).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Inclusive end date YYYY-MM-DD. | |
| from | Yes | Inclusive start date YYYY-MM-DD. | |
| step | No | Sub-sampling for raw series: 'daily' (every point), 'weekly' (last point of each ISO week), 'monthly' (last point of each calendar month). Ignored when aggregate='stats'. Default 'daily'. | |
| limit | No | Page size (1-200) for paginated raw series. When present the response carries meta.page { total, offset, limit } and the 10000-point cap does not apply. Ignored when aggregate='stats'. | |
| order | No | Sort by referenceDate: 'asc' (default) or 'desc' (most recent first — useful with limit/offset pagination). Ignored when aggregate='stats'. | |
| offset | No | Number of points to skip (pagination, default 0). Only meaningful together with `limit`. Ignored when aggregate='stats'. | |
| aggregate | No | 'none' (default) returns raw daily points with investorBuy + investorSell per row. 'stats' returns min/max/avg/count per side over the whole window. | |
| productId | Yes | Canonical product id (e.g. 'ipca-mais', 'selic'). For valid ids see PRICE_HISTORY_PRODUCT_IDS. | |
| maturityDate | No | Bond vencimento YYYY-MM-DD. Exactly one of maturityDate, maturityYear, or conversionYear. | |
| maturityYear | No | Calendar year of vencimento (2002-2100). Use exactly one of maturityDate, maturityYear, or conversionYear (Renda+/Educa+). When multiple papers share the product+year, the earliest maturityDate is returned. | |
| conversionYear | No | Renda+/Educa+ only: conversion (label) year, e.g. 2027 for 'Educa+ 2027'. Use exactly one of maturityDate, maturityYear, or conversionYear. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses the 10,000-point cap with truncation, pagination behavior with meta.page, exact output structure per mode, and the detail that rates are decimal fraction strings. It even clarifies percentile method ('nearest-rank'). No contradictions.
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 long but organized into labeled sections (Required paper selector, Two modes, Field semantics). It is front-loaded with the main purpose, and every detail supports selection or invocation. No filler.
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 11 parameters, two modes, and an output schema, the description is exhaustive: it covers selection criteria, mode differences, output shapes, truncation, pagination, and recommended use cases. The output schema already defines return structure, but the description goes beyond it.
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?
Although the schema already covers all 11 parameters, the description adds crucial semantics: the 'exactly one of maturityDate, maturityYear, or conversionYear' selector rule with bond-type-specific guidance, mode-specific parameter behavior (e.g. step/limit/offset ignored when aggregate='stats'), and the 10,000-cap exception when pagination is used.
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 opens with a specific verb+resource: 'Returns a time series or aggregate statistics for a single Tesouro Direto bond over a date range.' It explicitly distinguishes itself from sibling tools by stating 'this tool queries ONE bond, not a whole product family,' which prevents confusion with price_history_lookup/ranking.
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 states 'Use when the user asks for a time series or aggregate stats' and provides selection rules for maturity selectors, including 'If the user did not specify a maturity, call catalog_list first or ask.' It also instructs to prefer stats mode for 'is today's rate high?' questions, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulates a hypothetical Tesouro Direto bond operation at a given trade date and rate, returning the full set of metrics for that operation: price (PU), quotation, Macaulay/modified duration, and optionally the cash-flow schedule (coupons or installments).
USE THIS for ANY question about a Tesouro Direto bond — price, quotation, duration, sale proceeds, payment schedule, etc. Single tool, all metrics. Bulk: up to 10 items per request (5 if any item sets includeSchedule).
Output is discriminated by productFamily ('prefixado' | 'ipca' | 'renda-educa' | 'selic'). The schedule field defaults to null to keep responses compact (a Renda+ schedule alone has 240 entries). It comes populated as [{ date, businessDays, flow, cashFlowBrl, presentValue, kind, number? }] (kind: 'coupon' | 'principal' | 'installment') — flow is the nominal cash flow before discounting (STN-style flow, not a currency amount); semantics depend on kind. cashFlowBrl is BRL per one bond unit (face 1000): flow/100 × settlement snapshot of 1000 / vnaProjected / vniProjected, truncated to centavos (T-2 floor) — not a forecast of BRL actually credited on each payment date for indexed families (VNA on IPCA+ with coupons, VNI on Renda+/Educa+; both move with IPCA accrual); discounted sum of cashFlowBrl may differ slightly from PU (T-6). Only when the caller passes includeSchedule: true AND the bond family supports a schedule (zero-coupon families like prefixado / ipca-mais / selic never have one). Whenever a field is null, a structured warning in meta.warnings[] with code and field explains why.
Every response also carries a calculation object (discriminated by kind: 'prefixado-zero' | 'prefixado-semestrais' | 'ipca' | 'renda-educa' | 'selic') with the intermediate values used by the engine — business days to maturity, truncated discount exponent, discount factor, VNA/VNI base + projected, IPCA monthly rate, and (when auto-fetched) automaticIpcaValidFrom. For IPCA-linked families the indexProjection also splits the two projection legs: monthsBeyondVnaBase / monthsCompounded / compoundedFactor (the whole-month forward compounding) versus exponent (the sub-month pro-rata). On Tesouro Selic the calculation carries vnaProjected (the VNA the price discounts, truncated to 6 decimals), selicTarget (the Copom target standing in for the fixings not yet published) and an indexProjection with lastFixing / base / projectedBusinessDays. Use it to audit a price against the official methodology without re-running it.
Tesouro Selic (LFT) is priced off its VNA rather than a fixed face of 1000: annualRate there is the SPREAD over the Selic (ágio/deságio), routinely near zero and often negative (e.g. '-0.0002'), never the Selic rate itself. Because the VNA closes on the last published fixing and is projected to settlement at the Copom target, the trade date matters on top of the settlement date — a D+0 sale projects nothing, a D+1 purchase projects one business day.
Inputs: tradeDate (YYYY-MM-DD) is the negotiation date — NOT the settlement date. side ('investorBuy' | 'investorSell', optional but recommended when direction is known): semantic intent of the operation. When provided, the engine derives the correct settlementConvention automatically — 'investorBuy' -> 'D+1'; 'investorSell' -> 'D+0' if tradeDate >= 2021-09-13 (same-day sell-back rule), else 'D+1'. Omit side when simulating for pure pricing purposes without a specific trade direction. settlementConvention ('D+0' | 'D+1', optional): advanced override — when omitted, the engine derives from side (or defaults to 'D+1' when both are omitted). If both side and settlementConvention are provided and conflict, the explicit settlementConvention is used and a NONSTANDARD_SETTLEMENT_FOR_SIDE warning is emitted. The response echoes side (when provided), settlementConvention (resolved), and settlementDate. includeSchedule (default false) opts in to coupon/installment detail. annualRate MUST be a decimal string (e.g. '0.1423' for 14.23%, never '14.23'). Bond identification: prefixado/IPCA+/Selic require maturityDate; Renda+/Educa+ require conversionYear OR maturityYear. Optional overrides: vnaBase+ipcaMonthlyRate for IPCA+ types, vniBase+ipcaMonthlyRate for Renda+/Educa+ (auto-fetched if omitted). ipcaMonthlyRate is the current-month ANBIMA projection used ONLY for the sub-month pro-rata — it does NOT compound whole months forward. For a future-dated valuation (settlement months/years ahead), pass ipcaForwardMonthlyRate (assumed monthly IPCA) to project the VNA/VNI base forward over the whole-month gap; it is ignored when vnaBase/vniBase is overridden. Note ipcaForwardMonthlyRate and annualRate are orthogonal assumptions: the forward rate is the inflation that grows the VNA/VNI base, while annualRate is the REAL yield (the '+X%' of IPCA+X%) that discounts it — for IPCA-linked types it does NOT include inflation. A future-dated valuation needs BOTH set to the future scenario; passing ipcaForwardMonthlyRate with today's annualRate models future inflation at today's real yield.
Warning catalog (meta.warnings[], each { code, field?, message }): NONSTANDARD_SETTLEMENT_FOR_SIDE (both side and settlementConvention were provided and the explicit convention differs from the standard for that side — explicit value was used); SYNTHESIZED_BOND (bond not in catalog, synthesized for historical simulation); SETTLEMENT_BEFORE_LAUNCH (settlement predates the bond's launch date); IPCA_STALE (auto IPCA projection is over 35 days old vs settlement); IPCA_PROJECTION_MISSING (historical settlement before the earliest bundled IPCA projection — engine falls back to ipcaMonthlyRate=0, using the VNA of the nearest past day-15 without pro-rata; pass an explicit ipcaMonthlyRate for better precision); IPCA_FORWARD_RATE_IGNORED (both a vnaBase/vniBase override and ipcaForwardMonthlyRate were supplied — the override is authoritative so the forward rate was ignored); IPCA_FORWARD_GAP_NOT_COMPOUNDED (settlement is N whole months beyond the last published VNA/VNI and no ipcaForwardMonthlyRate was supplied — the gap was NOT compounded onto the base, only the sub-month pro-rata; pass ipcaForwardMonthlyRate for a future-dated valuation, or refresh bundled VNA data if the settlement is actually near-term); SUSPICIOUS_RATE (annualRate > 1.0 — likely passed as percentage); CALENDAR_LAW_SWITCH (tradeDate predates Lei 14.759/2023; legacy calendar without Nov 20 holiday is in use); TRADE_DATE_NON_BUSINESS_DAY (tradeDate is a weekend, holiday, or market interruption — settlement was rolled forward to the next business day, so D+0 and D+1 may resolve to the same date); NOT_INCLUDED (field could exist but caller did not request it — set the matching include* flag, e.g. schedule on coupon/stream families); CASHFLOW_BRL_SETTLEMENT_VNA_SNAPSHOT (only when includeSchedule: true for bondType ipca-mais-com-juros-semestrais — each schedule[].cashFlowBrl uses the settlement VNA snapshot; see message); CASHFLOW_BRL_SETTLEMENT_VNI_SNAPSHOT (only when includeSchedule: true for bondType renda-mais or educa-mais — each schedule[].cashFlowBrl uses the settlement VNI snapshot; see message); NOT_AVAILABLE_FOR_OPERATION (the provided side is not among the bond's current availableFor sides in the catalog, e.g. investorBuy on a bond withdrawn from new offerings and now sell-only — the simulation still runs as a hypothetical scenario, it is not blocked).
All values are pre-tax (gross), based on hypothetical inputs — this is a simulation, NOT a real-time market quote nor an offer to trade. IR and IOF apply on actual operations. Each bulk row returns { input, ok: true, result } or { input, ok: false, error }.
Before calling, use catalog_list if you need to discover available bonds or disambiguate the user's reference.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of pricing rows. Max 10 items (default), or max 5 when any row sets includeSchedule=true (schedule entries can be hundreds per row for Renda+/Educa+). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses that this is a simulation, not a real-time market quote or offer to trade, and that values are pre-tax gross with IR/IOF applying to actual operations. It additionally explains default behavior (schedule defaults to null), warning catalog semantics, and subtle calculation behaviors like VNA-based Selic pricing and non-compounding of forward IPCA gaps — far exceeding annotation coverage.
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 long, but its length is earned by the tool's complexity: it covers input semantics, output discrimination, calculation internals, a full warning catalog, and bulk behaviors. It is front-loaded with a crisp summary and then layers detail logically. A few points duplicate the input schema (e.g., settlementConvention rules), so it is not maximally tight, but no part is fluff.
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?
Given the tool's high complexity, the description is remarkably complete: it documents the discriminated output by productFamily, the schedule entry shape and semantics, the calculation object fields, cash-flow truncation rules, warning codes with meanings, and edge cases like tradeDate non-business-day rolling. An agent has everything needed to call the tool correctly and interpret its response even without opening the output schema.
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?
Although the input schema already has 100% parameter coverage, the description adds substantial meaning beyond it: annualRate must be a decimal string ('0.1423', never '14.23'), tradeDate is the negotiation date rather than settlement date, side and settlementConvention derivation rules, and the distinction between ipcaMonthlyRate and ipcaForwardMonthlyRate. This is exactly the kind of semantic guidance that prevents misparameterization.
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 opens with a precise verb and resource: 'Simulates a hypothetical Tesouro Direto bond operation at a given trade date and rate,' and enumerates the returned metrics (price PU, quotation, durations, optional cash-flow schedule). It also declares itself the single tool for all Tesouro Direto bond pricing questions, which clearly differentiates it from siblings like live_quotes_lookup and simulate_redemption.
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 explicitly directs usage: 'USE THIS for ANY question about a Tesouro Direto bond — price, quotation, duration, sale proceeds, payment schedule, etc.' and includes practical constraints such as bulk limits and when includeSchedule is worth the payload. It only names catalog_list as a prerequisite for discovery, but does not document when a sibling (e.g., simulate_redemption) should be chosen instead, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulates an early redemption: a historical acquisition lot (lot) and a hypothetical sell (sell), returning gross sale pricing plus netReturns (IOF, regressive IR, B3 custody) and annualized gross/net rates (du/252).
USE THIS for "quanto recebo líquido se vender?", IR/IOF/custódia on a held lot, or comparing gross vs net redemption proceeds.
lot takes exactly one of price (exact PU — preferred, from the B3 statement) or rate (decimal string; engine derives PU). sell takes rate only (sell by price is not supported). Optional per-leg IPCA scenario: vnaBase/vniBase/ipcaMonthlyRate. For a future-dated sell (redemption months/years ahead), also pass sell.ipcaForwardMonthlyRate (assumed monthly IPCA) to project the VNA/VNI base forward over the whole-month gap — otherwise the base stays frozen at the last published day-15 and an IPCA_FORWARD_GAP_NOT_COMPOUNDED warning is emitted. lot settles D+1; sell uses Tesouro sell-back conventions (D+0 when tradeDate >= 2021-09-13).
Coupons/installments between lot and sell are NOT tax-modeled (INTERMEDIATE_FLOWS_TAX_NOT_MODELED). On Tesouro Selic the custody fee is always charged in full: B3 waives it up to R$ 10,000.00 of Selic holdings, but that depends on the investor's total position rather than on this lot (CUSTODY_EXEMPTION_NOT_MODELED). Tax/fee estimate — not investment or tax advice. Bulk: up to 10 items.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Early-redemption scenarios (max 10 per request). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/destructive hints), the description discloses substantial behavior: D+1 lot settlement vs the D+0 Tesouro sell-back convention post-2021-09-13, the IPCA_FORWARD_GAP_NOT_COMPOUNDED warning when a future-dated sell omits the forward rate, the INTERMEDIATE_FLOWS_TAX_NOT_MODELED gap for coupons, the CUSTODY_EXEMPTION_NOT_MODELED limitation with its R$ 10,000.00 cause, and a tax-advice disclaimer. These are real interpretive contexts, not just restatements of the read-only annotation.
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 roughly 220 words — long — but the tool is complex (nested legs, settlement conventions, IPCA scenarios, modeling warnings) and each sentence carries distinct information. It is well-structured: purpose first, then usage triggers, per-leg field guidance, modeling caveats, disclaimer, and bulk limit, with the core purpose front-loaded.
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 tool with an output schema and a fully described parameter schema, the description fills every remaining behavioral gap: settlement conventions, known tax-modeling blind spots by warning code, forward-IPCA projection behavior, the 10-item bulk limit, and the estimate disclaimer. An agent has everything needed to invoke it correctly and interpret warnings without missing context.
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% and the schema already documents the price/rate exclusivity and forward-IPCA field, so the baseline is 3. The description adds meaningful interpretation beyond it: which input to prefer (exact PU from the B3 statement), the explicit constraint that the sell leg is rate-only ('sell by price is not supported'), and the conditional rule for when `ipcaForwardMonthlyRate` is required. That extra layer justifies a 4.
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 opening sentence states a specific verb ('Simulates an early redemption'), names the exact inputs (a historical acquisition `lot` vs a hypothetical `sell`), and the return shape (gross sale pricing, `netReturns` with IOF/IR/custody, annualized gross/net rates). This scope is clearly distinct from the sibling `simulate_bond`, which is about bond simulation rather than redemption net-of-tax analysis.
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 explicit usage triggers prefixed with 'USE THIS' — Portuguese queries ('quanto recebo líquido se vender?'), the IR/IOF/custódia-on-a-held-lot scenario, and gross-vs-net comparison. What it lacks is an explicit exclusion or named alternative (e.g., 'use simulate_bond instead when...'), so the when-not-to-use guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
price_history_ranking2 fields changedInput schema / properties / productId / descriptionPrevious value: -"Optional filter to a single product family. Omit to rank the whole active catalog. Only catalog families are rankable (no 'selic' / 'igpm-mais-com-juros-semestrais' — those have history but no active catalog entries)."New value: +"Optional filter to a single product family. Omit to rank the whole active catalog. Only catalog families are rankable (no 'igpm-mais-com-juros-semestrais' — it has history but no active catalog entries)."Input schema / properties / productId / enumPrevious value: -[
- "prefixado",
- "prefixado-com-juros-semestrais",
- "ipca-mais",
- "ipca-mais-com-juros-semestrais",
- "renda-mais",
- "educa-mais"
-]New value: +[
+ "prefixado",
+ "prefixado-com-juros-semestrais",
+ "ipca-mais",
+ "ipca-mais-com-juros-semestrais",
+ "renda-mais",
+ "educa-mais",
+ "selic"
+]simulate_bond1 field changedInput schema / properties / items / items / properties / bondType / enumPrevious value: -[
- "prefixado",
- "prefixado-com-juros-semestrais",
- "ipca-mais",
- "ipca-mais-com-juros-semestrais",
- "renda-mais",
- "educa-mais"
-]New value: +[
+ "prefixado",
+ "prefixado-com-juros-semestrais",
+ "ipca-mais",
+ "ipca-mais-com-juros-semestrais",
+ "renda-mais",
+ "educa-mais",
+ "selic"
+]simulate_redemption2 fields changedInput schema / properties / items / items / properties / bondType / enumPrevious value: -[
- "prefixado",
- "prefixado-com-juros-semestrais",
- "ipca-mais",
- "ipca-mais-com-juros-semestrais",
- "renda-mais",
- "educa-mais"
-]New value: +[
+ "prefixado",
+ "prefixado-com-juros-semestrais",
+ "ipca-mais",
+ "ipca-mais-com-juros-semestrais",
+ "renda-mais",
+ "educa-mais",
+ "selic"
+]Input schema / properties / items / items / properties / maturityDate / descriptionPrevious value: -"Bond maturity YYYY-MM-DD. Required for date-identified bonds (prefixado, IPCA+)."New value: +"Bond maturity YYYY-MM-DD. Required for date-identified bonds (prefixado, IPCA+, Selic)."indicator_history2 fields changedInput schema / properties / indicator / descriptionPrevious value: -"Which reference series to return. `selic-target` is the Selic target rate set by the Copom (Banco Central)."New value: +"Which reference series to return. `selic-target` is the Selic target rate set by the Copom (Banco Central), annual. `ipca-monthly` is the IPCA published by the IBGE, monthly — the realized index, not the projection used in pricing."Input schema / properties / indicator / enumPrevious value: -[
- "selic-target"
-]New value: +[
+ "selic-target",
+ "ipca-monthly"
+]indicator_historyprice_history_series1 field changedInput schema / properties / limit / descriptionPrevious value: -"Page size (1-200) for paginated raw series. When present the response carries meta.page { total, offset, limit } and the 1000-point cap does not apply. Ignored when aggregate='stats'."New value: +"Page size (1-200) for paginated raw series. When present the response carries meta.page { total, offset, limit } and the 10000-point cap does not apply. Ignored when aggregate='stats'."simulate_redemption1 field changedInput schema / properties / items / items / properties / sell / properties / ipcaForwardMonthlyRateAdded value: +{
+ "description": "Assumed monthly IPCA to project the VNA/VNI base FORWARD over the whole months between the last published day-15 and this leg's settlement, before the sub-month pro-rata. Use for a future-dated sell (settlement months/years ahead); omit for near-term. Ignored when vnaBase/vniBase is overridden. Distinct from ipcaMonthlyRate (the current-month pro-rata).",
+ "pattern": "^-?\\d+(\\.\\d+)?$",
+ "type": "string"
+}simulate_bond2 fields changedInput schema / properties / items / items / properties / ipcaForwardMonthlyRateAdded value: +{
+ "description": "Assumed monthly IPCA (decimal) used to project the VNA/VNI base FORWARD over the whole months between the last published day-15 and the settlement month, before the sub-month pro-rata. Only for IPCA-linked types. Opt-in: omit for spot/near-term pricing (identical to today). Ignored when vnaBase/vniBase is overridden (the override is authoritative). Distinct from ipcaMonthlyRate — they may hold different values.",
+ "pattern": "^-?\\d+(\\.\\d+)?$",
+ "type": "string"
+}Input schema / properties / items / items / properties / ipcaMonthlyRate / descriptionPrevious value: -"Monthly IPCA rate as decimal. Only for IPCA-linked types — auto-fetched by settlement date if omitted."New value: +"Monthly IPCA rate as decimal. Only for IPCA-linked types — auto-fetched by settlement date if omitted. This is the current-month ANBIMA projection used ONLY for the sub-month pro-rata within the settlement month; it does NOT compound whole months forward. For a future-dated valuation, use ipcaForwardMonthlyRate."simulate_redemptionprice_history_rankingcatalog_listlive_quotes_lookupprice_history_lookupprice_history_seriessimulate_bond
Add one secure layer between your agents and this server.