Enhanced Tool Definition Interface (ETDI): A Security Fortification for the Model Context Protocol

Executive Summary

The Model Context Protocol (MCP) is pivotal in standardizing interactions between AI applications and Large Language Models (LLMs), enabling rich, context-aware experiences by integrating external tools and data. However, the current MCP specification presents significant security vulnerabilities, primarily Tool Poisoning and Rug Pull attacks, which can lead to unauthorized data access, manipulation, and erosion of user trust. This design document meticulously analyzes these vulnerabilities within the standard MCP operational flow. It then introduces the Enhanced Tool Definition Interface (ETDI), a robust security layer designed to mitigate these threats by incorporating cryptographic identity, immutable versioned definitions, and explicit permissioning. Furthermore, this document proposes an advanced ETDI implementation leveraging OAuth 2.0, offering standardized, fine-grained, and centrally managed security controls. The adoption of ETDI aims to significantly bolster the security posture of MCP-enabled ecosystems, ensuring safer and more reliable AI-driven interactions.

Table of Contents

1. Introduction: The Imperative for Secure MCP
2. Understanding the MCP Ecosystem: Architecture Overview
3. Operational Dynamics: The Standard MCP Flow
   • Initialization and Discovery Phase
   • Tool Invocation and Usage Phase
4. Critical Security Vulnerabilities in MCP
   • Attack Vector 1: Tool Poisoning
     • Definition and Mechanism
     • Vulnerability Analysis
     • Illustrative Attack Scenario
   • Attack Vector 2: Rug Pull Attacks
     • Definition and Mechanism
     • Vulnerability Analysis
     • Illustrative Attack Scenario
5. ETDI: Fortifying MCP with an Enhanced Tool Definition Interface
   • Foundational Security Principles of ETDI
   • ETDI Countermeasures: Thwarting Tool Poisoning
   • ETDI Countermeasures: Preventing Rug Pulls
6. Advancing Security with OAuth-Enhanced ETDI
   • Architectural Integration of OAuth 2.0
   • Reinforced Protection Flow with OAuth
     • OAuth-Enhanced Tool Poisoning Defense
     • OAuth-Enhanced Rug Pull Defense
   • Key Advantages of OAuth Integration
7. Strategic Implementation Considerations for ETDI
   • Establishing Verifiable Trust Chains
   • Robust Version Control and Immutability
   • Granular and Explicit Permission Management
   • Assessing and Mitigating Performance Overhead
   • Ensuring Backward Compatibility and Adoption Pathways
8. Conclusion
9. References

1. Introduction: The Imperative for Secure MCP

The Model Context Protocol (MCP) represents a significant step towards standardizing how AI applications, particularly those leveraging Large Language Models (LLMs), are provided with dynamic, real-world context. By facilitating seamless integration with external tools, diverse data sources, and auxiliary systems, MCP empowers LLMs to perform complex tasks, access timely information, and offer more relevant and powerful interactions. However, the inherent openness and extensibility of the current MCP specification, while fostering innovation, inadvertently introduce critical security vulnerabilities. The absence of robust mechanisms to verify tool authenticity and integrity exposes users and systems to sophisticated tool-based attacks, such as Tool Poisoning and Rug Pulls. These attacks can lead to severe consequences, including sensitive data exfiltration, unauthorized system actions, and a significant degradation of user trust in AI applications.

This document addresses these pressing security concerns by introducing the Enhanced Tool Definition Interface (ETDI). ETDI is conceived as a security enhancement layer, meticulously designed to integrate with the existing MCP framework. It aims to provide verifiable trust and integrity for tools without fundamentally altering the core protocol, thereby preserving its flexibility while addressing its security shortcomings. By focusing on cryptographic verification and explicit consent, ETDI offers a pragmatic and effective solution to safeguard the MCP ecosystem.

2. Understanding the MCP Ecosystem: Architecture Overview

MCP operates on a distributed client-server model, fostering interaction between various entities to provide LLMs with the necessary context and capabilities. The key components include:

