Topic starter
15/12/2025 5:10 pm
TL;DR: Function calling keeps model-tool integration simple, but it ties tool definitions and credentials to the application, while MCP separates capabilities into server-side components with finer-grained security and better portability, according to Descope's analysis. For IAM and NHI practitioners, the architectural choice is really about where trust, permissions, and auditability live as agent fleets grow.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “MCP vs. Function Calling: How They Differ and Which to Use”.
Key questions
Q: What breaks when tool access stays embedded in the application layer?
A: When tool definitions, credentials, and execution logic sit inside the same application, compromise or misconfiguration of that app can expose every function the model can reach.
Q: When does MCP make more sense than function calling?
A: MCP makes more sense when tool reuse, access scoping, and auditability matter more than fast prototyping.
Q: How do you know whether an AI integration is too tightly coupled?
A: If changing a tool means editing the main application, duplicating schemas, or reworking secrets handling in multiple places, the integration is too tightly coupled.
Practitioner guidance
- Define the trust boundary for tool execution Map which credentials, data sources, and approval paths remain inside the application and which should move behind a separate MCP server boundary.
- Separate credentials from client code Keep backend secrets in the server process rather than in the model-facing application so compromise of the client does not expose every downstream permission.
- Standardise reusable tool servers Package shared integrations as protocol-based servers so multiple agents and multiple models can reuse the same governed capability set.
Bottom line: MCP and function calling differ most at the trust boundary, not just in developer ergonomics.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 months ago by NHI Mgmt Group
This topic was modified 10 months ago 3 times by Abdelrahman
This topic was modified 7 days ago by NHI Mgmt Group
06/10/2026 4:29 pm
Tool integration becomes an identity design decision once AI systems reach production scale. The article’s core comparison is not really about developer convenience. It is about whether trust, permissions, and auditability remain inside the app or move to an integration layer that can be governed independently. For identity programmes, that means tool integration patterns now belong in the same conversation as privilege model design and access boundary definition.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
A question worth separating out:
Q: What is the difference between application-level and server-level access control for agents?
A: Application-level access control ties tool use to the code that invokes it, so the app holds both the instructions and the credentials. Server-level access control puts the sensitive permissions behind a separate component that exposes only the approved capability. The second model is easier to scope, monitor, and retire.
👉 Read our full editorial: MCP versus function calling: security and scale trade-offs