October 9, 2026

MCP or API? Connecting AI agents to interest rate data

Last updated: 9 October 2026

Short answer: use MCP when a person asks an AI assistant questions in chat and wants live rates without writing code. Use a REST API when software runs the same calculation on a schedule and must return identical, auditable numbers. Either way, the model fetches the rate and its timestamp from a tool, and never recalls or calculates it from memory.

On evaluation calls this question comes up regularly. Fintechs building agents ask "do you prefer MCP or the API for our agents?". Lenders automating a weekly market note ask whether an AI-generated presentation can use real curve data. Treasury teams ask whether it works with assistants other than Claude. This post answers those questions in a vendor-neutral way, then shows one real prompt, the tool call it triggers and the number that comes back.

Why can't an AI assistant just tell me today's swap rate?

Because a language model has no market data of its own. Its knowledge stops at a training cut-off, usually many months before you ask, and when it lacks a number it tends to produce a plausible-looking one rather than say so.

Rates move far too much for a remembered number to be useful. A 5-year swap rate can move several basis points within a single session. Over a year of training lag, the moves add up to tens of basis points or more. A model that answers "the 5-year SONIA swap rate is around 4%" from memory is not slightly stale; it is guessing, and the guess reads exactly like a fact.

There are two other problems a live source solves:

  • Conventions. "The 5-year rate" is not one number. An annual fixed leg and a semi-annual fixed leg differ by about 3bp at a 3.5% rate and 4 to 5bp at 4 to 4.5%, and day counts differ by currency. A tool returns the rate together with the conventions it used.
  • Provenance. A number in a client note or board pack needs a source and a time. A model's memory has neither.

What is MCP, and how does an agent call a tool?

MCP (Model Context Protocol) is an open standard, published by Anthropic in late 2024 and, since December 2025, governed under the Linux Foundation's Agentic AI Foundation, for connecting AI assistants to external tools and data. A data provider runs an MCP server that describes its tools; any assistant that supports MCP can discover those tools and call them during a conversation.

A single tool call works in four steps:

  1. Discovery. When you connect the server, the assistant reads each tool's name, description and parameters, for example get_swap_rate(index, start_date, maturity_date, fixed_leg_frequency, valuation_time).
  2. Selection. You ask a question in plain English. The model decides which tool answers it and fills in the parameters.
  3. Execution. The client sends the call to the MCP server, which usually calls the provider's own REST API and returns the result.
  4. Answer. The model reads the result and writes its reply around it. If it is well instructed, it quotes the number and the timestamp exactly as returned.

The important point is step 2. With MCP the model chooses the tool and the parameters. With a direct API call, your code does. That one difference drives almost everything in the comparison below.

"MCP is simply just a way for, let's say, Claude to talk to BlueGamma's data in the same way that an Excel add-in is a way for Excel to talk to BlueGamma's data…"

Should we use MCP or the API for our agents?

Use MCP for interactive, human-in-the-loop work: analysis in chat, drafting a market note, building a chart or slide. Use the API for anything that runs unattended, feeds a system of record or must produce the same output every time.

MCP server REST API
Who it is for Analysts, treasurers and sales teams working in an AI assistant Developers building products, pipelines and scheduled jobs
Who chooses the call The model, from your prompt Your code, explicitly
Authentication Usually a per-user sign-in (OAuth) in the browser Usually an API key held by the application
Determinism The data is deterministic; the model's choice of tool and parameters is not Same request, same response
Latency A model turn plus one or more tool calls, typically several seconds One HTTP request
Auditability Good if the reply quotes the returned timestamp; the transcript is the record Strong: you log the exact request and response
Setup Paste a server URL into the assistant's settings and sign in Write and maintain code
Best uses Ad hoc questions, market commentary drafts, quick scenario checks, charts in chat Client-facing products, valuations, reports, alerts, anything audited

Many teams end up with both. A common pattern for automated market notes is a scheduled job that pulls the rates through the API, then passes those numbers to a model with the instruction to write the commentary around them. The model writes the words; the API supplies every figure. For a product that shows rates to its own customers, the API is the right layer, because the numbers must not depend on how a model reads a prompt.

Does MCP work with LLMs other than Claude?

Yes, in principle. MCP is an open protocol, so any assistant or agent framework that implements an MCP client can use any MCP server, and support now extends well beyond the assistant it started in.

In practice, check three things for the assistant you actually use:

  • Remote server support. Data providers usually host their server over HTTP. Some clients only support local servers, or only on certain plans or admin settings.
  • Authentication flow. If the server uses OAuth sign-in, the client must support it.
  • Your organisation's policy. Enterprise deployments often require an administrator to approve each connector before staff can use it.

