MCP server vs function calling: how should a finance agent get market data?

Strip away the terminology and function calling and MCP end in the same place: the model emits a structured call, something executes it, and the result goes back into context. So the choice between them is not about what the model can do. It is about who defines the tool, who hosts it, who maintains it when the upstream API changes, and how many clients get to reuse it. For a finance agent, where the tools are mostly “fetch trustworthy market data,” those questions have fairly clean answers.

What function calling gives you, and what you now own

With plain function calling, you write a JSON schema for each tool, pass it to the model provider’s API, and execute whatever the model calls inside your own code. It is simple, dependency-free, and completely under your control: your schemas, your execution, your error handling. The cost is that you now own all of it. Every tool needs a definition, an implementation against some upstream data API, auth handling, retries, and updates when that upstream changes. And all of it lives inside one application. If you later want the same tools in a second agent, or in a desktop assistant you did not write, you are copying code.

What an MCP server changes

The Model Context Protocol moves the tool boundary out of your application. A server defines and hosts the tools; any MCP-compatible client discovers them at runtime and calls them over a standard protocol. The schemas, the upstream integration, and the maintenance live on the server side, once. Your agent code shrinks to “connect to this endpoint.” For market data this fits unusually well, because the tools are generic reads — signals, filings, news, prices — that do not need to know anything about your application to be useful.

Portability: the same tools in every client

This is the argument that tends to settle it in practice. Hand-written function definitions work in exactly one codebase. An MCP server works in Claude, Cursor, and any other MCP client, plus your own agents through the client libraries. If your workflow spans a chat assistant for exploration and a custom agent for automation, function calling means implementing the same six finance tools twice and keeping them in sync. An MCP endpoint means configuring the same URL twice.

Auth and limits: one budget, not two

A subtler point: tool access should share the data API’s key and rate limits, not sit beside them. If your agent’s tools authenticate separately from your direct API usage, you have two quotas to reason about and a path where an agent quietly becomes a heavier consumer than any human. A well-designed MCP server passes the same API key through and counts tool calls against the same limits, so agent traffic and application traffic draw from one budget you can see. With hand-rolled function calling you can build this too — you just have to remember to.

When plain function calling is still the right call

MCP is not the answer to everything. If your tools are private business logic — “create an order in our system,” “query our internal database” — there is no reuse story and no reason to stand up a server; a function definition next to the code that executes it is simpler and easier to test. The same goes for a single-application agent with two or three stable tools, or for latency-critical paths where you want no extra hop. The honest rule: MCP earns its keep when tools are shared across clients or maintained by someone else. Your own one-off tools can stay functions.

How this looks with QuantConomy

QuantConomy runs a hosted MCP server at mcp.quantconomy.com/mcp over Streamable HTTP, exposing roughly 50 read-only tools — list_signals, search_entries, sec_insider_trades, get_market_candles, and the rest — that work in Claude, Cursor, or any MCP client with a URL and an Authorization header. It uses the same data, key, and rate limits as the REST API, so the split above maps directly: your application code calls the API, your agents and assistants connect to the MCP endpoint, and both draw from one plan. We covered what to look for in a finance MCP server in an earlier post; the short version is read-only tools, source-linked results, and shared limits.

Pick per constraint, not per fashion: functions for private logic, MCP for shared data tools. Just stop hand-writing the same six finance tools into every client you build.