Here is an overview of the core components in an AI ecosystem and their interactions within the OpenEdge MCP Server architecture.

  • End-User Client—The interface where tasks originate. It can be a chat application, web interface, or command-line tool. This client may embed an MCP Client or connect to one externally. It provides user credentials that authorize tool invocations.
  • MCP Client (through an AI Agent)—The MCP Client communicates with the MCP Server using the Model Context Protocol. It holds two credentials:
    • A service account credential assigned by the server.
    • A user token or JWT representing the end-user identity.
    The MCP Client discovers available tools, selects prompts, and invokes operations on behalf of the end-user. In simple deployments, the MCP Client and end-user client run in the same process. In multi-tier setups, they operate separately. Examples of MCP clients include VS Code extension, Windsurf, custom web chat UI, web dashboard application, and standalone desktop app.
  • MCP Server—The MCP Server is the central component of this architecture. It converts OpenAPI specifications and optional prompts into scoped tools. Key responsibilities include:
    • Validating both service account and user credentials ensuring dual authentication.
    • Applying scope-based access control.
    • Enforcing routing rules, which are read-only by default.
    • Executing downstream HTTP calls with guardrails for size and performance.
    The MCP Server never forwards its service account credential to downstream systems. When configured with OAuth2 endpoints, it acts as an authorization server, delegating authentication to external Identity Providers and managing OAuth2 protocol flows, including authorization code exchange, proof key for code exchange (PKCE) validation, and token issuance.
  • Identity Provider (IdP)—External authentication systems, such as Keycloak, Azure AD, AWS Cognito, or Google handle user authentication. The MCP Server delegates login and consent to these providers, which issue OAuth2/OIDC tokens. The MCP Server validates these tokens and may exchange them for downstream usage.
  • PAS for OpenEdge Single Sign-On (SSO) token exchange—Specifies an optional identity or token exchange endpoint.
    • When token exchange is configured—The MCP Server exchanges the inbound user credential for a PAS for OpenEdge-scoped token. This token includes audience, claims, or lifetimes tailored for backend services. If token exchange fails, the request is denied.
    • When token exchange is not configured—This component is bypassed.
  • PAS for OpenEdge services—Specify the OpenEdge or PAS for OpenEdge REST, or other backend services that implement business logic. They receive only the end-user credential or the exchanged token. Responses pass through MCP Server guardrails before reaching the MCP Client.