If you are building your own agent rather than using an off-the-shelf assistant, most agent SDKs can act as an MCP client, or you can skip MCP entirely and give the agent a function that calls the REST API.

What can go wrong when an LLM handles rate data?

The main risks are the model doing arithmetic it should not, quoting a number without its time, and silently using the wrong date, index or convention. Each has a simple control.

Risk What it looks like Control
Model arithmetic The model reads curve points and computes a swap rate, PV or interpolated forward itself Use a tool that returns the finished figure (swap rate, discount factor, forward rate), not raw points for the model to process
Number without a time "The 5Y rate is 4.50%" with no timestamp Require every figure to be quoted with the timestamp the tool returned
Wrong valuation date A quarter-end note built on today's curve Pin valuation_time explicitly; never rely on "now" for reporting
Time zone slips "4pm" read as 16:00 UTC when you meant London time (15:00 UTC in summer) State times in UTC in the prompt
Wrong index name "SONIA 5 year" mapped to a different index, or an invented one Have the model list the supported indices first and use the exact name
Convention drift Annual fixed in one call, semi-annual in the next Specify frequency and day count in the prompt or a saved system prompt
Silent gap-filling A tool call fails and the model answers anyway Instruct: "if a tool call fails, say so and do not estimate"

A system prompt that bakes these in is worth writing once and reusing. For example: "Only quote rates returned by the rates tools. Quote each rate to 2 decimal places with its timestamp in UTC. Pin the valuation time I give you. If a tool fails, tell me and do not estimate."

Worked example: one prompt, one tool call, one number

One plain-English question typically becomes one tool call, which returns a rate together with its quote timestamp, and the same answer again on a repeat call with the same pinned time.

Illustrative figures, not market data: the rates below are round numbers chosen for the example, while the request shape, timestamps and conventions follow how the API responds.

A prompt like this, sent to an assistant connected to an MCP rates server:

What was the 5-year SONIA swap rate at 16:00 UTC on 30 September 2026, with an annual fixed leg? Quote the timestamp.

would typically become one tool call:

get_swap_rate(
  index="SONIA",
  start_date="2026-09-30",
  maturity_date="5Y",
  fixed_leg_frequency="12M",
  valuation_time="2026-09-30T16:00:00"
)

The server forwards it to the REST API, and the response looks like this (abridged, illustrative rate):

{
  "index": "SONIA",
  "start_date": "2026-09-30",
  "maturity_date": "2031-09-30",
  "fixed_leg_frequency": "12M",
  "fixed_leg_day_count": "Actual365Fixed",
  "valuation_time": "2026-09-30T16:00:00",
  "swap_rate": 4.5,
  "timestamp": "2026-09-30T15:59:53"
}

So the correct answer reads "4.50%, from a quote stamped 15:59:53 UTC". When we sent the same pinned request twice, we got the same number twice, which is what a pinned valuation time should give you.

Changing only the valuation time shows why pinning matters. All are 5-year swaps with an annual fixed leg; the rates are illustrative.

Index Valuation time (UTC) 5Y swap rate (illustrative) Quote timestamp (UTC)
SONIA 12:00 4.48% 11:59:54
SONIA 16:00 4.50% 15:59:53
SONIA 21:00 4.50% 15:59:53
SOFR 12:00 4.46% 11:59:58
SOFR 16:00 4.50% 15:59:57
SOFR 21:00 4.53% 20:59:58

Three things to notice:

  1. Snap time matters. In this illustration SONIA moves 2bp between 12:00 and 16:00 UTC and SOFR moves 7bp between 12:00 and 21:00 UTC. Real rates can move several basis points in a session, so a note that says "the 5-year rate" without a time is ambiguous by that much.
  2. "End of day" differs by market. End of day is the last quote before that market stops updating: late afternoon London time for GBP and EUR (recently about 16:00 to 16:30 UTC), and into the evening for USD. Asking for SONIA at 21:00 UTC returns the 15:59:53 quote, because the sterling market had stopped updating, while SOFR kept updating into the evening. The timestamp tells you this; the rate on its own does not.
  3. Conventions come back with the number. The SONIA swap uses Actual/365 Fixed and the SOFR swap Actual/360, as returned in the response. A model quoting the rate should carry those through rather than assume them.

For live levels rather than this example, see the SONIA swap rates and USD swap rates pages.

How to check this yourself

