MCP tool abuse targets models and applications that use the Model Context Protocol to connect agents with tools and data. General function-calling abuse applies more broadly, including systems that do not use MCP but still let models interpret tool schemas. Both can expose prompts or trigger unsafe behavior, but the protocol layer and attack path differ.
Why This Matters for Security Teams
MCP tool abuse and general function-calling abuse can look similar from the outside, but they sit at different layers of the agent stack. That matters because defenders need to know whether they are securing a protocol boundary, a schema interpreter, or both. When teams treat every tool interaction as the same risk, they often miss where trust is actually being granted, and where an attacker can influence execution, data exposure, or action selection. The OWASP Agentic AI Top 10 is useful here because it frames agent abuse as a control problem, not just a prompt problem.
The practical distinction is that MCP introduces a standardised way for agents to discover and invoke tools, while general function calling may be custom-built, vendor-specific, or embedded in application logic. That means the abuse path changes: MCP issues often involve tool exposure, server trust, and instruction injection through connected resources, while function-calling abuse can stem from weak schema design, unsafe argument handling, or overbroad tool permissions. In practice, many security teams encounter the distinction only after an agent has already invoked the wrong tool, rather than through intentional design review.
How It Works in Practice
MCP tool abuse usually begins when an agent connects to a tool server that exposes capabilities the model can discover and call. If the server returns untrusted content, accepts overly broad requests, or lacks strong authorization checks, the model may be steered into revealing context, issuing dangerous actions, or chaining into a higher-risk workflow. General function-calling abuse is broader: the model is given a function schema, decides when to use it, and then supplies arguments that the application executes. The attack surface exists even without MCP, because the core problem is still model-mediated action selection.
Operationally, defenders should separate three control questions:
- Who is allowed to advertise, register, or expose tools to the agent?
- What input from the model is validated before execution?
- What limits exist on the tool’s data access, side effects, and downstream chaining?
Current guidance suggests treating tool descriptions, returned content, and model-supplied arguments as untrusted until validated. The NIST AI Risk Management Framework is helpful for structuring those decisions around governance, mapping, and monitoring, while the MITRE ATLAS adversarial AI threat matrix gives a useful lens for abuse patterns such as manipulation, evasion, and unsafe orchestration. For teams building or reviewing agent platforms, the difference is not academic: MCP adds a standard protocol boundary, but function-calling abuse can happen anywhere a model is allowed to translate language into execution. These controls tend to break down in loosely governed plugin ecosystems because tool registration, authorization, and logging are often split across different owners.
Common Variations and Edge Cases
Tighter tool governance often increases integration overhead, requiring organisations to balance faster agent enablement against stronger review and authorization controls. That tradeoff becomes more visible in hybrid environments where some agents use MCP and others use custom tool wrappers, because one policy model rarely fits both cleanly.
There is no universal standard for how every platform should separate protocol trust from function trust, so best practice is evolving. In lower-risk internal workflows, teams may accept simpler function schemas with narrow permissions. In higher-risk settings, especially where agents can read sensitive data or trigger external actions, the safer approach is to assume both MCP resources and function calls can be abused unless independently constrained.
One important edge case is that an MCP deployment can still suffer from plain function-calling abuse if the application behind it blindly trusts the model’s arguments. The reverse is also true: a non-MCP agent can be vulnerable to the same class of instruction manipulation if its tool descriptions or return values are not isolated from the model. The key question is not whether MCP is present, but whether the agent can be induced to choose or shape an unsafe action path. That distinction becomes most fragile when tool chains span multiple vendors, because ownership of validation and logging is fragmented.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers abuse patterns in agent tool use and orchestration. | |
| NIST AI RMF | Frames governance, mapping, and monitoring for AI system risks. | |
| MITRE ATLAS | AML.T0054 | Maps adversarial manipulation and abuse of AI decision paths. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central when agents can invoke tools or access data. |
| NIST Zero Trust (SP 800-207) | AC-4 | Trust boundaries matter when agents call external tools and services. |
Review agent tool invocation paths, constrain permissions, and test for prompt or tool abuse.
Related resources from NHI Mgmt Group
- What is the difference between tool-level access and data-level access for AI agents?
- What is the difference between function calling and MCP for enterprise security?
- What is the difference between managing LLM routing and managing MCP tool access in enterprise AI platforms?
- What is the difference between standard tool integration and MCP-based AI agent access?