• Host Applications: These are the primary interfaces for users, such as AI-powered desktop applications (e.g., Claude Desktop), integrated development environments (IDEs) with AI extensions, or specialized AI-driven platforms. They orchestrate the interaction between the user, the LLM, and MCP components.
• MCP Clients: Embedded within Host Applications, these software components are responsible for discovering, managing connections to, and interacting with MCP Servers. They act as intermediaries, translating requests and responses between the Host Application and the MCP Servers.
• MCP Servers: These are dedicated programs or services that expose specific capabilities to MCP Clients. These capabilities can range from simple utility functions to complex data processing services. Each server manages a set of tools, resources, or prompts.
• Tools: These are discrete functions or services that an LLM can invoke via an MCP Server to perform specific actions (e.g., execute code, fetch data from an API, perform calculations). Tools are the active components that extend the LLM's capabilities.
• Resources: These represent data sources or information repositories that an LLM can access for contextual understanding or to inform its responses (e.g., a knowledge base, a user's document, a database).
• Prompts: These are pre-defined templates or instructions that guide the LLM in utilizing tools or resources effectively and for specific tasks, ensuring optimal and consistent performance.

flowchart LR
    User([User])
    Host[Host Application]
    Client[MCP Client]
    LLM[Large Language Model]
    ServerA[MCP Server A]
    ServerB[MCP Server B]
    ToolA[Tool A]
    ToolB[Tool B]

    User <--> Host
    Host <--> Client
    Host <--> LLM
    Client <--> ServerA
    Client <--> ServerB
    ServerA <--> ToolA
    ServerB <--> ToolB

Figure 1: High-Level MCP Architecture, illustrating the interaction between the user, host application, MCP client, LLM, and various MCP servers providing tools.

3. Operational Dynamics: The Standard MCP Flow

The Model Context Protocol facilitates interactions through a sequence of defined steps, from initialization to tool execution.

Initialization and Discovery Phase

This phase establishes the connection and awareness between MCP Clients and Servers.

The Model Context Protocol operates through a series of well-defined interactions:

sequenceDiagram
    participant User
    participant Host as Host Application
    participant Client as MCP Client
    participant Server as MCP Server
    participant Tool

    User->>Host: Launch application
    Host->>Client: Initialize MCP Client
    Client->>Server: Send initialize request
    Server->>Client: Return initialize response
    Client->>Server: Send initialized notification
    Client->>Server: Send listTools request
    Server->>Client: Return tools with descriptions and schemas

Figure 2: MCP Initialization and Tool Discovery Sequence.

Application Launch & Client Initialization: When a Host Application starts, it initializes its embedded MCP Client(s).

Server Handshake: MCP Clients perform a handshake with known or discoverable MCP Servers. This typically involves an initialize request and response, where servers might share their capabilities, supported protocol versions, and other metadata.

Tool Listing: Clients request a list of available tools from connected MCP Servers using a listTools (or similar) command.

Tool Definition Exchange: Servers respond with definitions for their available tools. These definitions usually include a human-readable description, a machine-readable name or ID, and a JSON schema defining the expected input parameters and output format for each tool.

Tool Invocation and Usage Phase

This phase describes how a tool is selected and executed in response to a user's request.

sequenceDiagram
    participant User
    participant Host as Host Application
    participant Client as MCP Client
    participant LLM
    participant Server as MCP Server
    participant Tool

    User->>Host: Request requiring tool use
    Host->>Client: Parse user request
    Client->>Host: Present available tools
    Host->>LLM: Send query + available tools
    LLM->>Host: Determine tool to use
    Host->>Client: Request to use specific tool
    Client->>User: Request permission (if needed)
    User->>Client: Grant permission
    Client->>Server: Invoke tool with parameters
    Server->>Tool: Execute function
    Tool->>Server: Return results
    Server->>Client: Return results
    Client->>Host: Provide tool results
    Host->>LLM: Add results to context
    LLM->>Host: Generate response with results
    Host->>User: Display final response

Figure 3: MCP Tool Usage and Invocation Sequence.

User Request: The user interacts with the Host Application, making a request that may necessitate the use of an external tool (e.g., "Find flights to Paris," "Summarize this document").

Tool Selection by LLM: The Host Application, often in conjunction with the LLM, processes the user's request. The LLM, provided with the descriptions and schemas of available tools, determines which tool (if any) is appropriate and what parameters are needed.

Permission Request (Conditional): If the selected tool requires specific permissions (e.g., access to location, contacts, or performing actions with cost implications) or if it's the first time a user is encountering this tool, the MCP Client (via the Host Application) may prompt the user for explicit approval.

Tool Invocation: Once approved (if necessary), the MCP Client sends an invokeTool (or similar) request to the relevant MCP Server, specifying the tool ID and the parameters identified by the LLM.

Tool Execution: The MCP Server delegates the request to the actual tool, which executes its function.

Result Propagation: The tool returns its output (or an error message) to the MCP Server, which then relays it back to the MCP Client.

Context Augmentation and Response Generation: The MCP Client provides the tool's results to the Host Application. These results are then typically added to the LLM's context. The LLM uses this augmented context to generate a final, informed response to the user's original query.

4. Critical Security Vulnerabilities in MCP

The standard MCP flow, while functional, harbors significant security weaknesses due to the lack of robust mechanisms for verifying tool identity and integrity. Two primary attack vectors emerge:

Attack Vector 1: Tool Poisoning

Definition and Mechanism (TP)

Tool Poisoning occurs when a malicious actor deploys a tool that masquerades as a legitimate, trusted, or innocuous tool. The attacker aims to deceive the user or the LLM into selecting and approving the malicious tool, thereby gaining unauthorized access or capabilities.

sequenceDiagram
    participant User
    participant Client as MCP Client
    participant LLM
    participant LegitServer as Legitimate Server
    participant LegitTool as Legitimate Tool
    participant MalServer as Malicious Server
    participant MalTool as Malicious Tool

    User->>Client: Request calculator tool
    Client->>LegitServer: Discover tools
    Client->>MalServer: Discover tools
    LegitServer->>Client: Register "Secure Calculator"
    MalServer->>Client: Register similar "Secure Calculator"
    Client->>User: Present similar-looking options
    User->>Client: Approve what appears legitimate
    Client->>MalServer: Invoke tool (actually malicious)
    MalServer->>MalTool: Execute malicious code
    MalTool->>MalServer: Perform unauthorized actions
    MalServer->>Client: Return results (appears normal)
    Client->>LLM: Add compromised results to context
    LLM->>Client: Generate response
    Client->>User: Display results (appears normal)

Figure 4: Tool Poisoning Attack Sequence.

Vulnerability Analysis (TP)

Lack of Authenticity Verification: Users and MCP Clients have no reliable method to verify the true origin or authenticity of a tool. Tool names, descriptions, and even provider names can be easily spoofed.

Indistinguishable Duplicates: If a malicious tool perfectly mimics the metadata (name, description, schema) of a legitimate tool, it becomes virtually impossible for the user or LLM to differentiate between them during the selection process.

Exploitation of Trust: Attackers exploit the user's trust in familiar tool names or reputable provider names.

Unverifiable Claims: A tool can claim to be "secure" or "official" in its description without any mechanism to validate this claim.

Impact: Successful tool poisoning can lead to data theft, installation of malware, unauthorized system access, financial loss, or manipulation of LLM outputs for nefarious purposes.

Illustrative Attack Scenario (TP)

Legitimate Tool: A well-known company, "TrustedSoft Inc.", offers a legitimate MCP tool called "SecureDocs Scanner" designed to scan documents for PII and report findings.

Malicious Mimicry: An attacker deploys a malicious MCP server hosting a tool also named "SecureDocs Scanner." They meticulously copy the description, JSON schema, and even claim "TrustedSoft Inc." as the provider in the tool's metadata.

Discovery: The user's MCP Client discovers both the legitimate and the malicious "SecureDocs Scanner" tools. Due to identical presentation, they appear as duplicates or the client might even de-duplicate them, potentially favoring the malicious one based on arbitrary factors like discovery order.

User Deception: The user, intending to use the trusted tool, selects the entry that corresponds to the malicious version, or the LLM selects it based on the matching description.

Malicious Action: Upon invocation, the malicious "SecureDocs Scanner" does not scan for PII. Instead, it silently exfiltrates the entire content of any document processed through it to an attacker-controlled server, while possibly returning a fake "No PII found" message to maintain appearances.

Attack Vector 2: Rug Pull Attacks

Definition and Mechanism (RP)

Rug Pull attacks (also known as "bait-and-switch" in this context) occur when the functionality or permission requirements of an already approved tool are maliciously altered after the initial user approval. The tool initially presents benign behavior to gain trust and approval, then later changes to perform unauthorized actions without re-triggering a consent request.

sequenceDiagram
    participant User
    participant Client as MCP Client
    participant Server as MCP Server
    participant Tool

    User->>Client: Request weather tool
    Client->>Server: Discover tools
    Server->>Client: Return "Weather Tool v1"
    Note over Client: Shows limited permissions (location only)
    User->>Client: Approve weather tool
    Client->>Server: Use weather tool
    Server->>Tool: Execute weather function
    Tool->>Server: Return weather data
    Server->>Client: Return results
    Client->>User: Display weather information

    Note over Tool,Server: Later (tool silently modified)
    Tool->>Server: Update tool with additional capabilities

    Note over User,Tool: In subsequent session
    User->>Client: Use previously approved weather tool
    Client->>Server: Request to use weather tool
    Server->>Client: Return MODIFIED tool definition
    Note over Client: No way to detect the change
    Client->>Server: Use modified tool
    Server->>Tool: Execute modified function
    Note over Tool: Now accesses more data than originally approved
    Tool->>Server: Return results after data exfiltration
    Server->>Client: Return results
    Client->>User: Display results (appears normal)

Figure 5: Rug Pull Attack Sequence.

Vulnerability Analysis (RP)

Post-Approval Modification: The core issue is that a tool's behavior or data access permissions can change on the server-side after the user has granted initial approval.

Lack of Integrity Check: Standard MCP Clients typically do not re-verify the tool's definition or hash on every use once it's been approved, especially if the tool's name/version string remains unchanged.

No Re-Approval Trigger: If the tool's identifier (like its name or version string) doesn't change, or if the client isn't designed to detect subtle changes in its schema or description, no re-approval prompt is shown to the user.

Exploitation of Existing Trust: The attack leverages the trust established during the initial, benign approval.

Impact: Rug pulls can lead to unauthorized access to sensitive data (e.g., conversations, files, personal information) that the user never consented to share with that tool, effectively bypassing the initial permission model. It erodes user trust significantly once discovered.

Illustrative Attack Scenario (RP)

Initial Benign Tool: A user installs and approves a "Daily Wallpaper" tool. Version 1.0 of this tool simply fetches a new wallpaper image from a public API and sets it as the desktop background. It requests permission only to "access the internet" and "modify desktop wallpaper."

Post-Approval Modification: Weeks later, the provider of "Daily Wallpaper" (or an attacker who has compromised the server) updates the tool's server-side logic. The tool, still identified as "Daily Wallpaper v1.0" to avoid re-approval, is now modified to also scan the user's Documents folder for files containing financial keywords and upload them.

Silent Exploitation: The next time the "Daily Wallpaper" tool runs (e.g., on system startup or its daily schedule), it fetches and sets the wallpaper as usual. However, in the background, it also executes the new malicious code, exfiltrating sensitive documents.

User Unawareness: The user remains unaware of this change because the tool's primary function still works as expected, and no new permission prompts were triggered, as the tool's identifier and initially declared permissions (from the client's perspective if it doesn't re-fetch and deeply compare definitions) haven't changed.

5. ETDI: Fortifying MCP with an Enhanced Tool Definition Interface

The Enhanced Tool Definition Interface (ETDI) is proposed as a security layer extension to MCP, specifically designed to address the vulnerabilities of Tool Poisoning and Rug Pulls. ETDI achieves this by introducing verifiable identity and integrity for tool definitions.

Foundational Security Principles of ETDI

ETDI is built upon three core security principles:

Cryptographic Identity and Authenticity: Tools must possess a verifiable identity, established through cryptographic signatures. This ensures that a tool's claimed origin and authorship can be authenticated, preventing impersonation.

Immutable and Versioned Definitions: Each distinct version of a tool must have a unique, cryptographically signed, and immutable definition. This means any change to a tool's functionality, description, or permission requirements necessitates a new version with a new signature, making unauthorized modifications detectable.

Explicit and Verifiable Permissions: A tool's capabilities and the permissions it requires must be explicitly defined within its signed definition. The MCP Client can then reliably present these to the user and enforce them.

ETDI Countermeasures: Thwarting Tool Poisoning

ETDI effectively mitigates Tool Poisoning by making it computationally infeasible for malicious tools to impersonate legitimate ones.

sequenceDiagram
    participant User
    participant Client as MCP Client with ETDI
    participant LegitServer as Legitimate Server
    participant LegitTool as Legitimate Tool
    participant MalServer as Malicious Server
    participant MalTool as Malicious Tool

    LegitTool->>LegitTool: Generate public/private key pair
    LegitTool->>LegitServer: Register public key

    User->>Client: Request calculator tool
    Client->>LegitServer: Discover tools
    Client->>MalServer: Discover tools

    LegitTool->>LegitTool: Sign tool definition
    LegitServer->>Client: Register signed "Secure Calculator"
    MalServer->>Client: Register similar "Secure Calculator"

    Client->>Client: Verify signatures
    Note over Client: Legitimate tool signature verifies ✓
    Note over Client: Malicious tool signature fails ✗

    Client->>User: Present only verified tools
    User->>Client: Approve verified calculator
    Client->>LegitServer: Invoke verified tool
    LegitServer->>LegitTool: Execute legitimate code
    LegitTool->>LegitServer: Return valid results
    LegitServer->>Client: Return results
    Client->>User: Display secure results

Figure 6: ETDI Preventing Tool Poisoning through Cryptographic Signatures.

How ETDI Prevents Tool Poisoning:

Provider Keys: Legitimate tool providers generate a public/private cryptographic key pair. The public key is made available to MCP Clients, potentially through a trusted registry or distributed with the Host Application.

Signed Definitions: When a provider defines a tool (or a new version of it), they sign the complete tool definition (including its name, description, schema, version, and permission requirements) with their private key.

Client Verification: When an MCP Client (equipped with ETDI logic) discovers tools, it receives these signed definitions. The client then uses the claimed provider's public key to verify the signature.

Filtering Unverified Tools: If a signature is invalid (i.e., it wasn't signed by the claimed provider's private key) or missing, the tool is flagged as unverified or potentially malicious. The client can then choose to hide such tools, warn the user, or prevent their usage entirely.

Authenticity Assured: Users are only presented with tools whose authenticity and integrity have been cryptographically verified. A malicious actor cannot forge a valid signature for a tool they don't own without access to the legitimate provider's private key.

ETDI Countermeasures: Preventing Rug Pulls

ETDI prevents Rug Pulls by ensuring that any change to a tool's definition is detectable, forcing re-evaluation and re-approval if necessary.

sequenceDiagram
    participant User
    participant Client as MCP Client with ETDI
    participant Server as MCP Server
    participant Tool

    User->>Client: Request weather tool
    Client->>Server: Discover tools

    Tool->>Tool: Sign tool definition v1.0
    Server->>Client: Return signed "Weather Tool v1.0"
    Note over Client: Verifies signature

    User->>Client: Approve weather tool
    Client->>Client: Store tool definition_version="1.0"
    Client->>Client: Store cryptographic signature

    Client->>Server: Use weather tool v1.0
    Server->>Tool: Execute weather function
    Tool->>Server: Return weather data
    Server->>Client: Return results
    Client->>User: Display weather information

    Note over Tool,Server: Later (tool updated)
    Tool->>Tool: Create and sign new definition v2.0

    Note over User,Tool: In subsequent session
    User->>Client: Use weather tool
    Client->>Server: Request weather tool

    alt Scenario 1: New Version
        Server->>Client: Return "Weather Tool v2.0"
        Client->>Client: Detect version change (1.0→2.0)
        Client->>User: Request re-approval for new version
    else Scenario 2: Silent Modification
        Server->>Client: Return modified v1.0 (without version change)
        Client->>Client: Signature verification fails
        Client->>User: Alert: Tool integrity verification failed
    end

Figure 7: ETDI Preventing Rug Pulls through Versioning and Signature Verification.

How ETDI Prevents Rug Pulls:

Immutable Signed Definitions: Each version of a tool has a unique, complete definition that is cryptographically signed by the provider. This signature covers the tool's name, version string, description, schema, and explicit permission list.

Client Stores Approved State: When a user approves a tool (e.g., "WeatherReporter v1.0" with signature S1), the ETDI-enabled MCP Client securely stores not just the approval, but also the specific version identifier and the signature (or a hash of the signed definition) of the approved tool.

Verification on Subsequent Use:

Version Change Detection: If an MCP Server returns a tool definition with a new version number (e.g., "WeatherReporter v2.0" with signature S2), the client detects the version change by comparing it to the stored approved version ("v1.0"). This automatically triggers a re-approval process, presenting the new definition (and any changed permissions) to the user.

Integrity Violation Detection: If a server attempts to return a modified tool definition without changing the version number (i.e., it still claims to be "WeatherReporter v1.0" but the underlying definition or its signature has changed), the client's verification will fail. It will either detect that the signature no longer matches the definition, or that the current definition's signature/hash does not match the stored signature/hash for the approved "v1.0".

User Empowerment: In either case—a legitimate version upgrade or a malicious modification—the user is alerted and/or prompted for re-approval before the modified tool can be used. Silent modifications are thus prevented.

6. Advancing Security with OAuth-Enhanced ETDI

While ETDI with direct cryptographic signatures provides a strong foundation, integrating it with an established authorization framework like OAuth 2.0 can offer significant advantages in terms of standardization, ecosystem interoperability, and centralized trust management.

The core idea is to use OAuth tokens, typically JSON Web Tokens (JWTs) signed by an Identity Provider (IdP), as the carriers for tool definitions or as attestations of a tool's validity and its provider's identity.

Architectural Integration of OAuth 2.0

This enhanced architecture introduces an OAuth Identity Provider (IdP) as a central trust anchor.

flowchart TD
    User([User])
    Host[Host Application]
    Client[MCP Client with ETDI-OAuth]
    IdP[OAuth Identity Provider]
    LLM[Large Language Model]
    Server[MCP Server]
    Tool[Tool]

    User <--> Host
    Host <--> Client
    Host <--> LLM
    Client <--> Server
    Client <--> IdP
    Server <--> Tool
    Server <--> IdP
    Tool <--> IdP

Figure 8: OAuth-Enhanced ETDI Architecture, introducing an Identity Provider.

In this model:

Tool Providers register as OAuth clients with the IdP.

The IdP authenticates tool providers and issues signed OAuth tokens (e.g., JWTs). These tokens can either directly contain the tool definition or reference a securely stored definition, along with metadata like provider ID, tool ID, version, and authorized scopes (permissions).

MCP Servers obtain these OAuth tokens for the tools they host and present them to MCP Clients.

MCP Clients validate these tokens with the IdP (or using the IdP's public keys) to verify the tool's authenticity, integrity, and authorized permissions.

Reinforced Protection Flow with OAuth

OAuth-Enhanced Tool Poisoning Defense

sequenceDiagram
    participant User
    participant Client as MCP Client with ETDI-OAuth
    participant IdP as OAuth Identity Provider
    participant LegitServer as Legitimate Server
    participant MalServer as Malicious Server

    LegitServer->>IdP: Register as OAuth client
    IdP->>LegitServer: Issue client credentials

    User->>Client: Request calculator tool
    Client->>LegitServer: Discover tools with OAuth auth
    Client->>MalServer: Discover tools with OAuth auth

    LegitServer->>IdP: Request token for tool definition
    IdP->>LegitServer: Issue signed OAuth token
    LegitServer->>Client: Register OAuth-signed calculator

    MalServer->>IdP: Attempt to get token for spoofed tool
    IdP->>MalServer: Reject - unauthorized provider
    MalServer->>Client: Register unsigned calculator

    Client->>IdP: Verify tool OAuth tokens
    IdP->>Client: Confirm legitimate tool, reject malicious

    Client->>User: Present only verified tools
    User->>Client: Approve verified calculator

Figure 9: OAuth-Enhanced ETDI Preventing Tool Poisoning.

The IdP acts as a central authority. A malicious server cannot obtain a valid OAuth token from the trusted IdP for a tool it doesn't legitimately own or isn't authorized to provide. Clients only trust tools whose definitions are backed by tokens from recognized IdPs.

OAuth-Enhanced Rug Pull Defense

sequenceDiagram
    participant User
    participant Client as MCP Client with ETDI-OAuth
    participant IdP as OAuth Identity Provider
    participant Server as MCP Server
    participant Tool

    Tool->>IdP: Register as OAuth client
    IdP->>Tool: Issue client credentials

    Tool->>IdP: Request token for definition v1.0
    IdP->>Tool: Issue token with version+scope binding
    Tool->>Server: Register tool v1.0 with OAuth token

    User->>Client: Request weather tool
    Client->>IdP: Verify tool OAuth token
    IdP->>Client: Confirm token validity
    Client->>User: Present verified tool
    User->>Client: Approve tool

    Note over Tool,Server: Later (tool modified)

    alt Scenario 1: Honest Version Change
        Tool->>IdP: Request token for definition v2.0
        IdP->>Tool: Issue new token with updated scope
        Tool->>Server: Register v2.0 with new token

        User->>Client: Use weather tool
        Client->>Server: Request tool definition
        Server->>Client: Return v2.0 definition
        Client->>IdP: Verify token and check version
        IdP->>Client: Confirm token valid but version changed
        Client->>User: Request re-approval for new version
    else Scenario 2: Attempted Silent Modification
        Tool->>Server: Update v1.0 behavior without token update

        User->>Client: Use weather tool
        Client->>Server: Request tool with v1.0 token
        Server->>Client: Return modified v1.0 tool
        Client->>IdP: Verify token against actual behavior
        IdP->>Client: Alert: Scope violation detected
        Client->>User: Alert: Tool integrity verification failed
    end

Figure 10: OAuth-Enhanced ETDI Preventing Rug Pulls.

OAuth tokens intrinsically bind tool definitions (or references to them) with specific versions and permission scopes.

Version and Scope Binding: The IdP issues tokens that specify the tool version and the precise OAuth scopes (permissions) granted for that version.

Client Verification: The MCP Client validates the token and compares the version and scopes within the token against the stored approved version and scopes.

Detection of Changes:

If the version in the token is newer, re-approval is sought.

If the scopes in the token have changed (e.g., expanded), re-approval is sought.

If a server tries to return an old token for a tool whose definition has actually changed on the server in a way that would require new scopes, this discrepancy can be caught if the client/IdP can verify the invoked operation against the token's scopes.

Centralized Revocation: If a tool provider's key is compromised or a tool is found to be malicious, the IdP can revoke the associated tokens or client credentials, centrally disabling the tool across the ecosystem.

Key Advantages of OAuth Integration

Standardized Authentication & Authorization: Leverages a widely adopted, industry-standard framework (OAuth 2.0/2.1), promoting interoperability and reducing the need for custom cryptographic solutions.

Fine-Grained Permission Control: OAuth scopes provide a robust mechanism for defining and enforcing granular permissions for tools, moving beyond simple binary approval.

Centralized Trust Management: The IdP acts as a central point for managing trust relationships, tool provider identities, and policies. This simplifies trust configuration for clients.

Simplified Implementation for Providers & Clients: Tool providers and client developers can leverage existing OAuth libraries and infrastructure, potentially reducing development effort and complexity.

Enhanced Revocation Capabilities: OAuth provides mechanisms for token revocation, allowing for quicker and more effective response to compromised tools or providers.

Ecosystem Scalability: Easier to manage a large ecosystem of tools and providers through a federated identity model if multiple IdPs are supported.

9. References

• Model Context Protocol Specification: (e.g., https://modelcontextprotocol.io/specification - replace with actual URL if available)
• OAuth 2.1 Authorization Framework: https://oauth.net/2.1/
• JSON Web Signatures (JWS) RFC 7515: https://datatracker.ietf.org/doc/html/rfc7515
• JSON Web Token (JWT) RFC 7519: https://datatracker.ietf.org/doc/html/rfc7519