Use this checklist when you evaluate an MCP data server, or an API you plan to put behind an agent:

  1. List the tools. Connect the server and ask the assistant to list every tool and its parameters. Check that the instruments you need (swap rates, forward curves, discount factors, fixings, FX forwards) exist as tools, not just raw data dumps.
  2. Check every response carries a timestamp. Ask for a rate and confirm the reply includes the source timestamp, in a stated time zone.
  3. Test a pinned valuation time. Request the same historical time twice. The two answers should be identical to the last decimal.
  4. Compare against the API. Make the same request directly against the provider's REST API. The MCP answer should match exactly; if it does not, find out why before you trust either.
  5. Check conventions. Ask for a 5-year rate with an annual fixed leg, then semi-annual. You should see a difference, typically a few basis points, and the response should state the day count used.
  6. Break it on purpose. Ask for an index that does not exist. A good setup returns an error and the model says so; a bad one invents a rate.
  7. Confirm read-only access. Data tools should not be able to change anything in your account. Look for read-only annotations or ask the provider.
  8. Check authentication and admin controls. Is access per user? Can an administrator approve or revoke it? Is it included in your current plan, or priced separately?
  9. Check the licence. Confirm that putting the data into an AI assistant, and into any material you send to clients, is allowed under your agreement. Our guide to choosing an interest rate data provider covers the licensing questions in more detail.

Where BlueGamma fits

  • An MCP server for rates. The BlueGamma MCP server connects to assistants that support MCP, such as Claude or ChatGPT. You add the server URL to the assistant's settings and sign in with your BlueGamma account in the browser on first use.
  • Read-only tools across the curve stack. Tools cover swap rates and swap curves, forward and discount curves, zero rates, discount factors, forward rates and FRAs, historical swap rates, fixings, FX spot and forwards, government yields, inflation curves, and cap, floor and swaption pricing, plus a tool that lists every supported index by its exact name.
  • The same numbers as the API. The MCP server calls the same endpoints as the interest rate API, so a figure in chat matches the API and the Excel add-in, and the web app serves the same curves.
  • Timestamps and point-in-time history. Every point is timestamped in UTC at source, and the swap rate and curve tools accept a valuation time for reproducible historical answers. The curve construction is set out in our methodology.
  • Automated market notes. See how teams use rates in automated client market updates.

Start a free 14-day trial or book a call to see the MCP server and the API side by side.

Frequently Asked Questions

Can ChatGPT or Claude give me live swap rates?

Not on their own: a language model has no market data and its knowledge stops at a training cut-off, so any rate it gives from memory is a guess. Connect an MCP server or an API-backed tool and the assistant can fetch the live rate, with its timestamp, at the moment you ask.

What is the difference between MCP and an API for market data?

An API is called by your code with exact parameters; MCP lets an AI assistant decide which tool to call from a plain-English question. The data underneath is often the same. MCP suits interactive analysis and drafting; the API suits products, scheduled jobs and anything that must be reproducible and audited.

Is MCP deterministic enough for valuations or audit work?

The data can be, but the model's choice of tool and parameters is not, so audited figures are better produced through the API. If you do use MCP, pin the valuation time, specify conventions, and keep the returned timestamp with every number so the figure can be reproduced.

Can an AI-generated presentation or market note use real curve data?

Yes, if the assistant fetches the figures from a rates tool rather than writing them from memory. Ask it to quote each rate with its timestamp and valuation time, and have a person check the numbers before the slide or note goes to a client. For recurring notes, pull the rates through the API and let the model write only the commentary.

Does an MCP server work with LLMs other than Claude?

Yes: MCP is an open standard, so any assistant or agent framework with an MCP client can use it. Check that your client supports remote servers over HTTP and OAuth sign-in, and whether your administrator must approve the connector first.

Should the AI calculate swap rates from a curve itself?

No: language models are unreliable at multi-step arithmetic, so the tool should return the finished figure. Ask for the swap rate, discount factor or forward rate directly, rather than giving the model curve points to interpolate and discount.

Does BlueGamma have an MCP server?

Yes. The BlueGamma MCP server gives assistants that support MCP, such as Claude or ChatGPT, read-only access to swap rates, forward and discount curves, fixings, FX forwards, government yields and cap, floor and swaption pricing. It calls the same endpoints as the interest rate API, so the numbers match.

Try BlueGamma free for 14 days
BlueGamma.io company logo.

Get historic and live interest rates and FX forward curves delivered through our Excel Add‑in, API, MCP or web-app.

Made with ❤️ in rainy London ☔