MCP vs Function Calling

The short answer

Function calling lets a model request a tool invocation by producing structured arguments. Your application validates and executes that request. MCP standardizes communication between AI applications and tool or context servers. These mechanisms can be used together; neither automatically chooses the safest tool, guarantees authorization, or validates financial data.

For example, an AAPL price question requires a symbol and market, a source with suitable entitlements, a tool call, and a result carrying event time, retrieval time, currency and feed coverage. The model may propose the call; the host must check whether the output is usable.

What is function calling?

A model API accepts tool definitions and can return a function name or tool identifier with structured arguments. The application remains responsible for executing a handler, checking permission, validating arguments, and returning the tool result to the conversation. A generated call is not evidence that execution succeeded.

Provider request formats and supported schema subsets differ. An adapter can normalize part of that difference, but teams should test argument validation, parallel calls, streaming, retries and model-specific options. Tools need not be fixed forever: an application can discover candidates and supply a smaller tool set for each request.

OpenAI function calling documentation describes one provider interface; use the corresponding official documentation for other model APIs.OpenAI function calling documentation

What is MCP?

An MCP host coordinates clients that access independent servers. Servers can expose tools, resources and prompts. Local stdio and remote Streamable HTTP have different deployment and authentication requirements; choose the transport and protocol version supported by both endpoints.

Use the current specification as the authority. The specification entry point was reviewed on March 6, 2026; older examples may follow earlier lifecycle rules. Version discovery, transport support and optional features must be tested explicitly.

Seven differences that affect implementation

MCP does not make tool schemas disappear from model context. Token use depends on what the host sends to the model, caching, discovery strategy and the chosen API. Likewise, RBAC, retention, approvals and audit logs require actual implementation; protocol support alone does not provide them.

How the two work together

A practical sequence is: discover relevant tools, inspect their contracts, expose the necessary definitions to the model, validate the requested arguments and authorization, execute through the appropriate client, then validate the returned result. Log the provider, tool version, request identifier and timestamps along the path.

For financial research, reject a fallback whose market, currency, adjustment, freshness or license differs from the requested contract unless the user accepts the downgrade. Never turn an empty response or timeout into a fabricated price or silently reuse stale data.

When to use each approach

A small application with stable tools may use direct model tool calls and ordinary handlers. Shared tools accessed by several clients can benefit from MCP. A production application may use both. Tool count alone is not a sufficient decision rule: include deployment ownership, credentials, availability, schema evolution and the cost of maintaining adapters.

Measure the same workload on each candidate path. Record model and tool versions, schema token counts, cache state, transport, first-token and complete-task latency, error rates, retries and total cost. Publish sample size and environment with any benchmark. There is no universal MCP latency surcharge or automatic token saving.

Where QVeris fits

QVeris provides discovery, inspection and capability-call entry points through supported integrations. It complements the host and orchestration layer. The host still owns user intent, permissions and result validation; the selected provider determines underlying data coverage and licensing.

Discover and Inspect are free. Receive 1,000 one-time signup credits after signup verification. Buy 10,000 credits for $19. Credits never expire. No monthly fees or auto-renewal. Paid execution may consume credits during development as well as production.

Credits are a billing unit, not a fixed number of calls. Inspect the selected tool and include retries, provider charges, model usage and operational work in a like-for-like comparison.

Implementation examples

The original code samples are retained below as examples. Check package versions, protocol revision, API names and credentials against current documentation before execution; examples are not a record of successful calls.

// Define a tool schema (OpenAI format example)
{
  "type": "function",
  "function": {
    "name": "get_stock_price",
    "description": "Get current stock price",
    "parameters": {
      "type": "object",
      "properties": {
        "symbol": { "type": "string" }
      }
    }
  }
}

// Application code — tools are hardcoded prompt content
const tools = [{ name: "get_stock_price", ... }];

// Every request includes ALL tool schemas
const response = await openai.chat.completions.create({
  model: "gpt-4",
  tools: tools,  // static, predefined
  messages: [{ role: "user", content: "What's AAPL at?" }]
});

# MCP client dynamically discovers tools at runtime
from mcp import ClientSession

# Connect to any MCP Server
session = await ClientSession.connect(server_url)

# Discover tools — no hardcoded schemas needed
tools = await session.list_tools()
# Returns: dynamic list of available tools with schemas

# Call a discovered tool
result = await session.call_tool("get_stock_price", { "symbol": "AAPL" })

# One command to add QVeris MCP Server to Claude Code
claude mcp add qveris -s user -- npx @qverisai/mcp

# Now your Claude Code agent has access to 10,000+ capabilities
# Just ask: "find me tools for stock market data"
# QVeris discovers, inspects, and calls — all through MCP

Frequently asked questions

Sources

This guide uses the official MCP specification and official model API documentation as primary references. Verify protocol revisions, API behavior, package versions and access requirements against the linked documentation before implementation.