Developer Tools + Agents

What is the difference between function calling and MCP?

Function calling is a model capability: you send tool schemas with a request, and the model returns structured arguments your code executes. MCP (Model Context Protocol) is a transport and interface standard that exposes tools, resources and prompts to compatible clients. They are complementary — an MCP server can publish tools that a model then invokes through function calling.

Key facts

Function callingModel returns structured tool calls with JSON arguments for your code to execute
MCPOpen protocol for exposing tools, resources and prompts to compatible clients
RelationshipComplementary: MCP distributes tools, function calling invokes them
Wire formatFunction calling uses the chat completions request; MCP defines its own client-server transport
StatusFunction calling is live on Plugsky chat models; MCP is supported at the client and framework layer
Models30+ models behind one OpenAI-compatible API; tool support varies by model
Security surfaceTool schemas are code execution boundaries — validate arguments and scope permissions
Free tierFree plan with 2 free AI models, no card required

TL;DR

  • Function calling is how a model asks your code to run something.
  • MCP is how tools and data get discovered and shared across clients.
  • They stack: MCP for distribution, function calling for invocation.
  • Validate every tool argument — the model is not a security boundary.
  • Check per-model tool support before standardizing your stack.

How it works, step by step

  1. Define the tool contract: name, description, JSON schema for arguments and a result shape.
  2. Send the schemas with a chat completion request and handle the returned tool call.
  3. Execute the function in your own runtime with validated arguments and timeouts.
  4. Return the result to the model and let it continue or finish the turn.
  5. Wrap recurring integrations in an MCP server if several clients need the same tools.
  6. Log every tool call with inputs, outputs and latency for debugging and audit.
1Define the toolcontract: name,description, JSON2Send the schemaswith a chatcompletion request3Execute thefunction in yourown runtime with4Return the resultto the model andlet it continue or5Wrap recurringintegrations in anMCP server if6Log every tool callwith inputs,outputs and latency

Try it yourself

Open the function calling schema generator →

Function calling in one paragraph

You describe available functions in the request — name, purpose and a JSON schema for arguments. The model either answers normally or returns a tool call with structured arguments. Your application executes the function, returns the result as a message, and the model produces the final answer. Nothing runs on the provider side: the model only proposes, your code disposes.

What MCP adds

MCP standardizes the interface between clients (agents, IDEs, chat apps) and servers that expose capabilities: tools for actions, resources for readable data and prompts for reusable templates. Instead of every framework inventing its own plugin format, one server can be consumed by any MCP-compatible client. It solves distribution and discovery, not model reasoning.

How they work together

A practical stack uses both. An MCP server publishes a database query tool. The client discovers it and converts the MCP tool definition into a function schema for the model. The model returns a function call, the client routes that call back through MCP to the server, and the result returns to the model. Function calling remains the invocation mechanism; MCP remains the wiring.

Security and reliability

  • Validate arguments against the schema before execution — treat model output as untrusted input.
  • Scope each tool to the minimum permission it needs; never expose a shell or admin credential broadly.
  • Set timeouts and idempotency keys so retries do not double-apply writes.
  • Log calls with a trace id, and review which tools are actually used.
  • Remember that tool availability varies by model, so test the models you route to.

Map each tool to the data it can reach before enabling it for an agent.

Honest comparison

DimensionFunction callingMCPBoth together
What it isModel capabilityInterface and transport standardStandard plus invocation
ScopeOne request's tool setDiscoverable servers and resourcesServers surfaced as tools
ExecutionYour code executesServer executes behind the protocolClient routes to server
PortabilityProvider request formatClient-agnosticHigh across clients
Main riskUnvalidated argumentsOver-broad server permissionsBoth, unless scoped

Frequently asked questions

Is MCP a replacement for function calling?

No. MCP standardizes how tools and data are exposed to clients; function calling is how a model requests one of those tools by returning structured arguments. They solve different layers.

Does Plugsky support function calling?

Yes. Function calling is live on supported chat models through the OpenAI-compatible API. Check the docs for the current per-model capability matrix.

Do I need MCP if I already use function calling?

Only when several clients or teams need the same integrations. For a single application, direct function calling is simpler and has fewer moving parts.

How do I write a good tool schema?

Use a clear name, a one-sentence description of when to use it, strict JSON schema types, and an example. Vague descriptions cause wrong tool selection more often than model limits do.

What is the biggest security risk with tools?

Executing model-generated arguments without validation. Validate against the schema, enforce permissions, set timeouts, and keep destructive actions behind confirmation.

Which models handle tool calling best?

Instruction-tuned, larger models handle multi-tool selection more reliably. Prototype on free models, then route production tool traffic to a stronger alias from the 30+ model catalogue.