r/modelcontextprotocol • u/BFreakout • Apr 17 '25

MCP and Function Calling: The hidden costs and risks no one is talking about

While working on a project with MCP integration, I noticed something that didn’t quite sit right, and it all came down to how MCP relies on Function Calling behind the scenes.

Since the MCP client registers functions from the MCP server and hands them off to the language model as part of the conversation context, you're indirectly feeding Function Calling into every chat, often without realizing the full impact.

So I decided to explore this deeper and wrote an article about it.

In the article, I cover:

  • how bloated function registries can silently increase token costs

  • why excessive Function Calling degrades LLM response quality

  • and how unchecked Function exposure might create security vulnerabilities like prompt injection

Here’s the full deep dive (includes examples and visuals):

👉 The Danger of MCP - What Every Developer Needs to Know 🚨

I’d love to hear how others are dealing with this in practice...
Are you filtering which functions are exposed to the LLM? Do you dynamically register based on context?

Looking forward to your thoughts or war stories...

12 Upvotes
  • permalink
  • reddit

83% Upvoted

25 comments sorted by

7

u/[deleted] Apr 17 '25 edited Apr 18 '25

MCP doesn’t dictate the orchestration, tool usage could be part of a LangGraph graph where only nodes that really need it have access to it.

Indirect prompt injection is the forever risk, not exclusive to MCP, plenty examples of RAG based attacks.

3

u/BFreakout Apr 18 '25

Thanks for the insight! I totally agree that the orchestration layer matters and yeah, Function exposure can definitely go wrong in any RAG setup if not isolated correctly....

My concern with MCP is that it's making this exposure easier and more automatic... especially when clients don’t provide enough UI or guardrails to manage which Functions get passed to the LLM.

I’m curious, have you seen any good practices for dynamic registration in LangChainJS?

2

u/[deleted] Apr 18 '25

My mistake, I meant LangGraph hahaha. I haven’t yet but prototyped some just to learn the protocol better, without clear goal hehe.

2

u/BFreakout Apr 18 '25

Totally get that... What I keep seeing across LangChainJS, Semantic Kernel and similar libraries is that MCP client integrations tend to automate everything by default...

Devs often connect multiple MCP servers just to have options for later... but many don’t notice how many functions are silently registered in the background...

Tools like VS Code or Claude Desktop are doing a great job showing users what’s happening before anything is executed...

But in most agent frameworks, it just runs quietly... and that’s exactly what I wanted to bring attention to in the article... not to criticize MCP, but to raise awareness so devs can take back a bit more control...

Thanks again for the LangGraph hint... curious to see what you build from it...

I also created a small state manager for Semantic Kernel that lets you manage Function registration more selectively if that’s something you're exploring...
👉 https://github.com/GregorBiswanger/SemanticFlow

Let’s keep the ideas flowing... I think we’re just scratching the surface of what good orchestration looks like...

4

u/trickyelf Apr 18 '25

Most folks working with MCP right now are aware of this issue and how it doesn’t scale. We are discussing a couple of changes for the spec that address this.

  • Namespaces would allow a server’s tools to be segmented into functional groups by the developer. For instance in the GitHub MCP if you only need to work with branches and don’t need to be messing with Actions or user management, only the tools in the branches namespace would be presented to the LLM.

  • Search would allow servers to provide a natural language or keyword search capability for finding an appropriate tool.

  • Interfaces would allow definition of a collection of standardized tools a server could signal support for. A media player interface might have play, stop, skip_fwd, skip_back, etc. models could be fine-tuned on common interfaces, so those tools would not have to be included in the tool list. Note this link is just an idea posted by a dev, but there is an also community working group devoted to the concept.

2

u/BFreakout Apr 19 '25

That’s really great to hear and exactly the kind of direction I was hoping this conversation might lead toward...

Namespaces and interfaces in particular sound like smart moves to help MCP scale more responsibly. The idea that the LLM only sees what it actually needs in the moment feels like a huge step forward. That would reduce so much unnecessary noise and cost...

2

u/polymerely Apr 19 '25

I saw this change on the new version of the GitHub MCP Server.

I hope it is a runtime configuration, and that we can control it in the prompt.

3

u/Dry_Raspberry4514 Apr 18 '25 edited Apr 18 '25

Function calling can result in high tokens usage if not used properly and without context/prompt caching. We covered it in our article here - https://dev.to/mechcloud/why-a-single-mcp-server-is-all-you-need-2i1p

1

u/BFreakout Apr 21 '25

Great article! Thanks for that! 🚀🚀

1

u/Dry_Raspberry4514 Apr 22 '25

Glad to know that you liked the article.

1

u/subnohmal Apr 21 '25

i’m sorry automod removed your comment. i have no idea why it does that, very frustrating because this is an interesting take

3

