Skip to main content
Glama

scenario

Reprice a swap under named market variants and tabulate NPV versus base, showing quote bumps or replacements used.

Instructions

Reprice a swap under named market variants and tabulate NPV vs base.

Args: market, trade, as_of: as in swap_dv01. 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. scenarios: [{name, bumps: [{curve, bp, pillar?}], replace_quotes: [{curve, pillar, value}]}]. A bump without pillar moves every pillar of that curve; pillar is a label ("5Y", "3x6") or a 0-based index; replace_quotes sets a pillar's quote to an explicit value.

Result: table = [{name, npv, change = npv - base_npv, edits}] starting with base; calls = one complete pricing result per row with the quotes moved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNo
tradeYes
marketYes
scenariosYes
request_idNo
calendar_overridesNo
market_data_sourceYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A4.1/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does substantive work: it defines the data-provenance contract, forbids estimated/recalled data, and states that scenarios move quotes during the call. It stops short of 5 by not stating reversibility of market mutations or any rate-limit/error behavior.

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-loads the purpose, then organizes Args and Result into scannable sections with no filler. The market_data_source block is long but each enumerated value earns its place; only the result restatement is arguably redundant given an output schema exists.

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

Completeness4/5

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

For a complex pricing tool with nested objects it explains the scenario grammar, the provenance requirement, and the table/calls return shape. The opaque free-form 'market' object and unmentioned calendar_overrides/request_id are the remaining holes, but overall it is callable from the description.

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

Parameters3/5

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

Top-level schema coverage is effectively 0%, and the description compensates well for market_data_source and the nested scenarios/bumps/replace_quotes structure. But market, trade, as_of, calendar_overrides and request_id receive no explanation beyond 'as in swap_dv01', leaving real gaps for a 7-parameter tool.

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?

States a specific verb+resource ('Reprice a swap') and the distinctive output ('tabulate NPV vs base' under named market variants), which separates it from siblings like swap_dv01, key_rate_ladder and reprice_with. The reference to swap_dv01 for shared arg semantics is a genuine differentiation aid.

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

Usage Guidelines4/5

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

Gives explicit when-not guidance ('If you would have to invent numbers, do not call this tool: ask the user for the data') and constrains engine_example to only when the user asked for an example. It does not, however, contrast itself against the closest sibling alternatives for repricing, so it stops short of a 5.

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