{
  "source_file": "0930",
  "source_platform": "Dev.to",
  "author": "Arun Kumar",
  "title_listed": "MCP doesn't replace function calling. Your MCP client still emits one.",
  "keywords": "",
  "domain": "大模型算法",
  "content_type": "深度技术解析",
  "is_paid_flag": "否",
  "url": "https://dev.to/narotra05hp/mcp-doesnt-replace-function-calling-your-mcp-client-still-emits-one-5dgk",
  "publish_date": "2026-09-24",
  "corpus_stage": "",
  "notes": "",
  "id": "070542e23b48",
  "collected_at": "2026-10-02T13:54:50",
  "title": "MCP doesn't replace function calling. Your MCP client still emits one. - DEV Community",
  "body_markdown": "\"Do we still need APIs after MCP\" keeps coming up, and the framing is off in a way that's worth unpicking. MCP and function calling aren't two options you choose between. They're two layers of the same request, and a system built on MCP runs function calling underneath it every single time.\nThe two gaps\nA model can't act on its own. It reads text and predicts more text. Two separate gaps sit between it and anything useful, and each needs its own fix.\nThe first gap is expression — the model needs a structured way to say what it wants done. Function calling fills that. It's a capability of the model provider's API, not a protocol: your application sends tool definitions with the request, and the model returns a structured call naming one of them.\nThe part people skip:\nthe model doesn't run anything.\nIt hands back a request. Your code executes the function and feeds the result into the next turn.\nThe second gap is reach. Your application still has to find the tool, get its schema, and call it correctly — usually across a lot of tools. That's MCP's job. Client-server, JSON-RPC 2.0, discovery at runtime via\ntools/list\n.\nFunction calling links the model to your app. MCP links your app to the tool server.\nWhat actually happens when both are in play\nFive steps, fixed order:\nThe MCP client calls\ntools/list\non a server and gets tool definitions back, each with a JSON Schema.\nYour application hands those definitions to the model through the provider's function-calling mechanism.\nThe model emits a function call — tool name, arguments.\nYour application routes that call to the MCP server as\ntools/call\n.\nThe server executes it, and the result goes back into the conversation.\nSteps 2 and 3\nare\nfunction calling. Adopting MCP doesn't remove them, it feeds them. Note also that the model never talks to the MCP server directly — your application sits in the middle the whole time, translating between a function call and a\ntools/call\n.\nSo what is MCP actually for\nNot model capability. Models could call functions long before MCP existed.\nIt's the N×M problem. Without a shared protocol, wiring N applications to M tools means N×M integrations — three apps each needing five tools is fifteen separate pieces of work, none of which carry over. Wrap each tool once as a server, implement the client once per application, and the total becomes N+M.\nThat's the real argument, and it's a good one. It just has nothing to do with whether a model can express a tool call.\nThe part that gets overstated\nThis is the bit I'd most want people to check themselves, because plenty of write-ups claim MCP ships approval workflows and audit logging out of the box.\nHere's the specification text:\nthe protocol itself does not mandate any specific user interaction model. For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.\nSHOULD. The spec states up front that its key words are to be read per RFC 2119, so that's a recommendation aimed at client implementers, not something the protocol enforces. Nothing in MCP stops a client skipping the check.\nWhat you do get is a\nseam\n. Tools sit behind a server boundary, which is a natural place to put authentication, logging and policy. That part is real and genuinely useful. But you build it yourself. And the boundary means trusting a new party — the server is now part of your threat model, which isn't a free win.\nWhere I'd leave it\nReach for function calling whenever a model needs to act. That's every agentic flow, MCP or not.\nReach for MCP once tools need reuse across applications, or once they live behind a server you don't control. A single script calling one local function probably doesn't need it.\nMost production systems end up running both, because they're solving different problems. \"Do we still need APIs after MCP\" has the same answer as \"do we still need function calling after MCP\" — yes, underneath, every time.\nLonger version with the full comparison table at\ndiffstudy.com\n. Spec quote from the\nMCP specification, 2025-06-18, Server/Tools\n.",
  "metadata": {
    "title": "MCP doesn't replace function calling. Your MCP client still emits one. - DEV Community",
    "description": "\"Do we still need APIs after MCP\" keeps coming up, and the framing is off in a way that's worth... Tagged with mcp, llm, ai, machinelearning.",
    "keywords": "mcp, llm, ai, machinelearning, software, coding, development, engineering, inclusive, community",
    "author": null,
    "og:type": "article",
    "og:url": "https://dev.to/narotra05hp/mcp-doesnt-replace-function-calling-your-mcp-client-still-emits-one-5dgk",
    "og:title": "MCP doesn't replace function calling. Your MCP client still emits one.",
    "og:description": "\"Do we still need APIs after MCP\" keeps coming up, and the framing is off in a way that's worth...",
    "og:site_name": "DEV Community",
    "og:image": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F2a6ne73j17dj22qapdwa.png",
    "twitter:site": "@thepracticaldev",
    "twitter:creator": "@",
    "twitter:title": "MCP doesn't replace function calling. Your MCP client still emits one.",
    "twitter:description": "\"Do we still need APIs after MCP\" keeps coming up, and the framing is off in a way that's worth...",
    "twitter:card": "summary_large_image",
    "twitter:widgets:new-embed-design": "on",
    "twitter:image:src": "https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F2a6ne73j17dj22qapdwa.png"
  },
  "paywall": {
    "listed_paid": false,
    "detected": false,
    "marker": "",
    "public_only": false,
    "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙"
  },
  "crawl": {
    "success": true,
    "status_code": 200,
    "error": ""
  },
  "code_blocks": [],
  "images": [],
  "audio": [],
  "videos": [],
  "links": [
    {
      "href": "https://diffstudy.com/mcp-vs-function-calling/",
      "label": "diffstudy.com",
      "type": "a"
    },
    {
      "href": "https://modelcontextprotocol.io/specification/2025-06-18/server/tools",
      "label": "MCP specification, 2025-06-18, Server/Tools",
      "type": "a"
    }
  ],
  "repair_version": 2,
  "repaired_at": "2026-10-14T10:48:59Z",
  "source_url": "https://dev.to/narotra05hp/mcp-doesnt-replace-function-calling-your-mcp-client-still-emits-one-5dgk",
  "papers": [],
  "actual_video_files": [],
  "body_chars": 4072,
  "expected_body_images": 0,
  "discovery_status": "ok",
  "delivery_status": "ok",
  "missing_reason": "",
  "raw_html": "attachments/070542e23b48/pages/source.html",
  "local_html": "attachments/070542e23b48/pages/article.html",
  "body_base_path": "attachments/070542e23b48/pages/",
  "body_markdown_path": "attachments/070542e23b48/pages/article.md"
}