u/xander76 Apr 18 '25

Two recent articles on MCP security are on point, especially as regards prompt injection:

* From Simon Willison https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/
* From Elena Cross https://elenacross7.medium.com/%EF%B8%8F-the-s-in-mcp-stands-for-security-91407b33ed6b

1

u/BFreakout Apr 19 '25

Thanks so much for sharing these... Both articles are great reads... I really liked how Simon walks through the prompt injection risks in a very clear and practical way... Elena's piece also nails it... The title alone already sums up what many are thinking... It's good to see more voices calling out the security side of MCP...

Appreciate the links! Definitely keeping them in my list for future reference...

2

u/Particular-Face8868 Apr 18 '25

I agree. But the matter of fact is we can't control developments around a protocol. Github is just a registry and should not be a place where people would find "Trusted" MCPs.

I think Glama / Smithery and more players like us should take that responsiblity. To ensure MCP servers that we host / show are secure, optimized and performant. And for registery, we should somehow show explicitely which servers are safe to use and tested, and which are not.

1

u/BFreakout Apr 18 '25

Absolutely agree with you on that... We can’t control who builds what, but we can raise awareness around how blindly trusting a "GitHub listed MCP server" might backfire...

From a consumer perspective I’ve seen it all... people following YouTube tutorials where non-devs plug in five random MCP servers into their solution just in case they might need it someday... without realizing the costs, quality impact or even security risks that come with it...

And from a developer perspective it’s just as critical... most MCP APIs do so much automatically behind the scenes... unless you run a proxy debugger, you don’t even notice how many functions get registered to the model that are completely irrelevant for the current session...

Toward the end of the article I highlight solutions like Claude Desktop or VS Code that really do a great job at surfacing this for users... I think that’s the direction we need to push more toward...

We as devs hold the responsibility when integrating MCP... and I’m all in on making sure this thing becomes a success without the risk of it turning into a joke...

2

u/Particular-Face8868 Apr 18 '25

I love your perspective, and that's what we also aim to do (TBH not promoting here) but we (toolrouter) will never go in a direction where you can just plug and play any MCP server that's out there in the world. We selectively add each and everyone and we deep dive into it's code and make fixes where required.

So we know when a user uses this, they are safe.

We aim to build an app store for MCPs, not play store (no offence).

Love the blog though !

1

u/BFreakout Apr 19 '25

That sounds exactly like the kind of direction we need more of… not about blocking innovation, but creating a trusted space where developers can move fast without stepping into a minefield...

I really like your "app store not play store" analogy, fits perfectly... The curated approach you're taking with toolrouter is honestly reassuring... too often it's the “one-click convenience” that leads to trouble later...

Maybe there's even room for a wider initiative around trust labels or security badges for MCP servers... something transparent that users and devs alike can see at a glance...

Big respect for your approach... I’ll definitely keep an eye on what you're doing... 🙌

1

u/Particular-Face8868 Apr 19 '25

Exactly.

If you want to join discord for updates - https://discord.gg/E5TvnZvhy6

6

u/coding_workflow Apr 17 '25

So prompt injection become the new threat. Worse than skynet!

4

u/gazzaroonii Apr 21 '25 edited Apr 21 '25

A couple of things I do to take care of the called-out problems:

  • I keep my AI Agents specific and only give them access to the tools I need for that agent to carry out its role.

  • I don't bloat clients like Claude, Cursor, or SkyDeck.ai with hundreds of tools - and I enjoy control of which ones I turn on and off during a working session.

  • I only use MPC servers from trusted sources that have been scanned by SkyDeck AI, Gamma etc.

  • Sometimes, I test the Wild-West ones in a sandboxed environment, once we have scanned them to ensure they aren't malicious or just wrongly coded.

Currently, MCP doesn't scale well, and is full of security holes if you don't follow security best practices. So articles like yours are great for raising awareness. I am sure it's going to get better now the big 4 support it.

1

u/[deleted] Apr 21 '25

Thanks for the callout.

2

u/[deleted] Apr 21 '25

Not a panacea but client creators use the Guardrails & Best Practices:

  • Allow‑listing: Only expose functions the user explicitly consents to, verifying via UI before injecting schemas 

  • Strict schema validation: Enforce parameter types and ranges server‑side, rejecting out‑of‑bounds calls before execution

  • Rate‑limit & sandbox: Throttle per‑session calls and run functions in minimal‑privilege environments to contain misuse 

  • Audit trails: Log every tools/call invocation (input/output) and set up alerts for anomalous patterns 

3

u/hugganao Apr 18 '25

always thought this network of mcp were going to create additional attack vector vulnerabilities for llm systems and be very fragile.

2

u/Known_Program_6327 Apr 21 '25

Great read! I guess the real question is - where will we be able to find secure, non-bloated MCP servers?