Skip to main content
Glama
Sign In

Finra Fixed Income

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Finra Fixed Income Series

finra_fixed_income_series
Read-onlyIdempotent

Get a FINRA fixed income aggregate series — US bond market trading activity as reported to FINRA. Answers "how much Treasury volume traded", "corporate bond market sentiment", "agency MBS trading activity", "is bond market breadth positive", "what is CMBS pricing by deal vintage". Pass a dataset key from finra_fixed_income_datasets (e.g. "treasury_daily", "corporate_sentiment", "agency_mbs_activity", "capped_volume_corporate") and optionally a date range. With no date range, returns FINRA's latest published period for that series; with start_date or end_date, returns that window. This is MARKET-WIDE aggregate data, not individual trades — FINRA licenses transaction-level TRACE data separately and it is not available here. Example: finra_fixed_income_series({ dataset: "treasury_daily", limit: 10 }); finra_fixed_income_series({ dataset: "corporate_sentiment", start_date: "2026-07-01" }).

Input Schema

NameRequiredDescriptionDefault
limitNoMax rows (default 25, max 500)
datasetYesDataset key from finra_fixed_income_datasets, e.g. "treasury_daily"
end_dateNoLatest date, YYYY-MM-DD (optional)
benchmarkNoOptional row filter on the benchmark column (Treasury datasets), e.g. "On-the-run", "Off-the-run". Case-insensitive.
start_dateNoEarliest date, YYYY-MM-DD (optional)
product_categoryNoOptional row filter on the productCategory column (Treasury datasets), e.g. "Nominal Coupons", "Bills", "TIPS", "FRNs". Case-insensitive.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / benchmark
      Added value: +{
+  "description": "Optional row filter on the benchmark column (Treasury datasets), e.g. \"On-the-run\", \"Off-the-run\". Case-insensitive.",
+  "type": "string"
+}
    • addedInput schema / properties / product_category
      Added value: +{
+  "description": "Optional row filter on the productCategory column (Treasury datasets), e.g. \"Nominal Coupons\", \"Bills\", \"TIPS\", \"FRNs\". Case-insensitive.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the description focuses on what annotations cannot express: with no date range it returns FINRA's latest published period, and the data is market-wide aggregate rather than individual trades. It omits rate-limit/pagination behavior beyond the schema's limit field, but adds real context.

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 core purpose, then routing, then scope caveat, then two call examples. The string of quoted example questions is slightly padded but genuinely aids intent matching, so waste is minimal.

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?

For a read-only aggregate query tool with a fully documented schema and no output schema, the description covers what an agent needs: where the dataset key comes from, default behavior, date-window semantics, and the data's granularity limits.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining what `dataset` selects (e.g. treasury_daily, corporate_sentiment) and how omitting start_date/end_date changes the returned window. It does not explain benchmark/product_category filters, which remain schema-only.

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 and resource (get a FINRA fixed income aggregate series — US bond market trading activity), then distinguishes it explicitly from transaction-level TRACE data. The sample questions map concrete user intents to the tool, so an agent can tell at a glance what it retrieves.

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?

It routes the agent to finra_fixed_income_datasets first to obtain a dataset key, and explains the default-window behavior when no dates are given. It does not explicitly say when another sibling would be preferable, but the aggregation-vs-TRACE carve-out functions as an exclusion.

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

All Finra Fixed Income toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources