quantra-mcp

Overview Schema Source Related Servers Discussions Admin

build_curve

Converts a market quote strip into an engine curve specification and index definitions for bootstrapping, without pricing anything.

Instructions

Turn a quote strip into an engine curve spec (no engine call).

Args: id: curve id to register, e.g. USD_SOFR_OIS. preset: a preset id from list_presets; supplies the index definition and every helper convention. quotes: [{type: deposit|fra|future|swap|ois, tenor: "6M", rate: 0.052}, ...] (fra: months_to_start/months_to_end; future: future_start_date + price or rate). Sorted by maturity; a duplicate (type, tenor) is rejected locally. reference_date: YYYY-MM-DD curve date (normally the pricing as_of). market_data_source: where the market numbers in this call come from. user_pasted (the user pasted or typed the numbers in this conversation), user_file (the user attached a file/screenshot the numbers were read from), engine_example (an engine example's pricing block, only when the user explicitly asked to run an example), session (a market previously stored in this session, which itself came from one of the above). There is no value for estimated, recalled or placeholder data. If you would have to invent numbers, do not call this tool: ask the user for the data. trait: override the preset's bootstrap trait (Discount, ZeroRate, FwdRate). interpolator: override the preset's interpolator. day_counter: override the preset's curve day counter.

Returns {ok, curve, indices, preset, notes}: curve is the TermStructure and indices the IndexDef list to pass to bootstrap_curve (or to session_put); notes lists every default applied with its source. Nothing is priced here.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`trait`	No
`preset`	Yes
`quotes`	Yes
`day_counter`	No
`interpolator`	No
`reference_date`	Yes
`market_data_source`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it is a pure-local builder ('nothing is priced here', 'no engine call'), rejects duplicate (type, tenor) strips locally, and returns notes listing every default applied with its source. The market_data_source enumeration is further constrained in prose to exclude estimated/recalled/placeholder data.

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

Conciseness4/5

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

Front-loaded with the one-line purpose, then an Args block that maps to the schema; nothing is filler. It is long, but the density is warranted for an 8-param builder with a polymorphic quote list, so only marginally verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a preset-driven curve builder with defaults supplied by preset and an output schema present, the description covers the local-only nature, validation, default provenance, and where the result flows next. Nothing needed to call it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0% at the top level, but the description documents every one of the 8 parameters in prose, including the per-type quote shapes (fra months_to_start/end, future price vs rate), the accepted tenor forms, and the exact semantics of each market_data_source enum value. This fully compensates for the coverage gap.

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

Purpose5/5

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

Declares a specific verb+resource ('Turn a quote strip into an engine curve spec') and immediately scopes it with '(no engine call)', which is exactly what distinguishes it from the sibling bootstrap_curve. An agent can pick it apart from bootstrap_curve, curve_from_pasted_table and build_value_curve without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when not to call ('If you would have to invent numbers, do not call this tool: ask the user for the data') and routes the output forward explicitly: indices to pass to bootstrap_curve or session_put. That is an explicit when/when-not/alternative set rather than implied usage.

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

Deploy Server