Brazil Macroeconomic and Financial Data AI Platform for AI agents.
Scored across 11 tools
Each tool has a clearly distinct purpose: Focus revisions, breakeven inflation, actuals, calendar, surprise, composite divergence, real/nominal curves, market-vs-focus comparison, Copom path, and Selic snapshot. Even the composite tool explicitly directs users to the component tools for one-dimensional needs, removing ambiguity.
Most tools follow a brazil_<domain>_<noun> pattern, but three use verb-prefixes (get_brazil_copom_path, get_brazil_selic_snapshot, compare_brazil_market_vs_focus), creating a mixed convention. The pattern is still readable and predictable enough to navigate, but it is not consistently applied.
11 tools is well within the ideal 3-15 range and matches the server's broad Brazil macro scope without feeling bloated. Every tool occupies a distinct niche, from yield curves and survey revisions to release calendars and a composite divergence assessment, so none feel redundant.
The set covers the primary Brazilian macro data workflows: actuals, release timing, consensus surprises, market-implied policy paths, nominal and real curves, breakevens, and survey revisions. Minor gaps exist—such as no direct Focus survey value tool or an FX spot/forward tool—but the core analytical surface is well covered.
Detects whether Brazilian economists are revising inflation (IPCA), policy-rate (Selic), growth (PIB Total) or FX (Câmbio) expectations, and measures the speed and dispersion of those revisions — 1-week, 4-week and 13-week changes in the Focus survey median, plus a deterministic rising/falling/stable direction and accelerating/ decelerating/stable speed classification (method_id focus_revisions_v1). Built directly on Focus historical vintages — never recalculates a past date using data published after it.
Use when: assessing sentiment shifts among professional economists for
Brazil's main macro indicators, or whether a recent revision is
speeding up or slowing down.
Do not use when: you want market-implied pricing (use
get_brazil_copom_path) or a market-vs-consensus comparison (use
compare_brazil_market_vs_focus) — this tool is Focus-survey-only.
Units are NOT always basis points — check the `unit` field in the
response (bps for Selic/IPCA, percentage_points for PIB Total, BRL for
Câmbio).
Args:
indicator: one of "Selic", "IPCA", "PIB Total", "Câmbio".
reference_period: e.g. "2027" (the forecast year). Defaults to the
current year.
segment: "general" (all respondents) or "top5". Never mixed.
as_of: optional YYYY-MM-DD date. Defaults to today.
payment_token: required in staging ($0.05/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| segment | No | general | |
| agent_id | No | ||
| indicator | Yes | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| reference_period | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and largely succeeds: it discloses the deterministic method (method_id focus_revisions_v1), the no-look-ahead data construction, the never-mixed segment rule, and the unit semantics. It stops short of explicit read-only/auth/rate-limit statements, but the described behavior is concrete and trustworthy.
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 dense but well-organized: a purpose paragraph, use/when guidance, unit warning, and an Args list. Every sentence adds value and the most decision-relevant 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 output schema exists, the description doesn't need to explain return values, but it still covers methodology, exclusions, units, and parameter semantics. The tool is complex enough that this level of context is necessary, and nothing essential for correct invocation is missing.
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 0%, and the description compensates strongly by explaining every user-facing parameter: allowed indicator values, reference_period format/default, segment options, as_of format/default, and payment_token cost/requirement. Even without schema descriptions, an agent can construct a valid call and understand constraints like 'Never mixed'.
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 ('Detects') and a precise target ('whether Brazilian economists are revising inflation (IPCA), policy-rate (Selic), growth (PIB Total) or FX (Câmbio) expectations'), then names the exact outputs (speed, dispersion, direction, classification). It also distinguishes itself as Focus-survey-only, which separates it from siblings like get_brazil_copom_path.
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 'Use when' and 'Do not use when' sections tell the agent exactly when to select this tool and name two alternative tools with their distinct purposes. The additional 'never recalculates a past date using data published after it' warning clarifies a critical data-correctness precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market-implied Brazilian inflation breakeven — Fisher's EXACT
identity ((1+nominal)/(1+real) - 1), never the linear approximation —
computed only where the nominal and real curves both have support at
the same tenor (method_id breakeven_fisher_v1). Returns
nominal_zero_rate_pct and real_zero_rate_pct alongside the
breakeven so the result is auditable.
IMPORTANT: this is NOT "expected inflation" — it embeds risk premium,
liquidity and convexity effects. The response field is deliberately
named `market_implied_inflation_breakeven`.
Use when: assessing what the market is pricing for future inflation,
as distinct from Focus survey expectations (use
brazil_focus_revisions with indicator="IPCA" for that).
Do not use when: you need either curve alone (use brazil_yield_curve /
brazil_real_curve).
Args:
as_of: optional YYYY-MM-DD. Defaults to today.
tenors: comma-separated subset of 1Y,2Y,3Y,5Y,7Y,10Y. Default: all.
quote_side: "buy", "sell", or "mid" (default).
payment_token: required in staging ($0.03/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| tenors | No | ||
| agent_id | No | ||
| quote_side | No | mid | |
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses the exact identity used, the fact that this is not 'expected inflation', the risk premium/liquidity/convexity caveat, the support condition on both curves, and the auditable output fields.
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 organized with a compact definition, key caveat, usage instructions, and an Args section, with no redundant filler. Every section adds decision-relevant information and the most important scoping details are 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?
The tool has no annotations, but the description covers the computation, scope, alternatives, parameter semantics, output fields, and pricing in one place. Since an output schema exists, lack of detailed return-value documentation is acceptable, and nothing essential for correct invocation is missing.
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 descriptions are entirely absent, so the description compensates by documenting as_of, tenors, quote_side, and payment_token with formats, defaults, and restrictions. However, four schema parameters (agent_id, session_id, discovery_source, synthetic_identity) are not addressed in the description, though they appear to be common context fields.
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 identifies a specific resource (Brazilian inflation breakeven), the exact computation (Fisher's exact identity), and the condition under which it is computed. It also names the deliberate response field, distinguishing this tool from related curve and survey tools.
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 an explicit 'Use when' section that directs agents to this tool for market-implied inflation pricing and points to brazil_focus_revisions for Focus survey expectations. A 'Do not use when' clause names brazil_yield_curve and brazil_real_curve as the correct alternatives for standalone curves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a Brazilian macro headline actual (IPCA, IPCA-15, GDP, PIM-PF industrial production, PMC retail sales, PMS services volume, or PNAD Contínua unemployment) with full release-vintage provenance — built on a release/vintage layer that NEVER overwrites an original published number when a later revision arrives (method_id macro_actual_v1).
Use when: you need the current headline reading for a Brazilian macro
indicator, or (via `vintage`) what was known at a specific historical
instant vs. what is currently the revised/correct value.
Do not use when: you want the surprise vs. consensus (use
brazil_macro_surprise, IPCA only) or the release schedule (use
brazil_macro_calendar).
Args:
indicator: one of IPCA, IPCA15, GDP, PIM_PF, PMC, PMS, PNAD_UNEMPLOYMENT.
reference_period: e.g. "2026-07" (monthly) or "2026-Q2" (GDP).
as_of: YYYY-MM-DD, REQUIRED when vintage="as_known".
vintage: "latest" (currently-correct value, default), "first"
(original release, revision_number=0), or "as_known" (what was
known publicly at `as_of`).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| vintage | No | latest | |
| agent_id | No | ||
| indicator | Yes | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| reference_period | Yes | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does it well: it discloses the never-overwrite revision policy, defines latest/first/as_known vintage modes, and explains that as_known means what was publicly known at a date. It stops short of discussing access/payment or read-safety explicitly, though 'Returns' and the non-overwrite policy strongly imply a read-only operation.
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 prose is dense but each sentence earns its place: purpose, provenance guarantee, usage rules, and argument semantics are separated into clear blocks. The most important scope and exclusion information is front-loaded before the arg list.
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 nine parameters and non-trivial vintage semantics, the description explains the core selection and versioning behavior completely. An output schema is present, so detailed return-value documentation is not the description's responsibility; the remaining gaps are only generic bookkeeping parameters.
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 0%, so the description must compensate. It lists all valid indicator values, gives concrete reference_period formats for monthly and quarterly, and clarifies as_of as required only for vintage='as_known'. The remaining optional/metadata parameters (agent_id, session_id, payment_token, etc.) are left for the agent to infer from names, but they are not central to the tool's behavior.
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 ('Returns a Brazilian macro headline actual') and enumerates the exact indicators covered. It also differentiates from siblings by naming the surprise and calendar tools it is not, so an agent can route correctly.
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 'Use when' and 'Do not use when' guidance, including which sibling to use for consensus surprises and release schedules. This gives an agent clear decision criteria beyond the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official IBGE release calendar for Brazilian macro indicators (IPCA, IPCA-15, GDP, PIM-PF, PMC, PMS, PNAD Contínua unemployment), with status transitions scheduled -> released -> corrected.
Use when: you need to know when the next release of a Brazilian macro
indicator is scheduled, or whether a given period has been released yet.
Args:
event: optional filter to one indicator (e.g. "IPCA"). Omit for all.
upcoming_only: if true (default), only events not yet released.
limit: max events returned (default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | ||
| limit | No | ||
| agent_id | No | ||
| session_id | No | ||
| payment_token | No | ||
| upcoming_only | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it discloses that statuses transition through scheduled -> released -> corrected and that upcoming_only defaults to true. It does not mention output shape or any limits/rate constraints, but for a read-only calendar tool the disclosed status model is the most important behavior.
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 compact and front-loaded: purpose, status behavior, usage condition, and the three meaningful parameters. There is no filler or redundant 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?
For a simple calendar query tool, the description gives enough context: source, coverage, status transitions, and core parameters, while the output schema covers return values. The main missing piece is guidance on the five auxiliary parameters, which prevents full completeness.
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 Args section adds meaning for event, upcoming_only, and limit beyond the bare schema. However, schema description coverage is 0% and five other parameters (agent_id, session_id, payment_token, discovery_source, synthetic_identity) are left undocumented, so the description only partially compensates for the schema gap.
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 identifies a concrete resource ('Official IBGE release calendar for Brazilian macro indicators') and lists the covered indicators, then states the intended query ('when the next release ... is scheduled, or whether a given period has been released yet'). This makes it easy to distinguish from sibling tools like brazil_macro_actual or brazil_macro_surprise, which concern data values rather than the release schedule.
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 'Use when' sentence provides explicit conditions: knowing next release timing or checking whether a period has been released. It does not name alternative sibling tools or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a Brazilian macroeconomic release with the latest public consensus that was available before the release, with full vintage and source provenance (method_id macro_surprise_v1). The consensus is ALWAYS the last Focus survey reading published strictly before the official release timestamp — never a reading published after it, and the actual is always the FIRST release, never a later revision.
IMPORTANT: only computed for indicators with a methodologically valid,
event-specific public consensus — currently IPCA only. GDP/PIM-PF/PMC/
PMS/PNAD_UNEMPLOYMENT raise an error rather than fabricate a consensus
(use brazil_macro_actual for those — actual/momentum only, no surprise).
Args:
indicator: currently only "IPCA" is eligible.
reference_period: e.g. "2026-07".
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | No | ||
| indicator | Yes | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| reference_period | Yes | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It discloses that the consensus must be strictly before the release timestamp, the actual must be the first release never a revision, and unsupported indicators raise an error rather than fabricate a consensus. This is rich, actionable behavioral context.
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 and front-loaded with the main purpose, followed by important timing rules and error behavior. It is slightly redundant by stating IPCA eligibility twice, but every section serves a clear purpose and the length is justified by the tool's edge cases.
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 correct invocation: it covers eligibility, alternatives, timing semantics, and error behavior. Since an output schema exists, return-value details are not needed. It could mention edge cases like a missing consensus for a given reference period, but nothing essential for calling the tool is missing.
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 0%, and the description compensates for the two required parameters: indicator is constrained to 'IPCA' and reference_period is given a format example ('2026-07'). The five optional parameters are not explained, but their titles and defaults make their purpose largely self-evident, so the gap is minor.
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 verb and resource: compare a Brazilian macroeconomic release with the latest prior public consensus, with vintage/provenance details and method_id macro_surprise_v1. It also differentiates from brazil_macro_actual and is clearly distinct from the sibling tools.
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 explicitly says when to use the tool (IPCA only), when not to use it (GDP/PIM-PF/PMC/PMS/PNAD_UNEMPLOYMENT), and names the alternative tool (brazil_macro_actual). It also defines the precise consensus timing rule, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess divergence between Brazilian market-implied monetary policy, economist expectations, inflation breakevens and realized inflation surprises, using point-in-time public data with full provenance (method_id monetary_policy_divergence_v1).
Consumes ONLY the already-homologated capability layer (market-vs-Focus
meeting gaps, Focus Selic/IPCA 4-week revisions, the 5Y inflation
breakeven and its 20-business-day change, and the latest eligible IPCA
surprise) — never recomputes those engines and never fabricates a
number a component doesn't support. Each of the 5 evidence components
gets its own deterministic classification (strong_dovish..strong_
hawkish) with a versioned threshold set (threshold_version
B4_THRESHOLDS_V1), quality-weighted by the underlying engine's own
quality_status. `overall_signal` is a QUALITATIVE composite
(strong_dovish/dovish/balanced/hawkish/strong_hawkish/
insufficient_evidence) — deliberately NOT a fabricated 0-100 score.
`evidence_agreement` (0-1) tells you separately whether the components
agree with each other, independent of the direction of the signal.
IMPORTANT: `product_validation_status` is "internal_validated_external_
pending" until C0's external benchmark passes (see
docs/C0_external_validation_protocol.md), then "validated" — several
inputs (the market-implied Copom path, the real/breakeven curve) are
themselves still individually pending external benchmark validation,
never hidden here. This is macro intelligence, NOT an investment
recommendation.
Use when: assessing whether Brazilian market pricing, economist
consensus, market-implied inflation and realized inflation data agree
or diverge on the direction of monetary policy pressure.
Do not use when: you need only one dimension — use
compare_brazil_market_vs_focus, brazil_focus_revisions,
brazil_inflation_breakeven, or brazil_macro_surprise directly.
Args:
as_of: optional YYYY-MM-DD date. Defaults to today.
horizon_meetings: must be 4 in v1 (the PolicyGap weighting
0.40/0.30/0.20/0.10 is fixed for exactly 4 meetings).
include_evidence: if true (default), include the full per-component
evidence table (value, signal, quality_status, weights,
validation status, source vintage).
payment_token: required in staging ($0.25/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| agent_id | No | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| horizon_meetings | No | ||
| include_evidence | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it is thorough: it discloses that the tool never recomputes underlying engines, never fabricates unsupported numbers, uses deterministic classifications with versioned thresholds, reports validation status including external-pending states, and is explicitly not an investment recommendation. It also mentions the payment token requirement and per-call pricing in staging.
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 well-structured: purpose is front-loaded, followed by methodology, caveats, usage guidance, and arguments. Some method detail is dense, but it earns its place given the analytical complexity and the absence of annotations or schema descriptions.
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 analytical tool with an output schema present, the description covers purpose, methodology, data provenance, validation caveats, compositing logic, parameter constraints, and alternatives. It is sufficiently complete for an agent to invoke the tool correctly and interpret its qualitative signal without additional external 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 description coverage is 0%, so the description must compensate. It adds useful meaning for as_of, horizon_meetings, include_evidence, and payment_token, including the fixed 4-meeting constraint and the default evidence table contents. However, it omits four schema parameters (agent_id, session_id, discovery_source, synthetic_identity), leaving them entirely unexplained.
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: 'Assess divergence between Brazilian market-implied monetary policy, economist expectations, inflation breakevens and realized inflation surprises.' It clearly distinguishes itself from siblings by name in the 'Do not use when' section, so an agent can tell it apart from tools like compare_brazil_market_vs_focus or brazil_focus_revisions.
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 explicit 'Use when' and 'Do not use when' guidance, naming concrete sibling alternatives for single-dimension needs. It also specifies that the tool consumes only the already-homologated capability layer and should not be called when only one dimension is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real (IPCA-linked) Brazilian sovereign zero-coupon curve, bootstrapped from Tesouro Direto NTN-B Principal (zero-coupon) and NTN-B (semi-annual real coupon) offered-security quotes. Built entirely from the bonds' own quoted real yields — no Focus/IPCA projection is used anywhere in this engine.
curve_scope = "tesouro_direto_offered_securities" (see brazil_yield_curve).
Note: Tesouro currently offers no short-dated real zero-coupon bond, so
this curve typically has NO coverage for 1Y/2Y tenors — check `status`
per tenor.
Use when: you need Brazil's real (inflation-protected) rate curve.
Do not use when: you need the nominal curve (brazil_yield_curve) or
breakeven inflation (brazil_inflation_breakeven).
Args:
as_of: optional YYYY-MM-DD. Defaults to today.
tenors: comma-separated subset of 1Y,2Y,3Y,5Y,7Y,10Y. Default: all.
quote_side: "buy", "sell", or "mid" (default).
payment_token: required in staging ($0.03/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| tenors | No | ||
| agent_id | No | ||
| quote_side | No | mid | |
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses the bootstrapping methodology, the exclusion of Focus/IPCA projections, the curve_scope, the typical lack of 1Y/2Y coverage, and the payment_token requirement with cost. This goes far beyond a generic 'get curve' statement.
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-organized with clear sections: what it is, a critical coverage caveat, usage guidance, and argument details. Every sentence adds value, and the most important differentiators are 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 data-retrieval tool with an output schema and no annotations, the description is complete: it covers methodology, coverage limitations, pricing, parameter behavior, and sibling alternatives. An agent has enough context to invoke it correctly without further inference.
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 0%, so the description must compensate. It clearly explains as_of, tenors, quote_side, and payment_token, including defaults, allowed values, and pricing. Four generic parameters (agent_id, session_id, discovery_source, synthetic_identity) are left undocumented, which keeps this from a 5.
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 precisely identifies the deliverable: an IPCA-linked Brazilian sovereign zero-coupon curve bootstrapped from Tesouro Direto NTN-B and NTN-B Principal quotes. It also explicitly distinguishes itself from brazil_yield_curve and brazil_inflation_breakeven in the use-when block, so an agent can select it unambiguously.
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 states when to use the tool ('you need Brazil's real rate curve') and explicitly says not to use it for the nominal curve or breakeven inflation, naming the sibling tools as alternatives. This is exactly the level of routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nominal Brazilian sovereign zero-coupon curve, bootstrapped from Tesouro Direto LTN (zero-coupon) and NTN-F (semi-annual coupon) offered-security quotes (method_id sovereign_zero_curve_bootstrap_v1).
curve_scope = "tesouro_direto_offered_securities": this is NOT an
institutional ANBIMA/Bloomberg ETTJ — it's derived from retail-offered
public securities, published as open data (ODbL license). Tenors
outside the curve's actual node coverage return
status="unsupported", never extrapolated.
Use when: you need Brazil's nominal risk-free curve shape or a
specific nominal zero rate.
Do not use when: you need the real (inflation-linked) curve (use
brazil_real_curve) or breakeven inflation (use
brazil_inflation_breakeven).
Args:
as_of: optional YYYY-MM-DD. Defaults to today.
tenors: comma-separated subset of 1Y,2Y,3Y,5Y,7Y,10Y. Default: all.
quote_side: "buy", "sell", or "mid" (default).
payment_token: required in staging ($0.01/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| tenors | No | ||
| agent_id | No | ||
| quote_side | No | mid | |
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden and does so thoroughly: it states the curve is retail-offered open data with ODbL license, not institutional, and that tenors outside node coverage return status='unsupported' and are never extrapolated. It also flags the required payment token, which is not visible in 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 dense but every sentence carries signal: definition, method, source caveat, unsupported-tenor behavior, usage guidance, and parameter details are all packed without redundancy. The Args section cleanly separates operational details from conceptual scope.
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 no annotations and an output schema that handles return-value documentation, the description fully equips an agent to decide when to call, what parameters to provide, and what behavior to expect, including non-extrapolation and payment requirement. No critical gap remains for correct invocation.
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 0%, and the description compensates for the key operational parameters: as_of format/default, tenors allowed values/default, quote_side options, and payment_token requirement. The remaining schema fields (agent_id, session_id, discovery_source, synthetic_identity) are not explained, but they appear to be generic infrastructure parameters.
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 noun phrase — 'Nominal Brazilian sovereign zero-coupon curve' — and adds the bootstrapping source (Tesouro Direto LTN/NTN-F), method ID, and an explicit exclusion of institutional ANBIMA/Bloomberg curves. This clearly differentiates it from siblings like brazil_real_curve and brazil_inflation_breakeven.
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 includes direct 'Use when' and 'Do not use when' guidance, naming the specific sibling tools for the real curve and breakeven inflation. This eliminates ambiguity about when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares the market-implied Copom path (DI1-derived) against the BCB Focus survey median, meeting-by-meeting (not just year-end), returning the gap in basis points per meeting and an overall dovish/hawkish classification (method_id market_vs_focus_meetings_v1).
Use when: assessing whether Brazilian rates markets are pricing more or
less monetary policy action than professional economists' consensus —
useful for research agents, news agents, or risk agents monitoring
Brazil-specific policy surprises.
Do not use when: you only need one side of the comparison (use
get_brazil_copom_path for market pricing alone, or Focus data directly
for consensus alone).
Args:
as_of: optional YYYY-MM-DD date. Defaults to today.
horizon: number of upcoming Copom meetings to compare (1-8, default 4).
payment_token: required in staging ($0.15/call per pricing.yaml).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| horizon | No | ||
| agent_id | No | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It discloses the comparison logic, output granularity, classification label, method_id, and per-call pricing context. It does not discuss failure modes or data caveats, but the read-only comparative nature is clear and adequately transparent.
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 tightly written and front-loaded: the core comparison is in the first sentence, usage guidance follows immediately, and the Args list is compact. Every sentence adds information 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 an output schema present, the description already covers the essentials: what is compared, when to use it, when not to, and the key parameters. The main completeness gap is the undocumented metadata parameters and the slight payment_token/schema mismatch, but these are minor given the strong overall 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?
Even though schema description coverage is 0%, the Args block adds real meaning for as_of (format and default), horizon (range 1-8 and default 4), and payment_token (staging requirement and pricing). However, four schema parameters—agent_id, session_id, discovery_source, and synthetic_identity—are not explained, and the conditional 'required in staging' wording could be ambiguous against a schema that marks payment_token optional.
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 exact comparison ('market-implied Copom path (DI1-derived)' vs 'BCB Focus survey median'), the meeting-by-meeting granularity, and the return shape (basis-point gaps plus dovish/hawkish classification). It also names a sibling tool, get_brazil_copom_path, which helps distinguish it from adjacent tools.
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 an explicit 'Use when' section that frames the decision context for research/news/risk agents, and an explicit 'Do not use when' section that routes to the correct alternative for single-sided needs. This is exactly the kind of decision guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns market-implied Brazilian Selic expectations for upcoming Copom meetings, derived from B3 DI1 futures via a meeting-step bootstrap (method_id copom_path_di1_v1). Each entry gives the implied Selic level and the implied change in basis points for that specific meeting date — not rounded to 25bp increments.
Use when: estimating expected BCB policy changes, the terminal rate, or
cumulative easing/tightening priced by the market over the next 1-8
Copom meetings.
Do not use when: you want economists' survey expectations instead of
market pricing (use brazil_focus_revisions) or a direct comparison
between the two (use compare_brazil_market_vs_focus).
Limitations: requires liquid DI1 data for the as_of date's most recent
trading day; DU counts use the validated B3 trading calendar (A6.1).
Args:
as_of: optional YYYY-MM-DD date. Defaults to today.
meetings: number of upcoming Copom meetings to return (1-8, default 4).
agent_id, session_id, discovery_source: optional C1 telemetry fields.
payment_token: required in staging for this priced capability
($0.10/call per pricing.yaml) — omit to get the simulated
payment_required response instead of a result.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| agent_id | No | ||
| meetings | No | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does: it discloses the bootstrap source, the unrounded output trait, data-liquidity precondition, calendar validation, and the staged payment behavior (payment_token omission returns simulated payment_required). This is substantive behavioral context, not just a restatement of the tool's name.
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 organized into tight, label-led sections (purpose, use when, do not use, limitations, args) and front-loads the core result and method before routing to alternatives. Each sentence adds distinct information without boilerplate.
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 output schema exists, so return-value details are not required in prose. The description provides use-case context, exclusions, limitations, and payment behavior needed to invoke the tool, and the only minor gap (synthetic_identity) does not prevent correct default use. Overall it is complete for a 7-parameter tool with zero annotations.
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 0%, so the prose must supply parameter meaning; it clearly explains as_of, meetings, telemetry fields, and payment_token, including defaults, ranges, and staging behavior. However, synthetic_identity is omitted from the Args section and has no schema description, so one of seven parameters is left unexplained.
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 and resource: returns market-implied Selic expectations for upcoming Copom meetings, with a derived methodology and exact unit (implied level and bp change, unrounded). It distinguishes itself from survey-based siblings by emphasizing 'market-implied' and by naming alternatives in the usage section.
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 'Use when' lists the intended analytical cases (expected BCB changes, terminal rate, cumulative easing/tightening), and 'Do not use when' names alternatives brazil_focus_revisions and compare_brazil_market_vs_focus. Additions like liquid-data and trading-calendar limitations orient the agent about validity conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Brazil's current policy rate (Selic target) plus realized short-term rates (Selic 252, CDI) and the last Copom decision.
Use when: you need the current or historical Brazilian policy rate, or
the most recent Copom decision, without needing forward-looking pricing.
Do not use when: you need market expectations for FUTURE meetings — use
get_brazil_copom_path or compare_brazil_market_vs_focus instead.
Args:
as_of: optional YYYY-MM-DD date for a historical snapshot (respects
vintage — never uses data published after this date). Defaults
to today.
agent_id, session_id, discovery_source, payment_token: optional
telemetry/access-policy fields (C1) — safe to omit; this
capability is free and always returns 200 either way.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| agent_id | No | ||
| session_id | No | ||
| payment_token | No | ||
| discovery_source | No | ||
| synthetic_identity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 discloses the vintage-respecting behavior of the as_of parameter ('never uses data published after this date'), which is a meaningful behavioral trait. It also discloses that telemetry fields are safe to omit and that the capability is free and always returns 200. It doesn't describe the output shape, but an output schema exists, so that burden is partially lifted.
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: what it returns, when to use, when not to use, and parameter explanations. Every sentence earns its place, and the key information is front-loaded. The use of 'Use when' and 'Do not use when' headers makes it scannable for an agent.
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 read-only snapshot tool with an output schema and zero required parameters, the description is nearly complete. It covers the data returned, the historical vintage behavior, the alternative tools, and the optionality of telemetry fields. The only minor gap is not explicitly describing the output structure, but the output schema exists and the description's purpose is to add value beyond structured fields.
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 0%, so the description must compensate. It explains the as_of parameter's meaning and vintage behavior, and clarifies that the telemetry/access-policy fields are optional and safe to omit. The synthetic_identity parameter is not mentioned, but it is a boolean with a default, and the description covers the main semantic parameters well.
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 verb ('Returns') and resource ('Brazil's current policy rate (Selic target) plus realized short-term rates (Selic 252, CDI) and the last Copom decision'). It clearly distinguishes itself from siblings by naming get_brazil_copom_path and compare_brazil_market_vs_focus as alternatives for forward-looking expectations. An agent can tell exactly what this tool provides.
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 states when to use ('when you need the current or historical Brazilian policy rate, or the most recent Copom decision, without needing forward-looking pricing') and when not to use ('Do not use when: you need market expectations for FUTURE meetings'), naming the specific sibling tools to use instead. This is explicit routing guidance.
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.
brazil_focus_revisionsbrazil_inflation_breakevenbrazil_macro_actualbrazil_macro_calendarbrazil_macro_surprisebrazil_monetary_policy_divergencebrazil_real_curvebrazil_yield_curvecompare_brazil_market_vs_focusget_brazil_copom_pathget_brazil_selic_snapshotCross-asset market data for AI agents: forex, equities, Brazil macro (BCB/B3), crypto.
Brazilian fixed income & financial data for AI. Selic, CDI, IPCA, CDB/LCI/LCA rankings, FX rates.
Brazilian public data API for AI agents. BCB, IBGE, CVM, B3, compliance. x402 payments on Base.
Macroeconomic and FX time-series data for AI agents: indicators, calendars, COT, forex, commodities.
Add one secure layer between your agents and this server.
